D vs Java

[Matthias Spycher]

Dave wrote:
>> 2. Languages like Java have the advantage that they don't expose the 
>> actual layout of objects in memory to the programmer. Any language with 
>> pointers has a disadvantage in the context of dynamic optimization.
>>
> 
> If you're talking about the famous "pointer alias problem" then Java is
> certainly not immune to that (maybe even less so because of all of the
> references floating around).
>

True, but accurate garbage collection is a requirement if you're going 
to scale to support large, long-running applications. C-pointer 
functionality eliminates the potential. The D community might (in the 
future) consider the introduction of a managed D subset that would make 
accurate GC possible.

>> 3. Multicore/multithreaded systems will provide for enough computational 
>> bandwidth for dynamic compilers and GCs to run in parallel with the 
>> programs they operate on. Performance degradation due to compilation at 
>> runtime will become a moot point on server systems very soon.
>>
> 
> A compiler on these systems can be extremely complex, a VM even more so. A
> contemporary case in point is the Itanium compiler (it's not multi-core, but
> supposed to operate many pipelines per clock and a big part of that is the
> compilers job). If anything the difference between an Itanium static compiler
> and Java VM's is more pronounced on these systems because of the amount of work
> involved in optimizing for them. Chips like IBM's Cell system will make the
> problem even worse, not better.

I agree it's not easy, especially for asymmetrical multi-core processors 
like Cell. Time will tell. I don't believe dynamically compiled apps 
will consistently beat the equivalent statically compiled program. But 
for many apps the performance difference will probably be similar to 
that between an assembly program and the equivalent C/C++ 
implementation. And that will have to be weighed against all other 
factors, e.g. productivity during development, deployment costs, 
maintenance, etc.

Matthias