[sitkack]

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]

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]

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

[0x07c0]

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.

[sitkack]

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.