D vs Java

Roald Ribe rr.nospam at nospam.teikom.no
Wed Mar 22 00:17:12 PST 2006


Def wrote:
> 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 I see it, there's no technical reason why a static compiler couldn't do the
> same with run-time checks for different CPU versions, cache sizes, current
> system load, etc. and invoking different code versions accordingly. To prevent
> bloat such alternative code sections could even be loaded dynamically into RAM.
> It's just that it is a whole lot of work to implement such a compiler.
> But I'm sure Walter is already working on this... ;-)

In the dynamic compiler case, the VM/compiler could be written 20 years
later than the program itself, optimizing for a CPU/Arch that the developer
team had never heard of at the time the program was developed.
A static compiler could never do anything like that.
(given that source code is not available)

Java can be statically compiled with gcj (with some limitations).

I see no reason why a D compiler could not produce instructions for
a VM/dynamic compiler like .NET/Mono/JVM. In fact I think a
D compiler should have that as a codegen option, to give developers/
users as much flexibility as possible. It would also be a very good
temporary measure until a native compiler exists for all platforms.

Roald



More information about the Digitalmars-d mailing list