[qwerty456127]

Why do we need more computer power? I haven't upgraded my laptop since 2009 (well, I've replaced its HDD with an SSD 2 years ago and it made a huge difference) and I'm okay. Some people insist on photorealistic 3D graphics in the games they play, I agree that's cool but wouldn't say that's anything close to important.

[tluyben2]

> Why do we need more computer power?

A lot of the latest revolutions (good or bad, that's up to the reader); crunching huge data, ML, every more realistic simulations etc comes from every faster machines. If that growth stops, the article suggests we do something that was (and still is in some circles) normal in the 70-80s with homecomputers and consoles; because you could not upgrade the hardware and almost nothing was compatible (which is the most common reason the IBM PC won) to the next generation, you optimised the software to get everything from that existing hardware you had on your desk. And people are still doing that.

One of my personal miracle examples; my first love was the MSX computer, which is a Z80 3.58mhz computer with (in my case) 128kb in it. This machine could do nice games for the time and some business applications. Many years later, that same physical hardware (I still have my first one) can do this [0]. Obviously the hardware was always capable of doing this, but it needed many years (decades) for programmer(s) to figure out how to get every ounce of performance and memory utilization out of these things and push it beyond what anyone thought possible.

If the improvements in performance stagnate, there is a lot of room for getting most out of the existing hardware. I would think though that in the case of modern hardware, the geniuses that get to that point will get some language to compile to this optimised optimum instead of having to handcode and optimise applications like the Symbos guy did.

[0] http://www.symbos.de/

[leetcrew]

do you ever compile code? at work I have a machine with an i7-7700 (4C/8T), 32GB of RAM, and an SSD. it still takes about 45 minutes to do a full build of the project I work on, which can easily be triggered by modifying any of the important header files. if I had to do my job on your laptop from 2009, I'd never get anything done.

[rs23296008n1]

That is the choice of software tool. You are literally grinding through gigabytes of data. If your tool didn't require so much data processing it would be faster. This may or not be possible to improve by you. Often there are workarounds.

Case in point: a matrix library I used to use needed to a full row/column pass each time. We put a layer in between it and our code. Reduced lookups required by 30%. We were processing the same amount of data and getting the same results but requiring far less time. That layer also reduced memory requirements. Now we could process larger datasets faster with the same hardware. Thats just one example.

Your choice of CPU and other hardware isn't always the limiting factor. Even the language choice has an impact. Some languages/solutions require more data processing overhead than others to get the same final result.

Even the way your program's Makefile or module composition can have an effect on compiling performance. I remember the use of a code generator we included that meant it had to regenerate a massive amount of code each run due to its input files being changed. We improved it by a ridiculous amount simply by hashing its inputs and comparing the hashes prior to running the code generator. Simply not running that code generator each time meant we sped up the build significantly. 30 minute build times reduced by 5-10 minutes. Same hardware. And that was easily triggered by a trivial file change.

[leetcrew]

I understand your point, I think. c++ has an inefficient build system, and over time projects can end up with very suboptimal build systems. it's definitely worth spending time to pick the low-hanging fruit like in your example, or if possible, to choose a language that builds faster.

still, even twenty minutes is a long time to wait and see if your latest change actually works. in the foreseeable future, there will be complex projects that take a long time to build. you will eventually have to touch things that everything else depends on and recompile most of the code. people that work on these projects can always benefit from faster desktop-class hardware.

[pdimitar]

That's just picking the lowest hanging fruit which is quite common sense. Not to diminish your achievement but if tomorrow, say, I figure Rust's compiler is slow, there's nothing I can do [in the foreseeable future].

Having much better hardware in these cases helps you be actually productive and not twiddle your thumbs waiting for the compiler.

[billti]

Came here to say exactly this. I’m waiting for Amazon to deliver the new CPU cooler I ordered today so my i9-9900k can run flat out for longer when building, after I spent so much of yesterday waiting 20 mins for another build when my attempted fixed didn’t pan out. (Though probably more of a reflection on how painful C++ as a language is if you have to touch a common header file).

[leetcrew]

obviously the whole "textually including header files" model introduces a lot of overhead in compilation, but as I understand it, optimizations are inherently expensive. if you want to do stuff like inlining across module boundaries, full rebuilds are inevitable when you touch commonly used code. I think it's reasonable to expect that compiling optimized builds of complex code will always hunger for more compute power.

[qwerty456127]

No, indeed I don't. It has been a long time since I've started actively avoiding C and C++ because it takes too long time to compile. Nevertheless I used to compile reasonable amounts of C# until recently and it wasn't a problem. Nowadays I mostly use write-and-run scripting languages like Python and build-free vanilla JavaScript.

[jryb]

It’s critical for a lot of scientific and industrial applications. Too many things just can’t be done without a supercomputer.

[btrettel]

I disagree. I did my masters' on computational fluid dynamics (CFD) and I'd say that a large fraction of supercomputer use (in fluid dynamics at least) is wasted. Mostly because people take naive approaches and end up computing the wrong thing, set up their simulation poorly, reinvent the wheel, use HPC on something that can be computed by hand, etc. If they read more of the literature they'd have a more solid grasp on things and use the software much more efficiently when they do use it.

My philosophy at the moment is to use HPC only when I've exhausted other possibilities. I think many people jump to HPC prematurely. The simpler approaches are so much cheaper that I think it's usually worthwhile. I'm skeptical of the argument that it's cheaper to use HPC than it is to use more efficient methods in this case, because the more efficient methods are often something like a few days spent reading to find the right equation or existing experimental data vs. at least that much setting up a simulation and longer to run it.

Edit: Bill Rider has a bunch of blog posts that make similar points:

https://wjrider.wordpress.com/2016/06/27/we-have-already-los...

https://wjrider.wordpress.com/2015/12/25/the-unfortunate-myt...

https://wjrider.wordpress.com/2016/05/04/hpc-is-just-a-tool-...

https://wjrider.wordpress.com/2016/11/17/a-single-massive-ca...

https://wjrider.wordpress.com/2014/02/28/why-algorithms-and-...

[rs23296008n1]

Many moons ago when Beowulf clusters were still new, I remember a project where I was given a months worth of then new cluster time to spend. Due to a delay we had to wait a few months before we could exercise it. One weekend I was playing around with some junk computers I'd assembled for a LAN party. Long story short, I tried out a portion of the project on that LAN, got a useful result then we ran the rest of the project on that overall system and joined more machines. We completed the project using no special machines, often just idle machines added and removed upon their availability. Along the way we rewrote the entire project code as a set of modules then used python to orchestrate them.

None of this is extraordinary now but the result was we reduced multiple times the budget requirements and processing times just using code improvements. A lot of times, the head-on solution just needed optimisation. Sideways improvements also helped such as small optimisations also helped. The more exotic equipment is still useful but its an accelerator.

One last thing: we received a LOT of grief and criticism for our approach. There was peer pressure to use particular solution types even though they were wildly inappropriate. We had funding pulled or threatened to be pulled by some and other backers. One lessons we learnt includes: Don't underestimate how vested certain interests are for the use of various toolkits. "Use this or else!" is the not-so-subtle threat.

I'm so glad to not rely on only academic work now.

[pinewurst]

This is _so_ true! I remember a few years ago interviewing for a position where the largest supercomputer in the area was being used to run Perl programs. Of course the place I ended up working was running Python at supercomputer scale and running out of I/O bandwidth because of all the naive Python runtime startup crud.

[jryb]

This may be true for some fields, but it's certainly not true for all fields. I'd be surprised if there are still orders-of-magnitude improvements to be discovered for BLAST, for example, and that's a foundational component of modern biology.

I should have spoken more generally to OP's point though. What I was really hoping to get at is that there are applications other than games that require non-trivial amounts of compute, and speeding them up would make meaningful differences in their users' lives.

[qwerty456127]

Can these areas really be optimized on the code level? Aren't serious computation algorithms already implemented the best way known to computer science and optimized to the hardware architecture? I agree most of the software is bloated but I don't know if scientific computation software in particular is.

And by the way I believe the software code is not the only place which could be made more efficient. What if we removed all the legacy stuff from the x86 architecture - wouldn't it become more efficient? What if we designed a new CPU with a particular modern programming language and advanced high-level computer science concepts in mind - wouldn't it make writing efficient code easier?

Also, what are the actual tasks we need so much number-crunching power for, besides things of questionable value like face recognition, deep-fake, passwords cracking and algorithmic trading?

[btrettel]

Computational fluid dynamics software rarely is implemented in the best way known to computer science and optimized to the hardware architecture. There's a compromise between development and run time here. Plus, how to optimize the software is an active area of research that often combines both computer and physical knowledge.

[zozbot234]

How many 'serious computation algorithms' are written in FORTRAN 77? They may be "implemented the best way known to computer science and optimized to the hardware architecture", but they're also a full 40 years (and counting) out of date.

[thewarrior]

Virtual reality and augmented reality

[jdnenej]

I'm doing VR on a 6 year old i7 and it runs perfectly fine. Improvements come almost entirely from updating the gpu

[imtringued]

There won't be many GPU upgrades left if the manufacturing processes don't improve. GPUs are much closer to the theoretical performance you can squeeze out of a piece of silicon than CPUs.

[jdnenej]

I doubt it. My new gpu released in 2019 is 3x as powerful as my 2013 gpu but the new CPUs are mostly only improved in core counts.

Rendering is also an insanly parallelizable task. In the worst case we can always slap 2 of the same gpu on one card and get them to render half the screen or for vr, one gpu per eye.