21–30 of 54 posts
Something I like thinking about: Your computer can (probably) perform a few dozen arithmetic operations or a few stores/reads in the time light leaving your monitor takes to reach your eye balls. edit: not to mention GPUs
I just had to do arithmetic. A 3 GHz processor would clock about 10.006671 cycles in the time it takes for light to travel 1 meter.
Earlier quoted context omitted.
I blame I/O. It's pretty fast warmed up.
Sometimes I wonder if the OS can put very heavily used files from the FS into RAM. Some software just sucks and keeps pulling the same files over and over... ... and the plus side is, if an application needs the RAM, no harm done, just dump the file from RAM and read it from disk.
Something I like thinking about: Your computer can (probably) perform a few dozen arithmetic operations or a few stores/reads in the time light leaving your monitor takes to reach your eye balls. edit: not to mention GPUs
Light travels about 1 foot/nanosecond, so the travel time from monitor to eyeball is 1 or 2 nanoseconds, which might be 2 or 3 clock cycles. So I think at most 3 operations per CPU.
Something I like thinking about: Your computer can (probably) perform a few dozen arithmetic operations or a few stores/reads in the time light leaving your monitor takes to reach your eye balls. edit: not to mention GPUs
I don't think so. Light travels about 1 foot/nanosecond, so the travel time from monitor to eyeball is 1 or 2 nanoseconds, which might be 2 or 3 clock cycles. So I think at most 3 operations per CPU.
I sometimes feel bad that I'm not more of an "algorythms developer", that I don't read all(any) research papers, that I don't remember what RedBlack Trees are, that other than minimal attention to using decent basic structures and reasonable bigO operaions (e.g hashes, don't pop of front of array in loop) when I sit down and code I invariably brute force it. OTOH, I encounter the "computers are fast" phenomenon 9 out…
I'm on the other side of your situation. These days, nine out of ten times I'm looking at papers, algorithms, lots of paper with big-O and cache nitpicking, brainstorming with others trying to make those 20 Gbps turn to 60.. Speed is a direct product of simplicity, and for me simple is elegant. I also think speed is important enough for me to feel strongly about cutting down a "feature" or two, to just make the damne…
When I put on my kernel dev hat or when I was working on SQL Server I spent all day making sure other me could throw data around haphazardly and not get stuck on a course-grained kernel lock or only hit 1/8 of the pipelines.
Sometimes it's just too much to handle all at once, even if you know what you're doing in both domains.
Earlier quoted context omitted.
I/O is one of my biggest daily pains. Spend some time in Process Explorer on Windows and you can see just how much disk-based I/O the average app is doing. Anti-virus software makes the bad problem worse. It's just like pouring sugar in a gastank. Why isn't more software designed to take advantage, where appropriate, of large amounts of RAM?
Did you see that article on the Varnish site about second-guessing Virtual Memory? "2006 programmng" I think it was.
Varnish dev says second-guessing VM is so 1975: http://news.ycombinator.com/item?id=1554656 OR http://news.ycombinator.com/item?id=1760811
Redis dev says second-guessing VM is elite (and not doing so is so 2006): http://news.ycombinator.com/item?id=1760540
Yes. Computers are fast. Who cares about algorithms... Premature optimization is evil... But why then it is so annoying that Visual Studio starts longer than my whole custom linux system in VM on the same computer...
I blame I/O. It's pretty fast warmed up.
CPUs are fast but the ratio of latency of random access vs. maximum bandwidth is getting worse. In nanoseconds, approximately: 10^7 Disk seek 10^4 2KB over 1Gbps 10^2 RAM uncached reference 10^1 L2/L3 cache reference 10^0 L1 cache reference That's why systems don't feel fast lately. In particular for big data or bloated software that can't fit well within the caches or shared systems doing a lot of frequent switches…
A long time ago I was working on a data conversion project that involved taking what was essentially a 10 dimensional data set and reordering it. The easiest way to achieve this was to load everything into a ten dimensional array and read it out in another order, but I was sure this would take too long. So I spent some time trying to get a sparse array implementation working until I finally sat down and worked out th…
So, prune! as it swapped digits left to right in a Grey-code-like sequence, test the digits to the left for diagonals (|row#A - row#B| == |A-B|) and don't bother to recurse if its already failing.
Every few minutes - out popped a solution, and it finished in under 25 minutes.
Nowadays, that would take imperceptible time to execute.