D vs Java

[Dave]

In article <dvs40o$1amc$1 at digitaldaemon.com>, Matthias Spycher says...
>
>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

Good points... I'm not so sure accurate GC can't be done on non-raw-pointer data
with D as-is. Conservative collectors for C/C++ as they are of course is a must,
but I'm not so sure w/ D because the compiler/GC interface can be synchronized.
Don't ask me to expound on it because I can't, just something in the back of my
tiny mind somewhere. <g>

- Dave