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