4 ms·

The point I'm trying to make with the analogy is that the x86 instruction set is not representative of what the hardware is actually doing. It is not "low leve

The point I'm trying to make with the analogy is that the x86 instruction set is not representative of what the hardware is actually doing. It is not "low level" because it is an abstraction or virtual platform that the processor exposes and then interprets using its own internal resources and programming interface (microcode). The x86 interface does not map closely to the actual hardware, just as the article states. It exposes a flat memory model with sequential execution and only a handful of registers. Much the same way that the JVM exposes a virtual machine that doesn't directly map to any of the platforms that it runs on. It's an abstraction that is interpreted or compiled at runtime. I don't understand why you think the two are so different just because the JVM is higher level.

pvg 9y ago
Right, and the point I'm trying to make is this is a pretty lousy analogy. For one thing, an x86 CPU is not nearly as VM-y as you make it out - renamed registers are very much real registers, big piles of the most common instructions execute in 1 or 2 uOps. For another, the VM you've picked as an example is singularly uncpu-like. C also exposes an abstract machine, would you use that as an analogy? Probably not. 'An abstraction that is interpreted or compiled at runtime' is so broad it's exactly the what I said up top - it's analogous in the way everything is analogous to everything else. It's the sort of thing that might be true if you squint but offers somewhere between zero and negative insight.
- admax88q 9y ago
  I don't know I think you're getting caught up too much on the specifics of what they're doing. CPU's are adopting JIT like tendencies in order to increase performance. Instruction reorder, register renaming, branch prediction, etc. > if you squint but offers somewhere between zero and negative insight. The insight I bring from this is that we should look moving those features out of the hardware and into the software level. Let us take advantage of them in our compilers and virtual machines. The JVM can beat C in many scenarios because it can make optimizations based upon runtime information that a static compiler will never have available. Imagine what we could do if we weren't chained to the x86 abstractions.
  - gpderetta 9y ago
    OoO, renaming, branch prediction, microcode have existed for a long time. If anything, more modern CPUs (x86 included) are RISCer than the older generations which had extensive microcode expansion for each instruction. Even ignoring the fact that the JVM is typed, memory safe and with builtin GC (all things that were tried architecturally in the past and abbandoned), there is still a large difference between the scope and variety of non-local optimizations perfomed by any non-toy VM and the local, strictly realtime, constrained to a small window, set of reordering done by an OoO engine. Even tracing, which is used by some JITs, has been largely abbandoned in the CPU world. Transmeta and Denver-like dynamic translation is closer to the behaviour of a software JIT and it is certainly considered drastically different from mainstream OoO.
  - pvg 9y ago
    "x86 is an architecture hobbled by its legacy ISA, the CPUs are immensely complex VM-like dynamic beasts that hide the real CPU to get performance out of it" is one of those tropes that's inaccurate enough to have a small cottage industry of online pieces explaining the wrong bits. You can probably find highly rated SO answers or HN comments about it. The long and the short of it is, an x86 cpu is not really VM-like and a JVM is decidedly unCPU like. The analogy only works if you generalize it so much it becomes a uselessly mushy tautology or you ignore basic aspects of how each of these things work.

pvg 9y ago

Right, and the point I'm trying to make is this is a pretty lousy analogy. For one thing, an x86 CPU is not nearly as VM-y as you make it out - renamed registers are very much real registers, big piles of the most common instructions execute in 1 or 2 uOps. For another, the VM you've picked as an example is singularly uncpu-like. C also exposes an abstract machine, would you use that as an analogy? Probably not. 'An abstraction that is interpreted or compiled at runtime' is so broad it's exactly the what I said up top - it's analogous in the way everything is analogous to everything else. It's the sort of thing that might be true if you squint but offers somewhere between zero and negative insight.

admax88q 9y ago
I don't know I think you're getting caught up too much on the specifics of what they're doing. CPU's are adopting JIT like tendencies in order to increase performance. Instruction reorder, register renaming, branch prediction, etc. > if you squint but offers somewhere between zero and negative insight. The insight I bring from this is that we should look moving those features out of the hardware and into the software level. Let us take advantage of them in our compilers and virtual machines. The JVM can beat C in many scenarios because it can make optimizations based upon runtime information that a static compiler will never have available. Imagine what we could do if we weren't chained to the x86 abstractions.
- gpderetta 9y ago
  OoO, renaming, branch prediction, microcode have existed for a long time. If anything, more modern CPUs (x86 included) are RISCer than the older generations which had extensive microcode expansion for each instruction. Even ignoring the fact that the JVM is typed, memory safe and with builtin GC (all things that were tried architecturally in the past and abbandoned), there is still a large difference between the scope and variety of non-local optimizations perfomed by any non-toy VM and the local, strictly realtime, constrained to a small window, set of reordering done by an OoO engine. Even tracing, which is used by some JITs, has been largely abbandoned in the CPU world. Transmeta and Denver-like dynamic translation is closer to the behaviour of a software JIT and it is certainly considered drastically different from mainstream OoO.
- pvg 9y ago
  "x86 is an architecture hobbled by its legacy ISA, the CPUs are immensely complex VM-like dynamic beasts that hide the real CPU to get performance out of it" is one of those tropes that's inaccurate enough to have a small cottage industry of online pieces explaining the wrong bits. You can probably find highly rated SO answers or HN comments about it. The long and the short of it is, an x86 cpu is not really VM-like and a JVM is decidedly unCPU like. The analogy only works if you generalize it so much it becomes a uselessly mushy tautology or you ignore basic aspects of how each of these things work.