Programmer Humor

RISC was so successful

I would say popular rather than successful, but yeah, I was "actively" in the assembly code around then.

Around 2010 I was working with NIOS cores on FPGAs, which were ultra-flexible (sort of the ultimate microcode embodiment), but not really efficient or performant the way a fixed ARM core is. At the time Xilinx was promising ARM cores on-chip beside the FPGAs "real soon" - it took a while, but they finally delivered and that is a nice arrangement when you need specialized processing, which most projects I have seen implemented with those ARM+FPGA uZed and similar boards don't really need and they can better be implemented on a simple ARM core system, maybe with a few built-in timer-latches, instead.

In the 2007 timeframe we were looking to squeeze performance out of an algorithm to bring an analysis time down from hours to 5 minutes or less, massive parallelism was on the table but expensive - not unaffordable in the application - but unwieldy in the space / bandwidth taken by the hardware. SIMD, MIMD - the compiler optimizers seemed to be doing well enough with those to get what was possible, but we were still over 2 hours. Finally, a code review of the profiler identified bottleneck turned up a queer looking nested loop structure that was causing cache misses on the inner loop. We restructured that and sped things up 100x, 5 minute execution on a laptop, more like 2 minutes on the quad-core workstation target. I think the "chief scientist" was disappointed that we wouldn't be building an array of 100 workstations to crunch the numbers in parallel. RAM is fast, cache is faster.

I'm sure they've run the numbers and strings are better in code than hardware overall - I just constantly instantiate and manipulate string objects and wonder how much that adds up throughout the app execution. I'm going to guess that most string operations are small enough to fit in cache these days, and that's all the help they need.