D vs Java

Dave Dave_member at pathlink.com
Wed Mar 22 07:24:57 PST 2006


In article <dvpq5q$1be1$1 at digitaldaemon.com>, Matthias Spycher says...
>
>1. A dynamic compiler knows about the architecture of the machine, e.g. 
>cache sizes; and the profile of the running application, e.g. I/O 
>boundedness. The data path is likely to be the main bottleneck in coming 
>years.
>

As someone else pointed out, there is no reason why this can't be done in static
compilers - as it is now by GCC, Intel C/C++/Fortran and MS VC++ and probably
several other high-perf. compilers.

>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).

If your talking about memory, see:
http://www-128.ibm.com/developerworks/java/library/j-jtp06243.html

>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.

>4. The ability to run multiple applications in the same runtime context; 
>i.e. sharing the heap, the GC and the dynamically compiled bits of code; 
>will reduce the overhead (which today is clearly a big issue for certain 
>applications). Such a feature will be more easily implemented for a 
>language like Java than D.

Perhaps, but there will also be much more 'context switching' and
synchronization, and there will always be an overhead involved there.





More information about the Digitalmars-d mailing list