Re: [TUHS] PDP-11 legacy, C, and modern architectures

Thanks for the promotion to CTO Clem! I was merely the software architect at Sicortex. The SC systems had 6-core MIPS-64 cpus at 700 MHz, two channel DDR-2, and a really fast interconnect. (Seriously fast for its day 800 ns PUT, 1.6 uS GET, north of 2 GB/sec end-to-end, this was in 2008.) The achilles heel was low memory bandwidth due to a core limitation of a single outstanding miss. The new chip would have fixed that (and about 8x performance) but we ran out of money in 2009, which was not a good time to look for more. We had delighted customers who appreciated the reliabiity and the network. For latency limited codes we did extremely well (GUPS) and still did well on the rest from a flops/watt perspective. However, lots of commercial prospects didn’t have codes that needed the network and did need single stream performance. We talked to Urs Holtze at Google and he was very clear - they needed fast single threads. The low power was very nice, … but we were welcome to try and parallelize their benchmarks. Which brings me back to the original issue - does C constrain our architectural thinking? I’ve spent a fair amount of time recently digging into Nyx, which is an adaptive mesh refinement cosmological hydrodynamics code. The framework is in C++ because the inheritance stuff makes it straightforward to adapt the AMR machinery to different problems. This isn’t the kind of horrible C++ that you can’t tell what is going to happen, but pretty close to C style in which you can visualize what the compiler will do. The “solvers” tend to be Fortran modules, because, I think, Fortran is just sensible about multidimensional arrays and indexing in a way you have to use weird macros to replicate in C. It isn’t I think that C or C++ compilers cannot generate good code - it is about the syntax for arrays. For anyone interested in architectural arm wrestling, memory IS the main issue. It is worth reading the papers on BLIS, an analytical model for writing Basic Linear Algebra libraries. Once you figure out the flops per byte, you are nearly done - the rest is complicated but straightforward code tuning. Matrix multiply has O(n^3) computation for O(n^2) memory and that immediately says you can get close to 100% of the ALUs running if you have a clue about blocking in the caches. This is just as easy or hard to do in C as in Fortran. The kernels tend to wind up in asm(“”) no matter what you wish for just in order to get the prefetch instructions placed just so. As far as I can tell, compilers still do not have very good models for cache hierarchies although there isn’t really any reason why they shouldn’t. Similarly, if your code is mainly doing inner products, you are doomed to run at memory speeds rather than ALU speeds. Multithreading usually doesn’t help, because often other cores are farther away than main memory. My summary of the language question comes down to: if you knew what code would run fast, you could code it in C. Thinking that a new language will explain how to make it run fast is just wishful thinking. It just pushes the problem onto the compiler writers, and they don’t know how to code it to run fast either. The only argument I like for new languages is that at least they might be able to let you describe the problem in a way that others will recognize. I’m sure everyone here has has the sad experience of trying to figure out what is the idea behind a chunk of code. Comments are usually useless. I wind up trying to match the physics papers with the math against the code and it makes my brain hurt. It sure would be nice if there were a series of representations between math and hardware transitioning from why to what to how. I think that is was Steele was trying to do with Fortress. I do think the current environment is the best for architectural innovation since the ‘90s. We have The Machine, we have Dover Micro trying to add security, we have Microsoft’s EDGE stuff, and the multiway battle between Intel/AMD/ARM and the GPU guys and the FPGA guys. It is a lot more interesting than 2005!