Misc questions:- licensing, VC++ IDE compatible, GPGPU, LTCG, QT, SDL

[retard]

Tue, 18 May 2010 15:03:43 -0700, Walter Bright wrote:

> retard wrote:
>> Tue, 18 May 2010 12:13:02 -0700, Walter Bright wrote:
>> 
>>> %u wrote:
>>>> The DMC++ compiler you mentioned sounds interesting too. I'd like to
>>>> compare performance with that, the VC++ one, and the Intel compiler.
>>> When comparing D performance with C++, it is best to compare compilers
>>> with the same back end, i.e.:
>>>
>>>     dmd with dmc
>>>     gcc with gdc
>>>     lcc with ldc
>>>
>>> This is because back ends can vary greatly in the code generated.
>> 
>> What if I'm using a clean room implementation of D with a custom
>> backend and no accompanying C compiler, am I not allowed to compare the
>> performance with anything?
> 
> You're allowed to do whatever you want. I'm pointing out that the
> difference in code generator ability should not be misconstrued as a
> difference in the languages.

It's a rookie mistake to believe that languages have some kind of 
differences performance wise. That kind of comparison was likely useful 
in the 80s when languages and instruction sets had a greater resemblance 
(they were all low level languages). But as you can see from the 
bearophile's link ( http://blog.llvm.org/2010/05/glasgow-haskell-compiler-
and-llvm.html ), there is larger performance gap between a naive and a 
highly tuned implementation of the same language than between decent 
implementations of different modern languages.

Why developers want to compare dmd with g++ is just because they're not 
interested in D or D's code generator per se. They have a task to solve 
and they want the fastest production ready (stable enough to compile 
their solution) toolchain for the problem - NOW. There is no loyalty 
left. Most mainstream languages contain the same imperative / object 
oriented hybrid core with small functional extensions (closures/lambdas). 
You only need to choose the best for this particular task. Usually 
there's only a limited amount of time left so you may need to guess. You 
just have to evaluate partial information snippets, for instance that dmd 
sucks at inlining closures and Java doesn't do tail call optimization.

Ideally a casual developer studies the language grammar for a few hours 
and then starts writing code. If the language turns out to be bad, he 
just moves on and forgets it unless the toolchain improves later and 
there will be a reddit post about it. That's how I met Perl. With years 
of Pascal/C/C++/Java experience under my belt, I learned that Perl might 
be a perfect tool for extending apache with our plugin. Few hours of 
studying (the language) + quite a bit more (the APIdocs) and there I was 
writing Perl - probably really buggy code, but code nonetheless.

There are even languages that consist of visual graphs (the "editor" is 
just a CAD-like GUI) or sentences written in normal english - they don't 
have any kind of link between the target machine and the solution other 
than the abstract computational model. If you encounter a statement such 
as:

  find_longest_common_substring(string1, string2);

you cannot know how fast it is. This kind of code is getting more popular 
and it's called declarative - it doesn't tell how it solves it problem, 
it just tells what it does. It's also the abstraction level that most 
developers are (should be) using. You may ask, if that statement is 
faster in C than in Python. The Python coder could just use the one 
written in C and invoke it via a foreign function interface. The FFI 
might add few cycles worth of overhead, but overall the algorithm is the 
same.