|
Seems to be OK (without reading this...)
|
|
|
|
|
Have you seen Sander's tastes in music?
The only way to win is not to play.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
|
After much discussion we've chosen to play Orthrelm - OV[^] because we think it will help patients to relax
|
|
|
|
|
In fact they will be so relaxed because they are dead after that
|
|
|
|
|
You can't be stressed if you're dead and you won't need the surgery either, it's a win-win
|
|
|
|
|
The symptoms you describe are not surprising, given the music you listen to
p.s. the only known cure requires a year of total silence.
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
I listen to a very wide variety of music, so I have no idea what you mean... Could it be the classical music?
|
|
|
|
|
Message Removed
modified 12-Aug-19 8:17am.
|
|
|
|
|
Message Removed
modified 12-Aug-19 8:17am.
|
|
|
|
|
as if LALR(1) table generation wasn't ugly enough, the operation takes *minutes* to generate tables for on my machine for the Javascript grammar i'm using.
Gold is faster at that, and I largely know why, but it still takes a long time.
So now I get to take this nasty, CPU bound op and spread it across multiple cores.
And i have no idea where I'm going to start. This is a bear, and everything is interdependent.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Have a look at OpenMP[^]. It is very easy to use.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
I'm fine using tasks. It's more about where to break the algorithm apart - I'd need to solve that with OpenMP too, but thanks for the head's up.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Adding extra brackets around your single-line if-statements will greatly improve performance
|
|
|
|
|
LIES!
Brackets Braces take CPU cycles
Edit: Now look what you've done. you've got me calling braces brackets.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
If the computer sees you've put good effort into your code it will do a good effort to run it
Currently your computer is running the same way you've written your code, which is "meh, whatever, no braces no performance"
It's science, duh!
|
|
|
|
|
Actually I just made it a whole lot faster by removing spurious braces.
Seriously though, I did speed it up a lot by implementing a remedial cache, but it's still slow.
Now I'm just reporting progress as I go. That should help.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the monster, codewitch wrote: I did speed it up a lot by implementing a remedial cache My #1 goto when I've got some slow running code
I once gained a performance boost by removing a method and putting the code in the calling method instead.
I think it was a loop, so instead of:
foreach (var item in items)
{
Method(item);
}
private void Method(Item item)
{
} I got:
foreach (var item in items)
{
} It went from over a second to a few milliseconds.
I'm not sure why there was such a performance penalty in invoking the method (probably a few thousand times).
It was an older version of .NET anyway, either 3.5 or 4(.0), I've never seen it since.
If you're dealing with an ORM, going to a manually written query (or completely ditching the ORM at that point) can also greatly boost performance.
And the difference between a debug build and a production build can sometimes be pretty big as well.
Fixing performance bottlenecks can be fun and rewarding, but it can also be a real PITA
|
|
|
|
|
Yeah, the difference between Debug and Release performance on my FA code is phenomenal.
Speaking of performance, I got this routine pretty fast. Turns out there was one area in my code that wasn't using the cache because it was older code.
Fixed, and boom, free perf!
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
5GB to backup!
internal SSD to external SSD on USB 3.1 gen 2
20 seconds including time to grab and plug in and out the external.
and being paranoid I always do double backups (and an internal mirror)
... oh the pain!
Message Signature
(Click to edit ->)
|
|
|
|
|
lopatir wrote: internal SSD to external SSD on USB 3.1 gen 2 don't complain... USB 2.0 is still much slower
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
'Taint nothin. We copied 600 and some gigs from one server to another today.
But nothing says Saturday like computer maintenance.
|
|
|
|
|
I just launched my backup batch file before leaving for the evening. Roughly 4TBs worth of VHDs. When I come back, that drive will be rotated with another, which will then also be brought up to date overnight. Since I won't be around (or sleeping), that essentially translates to no real downtime.
My NAS (8TB) doesn't take nearly that long--robocopy is smart enough to skip files that haven't changed. No such luck with VHD files however; if a VM is merely powered up, that's enough to mark the file as changed, so that's a few dozen GBs that get added to the backup pile instantly.
|
|
|
|
|
dandy72 wrote: owever; if a VM is merely powered up, that's enough to mark the file as changed, so that's a few dozen GBs that get added to the backup pile instantly
with virtualbox if you take a snaphot only the latest ss file get's modded.
usually after setting up a vm (o/s, required apps I'll do a double snapshot, want to roll back to clean state or/and add things to the base roll back to the first ss (and do any new "base mods" there). means even then the usually huge base: os & core apps) stays un-modded.
do regular snaps (daily/weekly/monthly depending on how much happens/matters) to keep daily backup fast and sensible. Every half dozen or so snaps merge them back into base+1 or base+2 then take another snap and carry on. (if base+1 snap starts to get too large add another layer.)
it may seem counter productive , a potential performance hit or just somehow bad to have too many snaps, but in fact not at all*. with regard to performance snaps are no different to disk file fragmentation (i.e. on zero seek time media such as SSD no impact at all.)
* the entire block allocation tables always live in the last snap so regardless how many snaps you have, and in which snap the file/block you seek is located it's a O(1) lookup.
BTW, this means any [potential] delays caused by 'having [too] many snaps' are entirely of the host o/s and it's file system. ... which is why serious VM users and almost all providers (including ms [azure]) prefer linux/BSD for VM hosts [way way better large volume/tree file systems].
merging snaps: all merging does is clean out the redundant/previous copies of the same file(s)/block(s) ==> merging snaps only optimizes space, not time, speed or performance. (unless once again a on a sucky host).
OTOH though I also do merging because it looks 'cleaner', and can also take the opportunity to put more descriptive titles on those important snapshots so they won't get so easily lost in a long long long file/snap list. (host disk space is not an issue... yet)
Message Signature
(Click to edit ->)
modified 11-Aug-19 1:35am.
|
|
|
|
|
lopatir wrote: with virtualbox if you take a snaphot only the latest ss file get's modded.
True. I'm familiar enough with snapshot (or checkpoints, as Hyper-V prefers to call them), but I never thought of it this way. You're absolutely right.
Part of my problem, I guess, is that I try to keep everything as a single file so it's simply easier to manage. I bring all my VMs up to date on every Patch Tuesday, and so my "one VHD" is always clean and up to date. I'll only take a snapshot if I'm about to install something temporarily and I want to clean it up afterwards. If I was to take multiple snapshots, then you're right, the base OS (the larger files) would hardly ever change.
But again, I would still prefer to merge everything back into the "base image" after every Patch Tuesday, so that means that base image still changes at least once a month. Hmmmmmmm…
|
|
|
|