GPU/CPU roadmaps

bearophile bearophileHUGS at lycos.com
Tue Aug 11 02:45:37 PDT 2009


Chad J:

>I'd love to see that, though I worry that the existing C++ codebase (mostly in middleware) is too momentous.  It's like garbage trucks on ice.<

They spend lot of work and money on such code. I don't think they are so fixed on C++. So I think they are willing to change languages (to D) if they see D as good enough for their purposes.

They need a compiler able to produce efficient code (LDC is almost there), a profiler, debugger, code coverage, a well debugged language. Some editor support for D (a really good IDE isn't strictly necessary). First of all they need a language that's able to do in a simple way what they need, this means using Intel Larrabee efficiently and GPUs in a simple enough way. A language that's not designed to replace scripting languages (like Lua, Python, etc) but to work well beside them. A language that allows to use software transactional memory in a handy way, and to use a lot of data parallelism instructions efficiently and with a good enough syntax. A language that's safer, with less corner cases and that allows to write concurrent code that's much less buggy (here the type system helps a lot, like the non-nullability by defaulf of class references).

Currently the D2 language isn't much designed for such things.
Give them such things and I think they are willing to leave C++ for D in a short time :-)

Bye,
bearophile



More information about the Digitalmars-d mailing list