Just my opinion, but I don't think Java is a good example. We have been discussing programming languages in which the compiler emits executable machine instructions that will run without the need of a runtime package. Java doesn't qualify in that sense as a compiled language.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

On the subject of writing optimal code, as a human: it's quite amazing the improvements we saw in the 6502 emulator running on the Raspberry Pi as it received expert attention. Although that expert was a human (AFAIK) I think it demonstrated that most programmers stand little chance of writing optimal programs for modern processors.

Second point, have a look at "Stochastic Superoptimization" - it proves fruitful in some cases to let a machine stew over the enormous search space looking for optimal code sequences:
http://blog.regehr.org/archives/923

Nonsense.

All compiled code have runtimes. Some are as minor as _crt0 and the standard library, statically linked in to the image. Others include more sophisticated capabilities, such as garbage collectors and dynamic module loaders (DLLs, the old DOS overlay managers, etc.), plus all those calls to the local OS. Java's is just a particularly sophisticated runtime. Even Java ME (the Java runtime targeted for embedded applications) includes a JIT layer.

Early Microsoft applications were a combination of native and "p-code". They did this to preserve space.

When the Macintosh switched over from the 68K to the PPC, it ran in a mixed environment, with the 68K code being emulated (and later, dynamically compiled) along side the now-native PPC code. This wasn't just on the application level, but even early system ROMs were a mix of PPC and 68K. The file system primitives were one example that remained in 68K in the early releases. This worked so well, they did the same thing when they moved to the x86. An x86 OS running PPC programs with 68K code in them…makes your head hurt.

The .NET runtime does not compile into "P-Code" like Java does, rather it compiles into an intermediate code that is JIT compiled on load. .NET intermediate code is never "interpreted" like the JVM can do, it always runs native instructions. It's just those native instructions aren't created until the modules are loaded at runtime.

All of these systems were "compiled" in every sense of the word. You can ship Java code with the runtime bundled as a standard EXE file.

LLVM is similar, an intermediate representation that is both statically compiled, and JIT -- yet the host language is simply compiled down in to the LLVM code. Now the compiler writers focus on creating optimal LLVM code while the LLVM creators focus on creating better machine code out of the LLVM intermediate form for the individual CPU sets.

The assertion was that a machine can't create better code than a human. Are there instances where the machine will most certainly be worse than a human? Naturally. But it's no longer a blanket statement that a machine will produce worse code than a human, simply because in many modern scenarios the machine simply has much more information, including dynamic runtime information in some cases, at hand to make better decisions than a human does, particularly in large projects.

[..]
In this I'll have to side more with BDD. There's a vast difference between a runtime library in the form of common routines, e.g. libc for C (and you can in principle write C which doesn't need it. And it's not even any different from any library you write yourself, as part of your program), and a VM-based language like Java where you need a bytecode interpreter. It's at that point it makes sense to throw all kinds of JIT and other dynamic methods at it. And yes, that's a job for a computer, not a human. But for bytecode-based languages it would be better to discuss how best to write the bytecode interpreter.. some hand-optimization there, perhaps? (Of course, when you change the original bytecode interpreter to be dynamic as well, then it's back to the computer. The programmer just thinks about the algorithms to apply.)

Anyway, runtime support != runtime library. Not the same thing.

Hi

Just in case anybody is still interested in this thread, I created a hacked version of JaC64, a java emulator for the Commodore 64, that you can use to run C64 programs while recording the opcodes that are executed by the emulator. From its output, you can run all the analytics you want.

https://github.com/mzattera/JaC64

Welcome! Always good to see a tool which helps in analysis: dynamic stats are much more meaningful than stats from a block of code.

In VICE, IIRC, another reason was cache locality (in early machines, remember, VICE is rather old).

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/