6 ms·

There were many years when any hardware computing acceleration card failed pretty quickly because CPUs were advancing so rapidly hardware could not keep up. App

by mchahn 11y ago

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.

oldmanjay 11y ago
I feel like I missed your point, in what way are GPUs and FPGAs hardware that CPUs are not?
- kbob 11y ago
  GPUs and FPGAs are accelerators. CPUs are not.
  - grkvlt 11y ago
    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...
0x07c0 11y ago
+1 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.
- sitkack 11y ago
  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.
  - 0x07c0 11y ago
    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.
    - sitkack 11y ago
      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.pdf http://www.graphics.stanford.edu/~hanrahan/talks/dsl/dsl1.pd... http://www.graphics.stanford.edu/~hanrahan/talks/dsl/dsl2.pdf 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 http://terralang.org/snapl-devito.pdf

by mchahn 11y ago

oldmanjay 11y ago

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

kbob 11y ago
GPUs and FPGAs are accelerators. CPUs are not.
- grkvlt 11y ago
  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...

0x07c0 11y ago

+1 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.

sitkack 11y ago
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.
- 0x07c0 11y ago
  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.
  - sitkack 11y ago
    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.pdf http://www.graphics.stanford.edu/~hanrahan/talks/dsl/dsl1.pd... http://www.graphics.stanford.edu/~hanrahan/talks/dsl/dsl2.pdf 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 http://terralang.org/snapl-devito.pdf