Hacker News Reader

Comment by mchahn | Hacker News Reader

There were many years when any hardware computing acceleration card failed pretty quickly because CPUs were advancing so rapidly hardware could not keep up. Apparently we have reached an end to this. With GPUs, and things like this FPGA integration, hardware matters again.

View on HN

Before the difference between highly optimized code and ok code was maybe 2-3x speedup. Roughly one Moore's law doubling. With heterogeneous computing that is more like 20-30x or more. And Moore's law is dead! This will change a loot in the IT world (More servers are the solution, developer time is more expensive then computer time, etc..). Learn C, down on the metal programming is back, the future is heterogeneous parallel computing.

No, native won't help you. Native is a red herring. C is not the correct abstraction level to take advantage of heterogeneous parallel hardware. The advantage of Rust isn't that it is native, the advantage is that removes the GC and the pressure on the memory subsystems and the latencies involved in compaction. The Hotspot JIT produces code as fast or faster than a C compiler. One could design a language that is high level and removes the GC through an affine type system. I predict there will be a hybrid language that does gradual-affine typing that marries a GC, escape analysis and use at most once semantics.

I wish that to be true, but that is not what I'm seeing. (I'm doing HPC.) . It's not about native c performance vs some other language. Its about the the low level stuff you can do in C. You use avx (and the compiler don't help(they are supposed to, but don't do it very well), you have to use intrinsics or asm), then memory stuff, cash blocking, alignment, non temporal stuff. Same for CUDA, compiler don't get that much performance. You have to think about all low level stuff, usually memory, like alignment, use shared memory or not, cash line size etc.. . And then you are using multiple GPUs.. No help from compiler, you have to do all by your self. Had been nice with compiler doing it, and there are some compiler that helps. But you don't get max performance, and with some effort the performance you get by handcoding all this stuff is much greater then what compilers can give you. And that advantage is increasing.

Ok, maybe it isn't a question of C and native, but access to low level semantics, memory layout and specialized instructions. The majority of programs and programmers are better served by going with a higher level, easier to parallelize semantics than dropping down to architecture specific features. I am thinking Grand Central Dispatch vs assembler.

I would argue that the low level work you are doing should be done in a macro or compiler.

http://www.graphics.stanford.edu/~hanrahan/talks/dsl/dsl1.pd...

http://www.graphics.stanford.edu/~hanrahan/talks/dsl/dsl2.pd...

Pat Hanrahan makes a compelling argument for using special purpose DSLs to construct efficient performant code that takes advantage of heterogeneous hardware.

See the Design of Terra, http://terralang.org/snapl-devito.pdf

Thanks! This are really useful. (I'm actually now making a small dsl for distributing work on accelerators.)

I personally really like the idea from the the Halide language, having one language for algo, another for how the computation is done. If something like that could be made general purpose it would be very useful.

http://halide-lang.org/

>should be done in a macro.. Encourage c programmers to use macros is like encouraging alcoholics to drink :) But I guess you didn't think about pre processor macros.

I find halide really interesting. Like the split between control and data planes. It made me realize we conflate things and don't even realize that they can be separated.

>...macro

Yeah, I didn't have preprocessor macros in mind. ;*| But wonderful, AST slinging hygienic Macros!

Take a look at http://aparapi.github.io/ it one of the best examples of making OpenCL a first class citizen in Java.

I feel like I missed your point, in what way are GPUs and FPGAs hardware that CPUs are not?

GPUs and FPGAs are accelerators. CPUs are not.

I think his point was that accelerators have the same problems: it used to be that 18 month's ago's accelerator is obsoleted by today's due to Moore's law. This is no longer true, so todays accelerator is as good as the next iteration. Of course, I guess what you mean though, is that the future is in developing different, new accelerators for specific niches. So your future compute system is modular, with an accelerator module bus, and plugged into it cards for managing graphics, physics, fluid dynamics, I/O, crypto and so on. You could build a system tailored to your workload...

Reply on news.ycombinator.com