3 ms·

Why not just run a VM, and use the saved die area for more cache?

by jonmrodriguez 13y ago

sliverstorm 13y ago
'cause cross-platform VM means emulation, and emulation is as a rule 10x slowdown at best?
- pjmlp 13y ago
  JIT at installation time?
  - johnchristopher 13y ago
    Would that be platform independent ?
    - pjmlp 13y ago
      Of course not, the translation engine needs to know how to properly map the op-codes between architectures.
  - InclinedPlane 13y ago
    That's not emulation that's decompilation / recompilation. Which is a very challenging task. TransMeta worked on this under the name of "code morphing". It's a promising technique but I don't think it has the maturity to be able to run cross-architecture code at close to hardware speeds (say, 50% or higher) without introducing new defects, especially x86 on ARM.
    - pjmlp 13y ago
      What you are discussing about, is a runtime issue. I was discussing about installation time, which only prevents situations were you make use of code rewriting tricks, which are anyway frowned upon in the day and age of read-only code sections and no-execute data sections.
  - willvarfar 13y ago
    (Worth mentioning that the fancy new Mill processor takes this approach. It is technically viable, as Transmeta have already proved.)
    - deleted 13y ago
      [deleted]
    - pjmlp 13y ago
      Thanks for the heads up. Putting a link here for those that want to follow up. http://staff.science.uva.nl/~poss/posts/2013/08/01/mill-cpu/ http://staff.science.uva.nl/~poss/posts/2013/08/01/mill-cpu/
InclinedPlane 13y ago
Everyone's always had this idea, and it has very rarely proven to be terribly practical in reality. The few times that VMs of different hardware tend to be practical are when there is an enormous gap in performance between the emulated hardware and the host hardware (such as with old game consoles and arcade hardware).
- jonmrodriguez 13y ago
  Yeah, you're right. It would not match this use case.
- zurn 13y ago
  I don't think it has been tried too many times in practice, because software binary translation is so proven (eg. like in android x86, or rosetta on mac, or fx!32 on nt, etc etc). Itanium is the only one that comes to mind. Any others? Then there are several that have lower level "programmable microcode" kind of level in the hardware, ranging from the Transmeta stuff to mainframe-era writable control store...
quacker 13y ago
Emulating a processor of another architecture will not be as quick as having the hardware, will it?
- jonmrodriguez 13y ago
  Indeed, I guess it depends whether your x86 application is going to be MS Word or some new game. It would be cool if both the ARM and the x86 cores could use the same GPU.

Why not just run a VM, and use the saved die area for more cache?

sliverstorm 13y ago

'cause cross-platform VM means emulation, and emulation is as a rule 10x slowdown at best?

pjmlp 13y ago
JIT at installation time?
- johnchristopher 13y ago
  Would that be platform independent ?
  - pjmlp 13y ago
    Of course not, the translation engine needs to know how to properly map the op-codes between architectures.
- InclinedPlane 13y ago
  That's not emulation that's decompilation / recompilation. Which is a very challenging task. TransMeta worked on this under the name of "code morphing". It's a promising technique but I don't think it has the maturity to be able to run cross-architecture code at close to hardware speeds (say, 50% or higher) without introducing new defects, especially x86 on ARM.
  - pjmlp 13y ago
    What you are discussing about, is a runtime issue. I was discussing about installation time, which only prevents situations were you make use of code rewriting tricks, which are anyway frowned upon in the day and age of read-only code sections and no-execute data sections.
- willvarfar 13y ago
  (Worth mentioning that the fancy new Mill processor takes this approach. It is technically viable, as Transmeta have already proved.)
  - deleted 13y ago
    [deleted]
  - pjmlp 13y ago
    Thanks for the heads up. Putting a link here for those that want to follow up. http://staff.science.uva.nl/~poss/posts/2013/08/01/mill-cpu/ http://staff.science.uva.nl/~poss/posts/2013/08/01/mill-cpu/

InclinedPlane 13y ago

Everyone's always had this idea, and it has very rarely proven to be terribly practical in reality. The few times that VMs of different hardware tend to be practical are when there is an enormous gap in performance between the emulated hardware and the host hardware (such as with old game consoles and arcade hardware).

jonmrodriguez 13y ago
Yeah, you're right. It would not match this use case.
zurn 13y ago
I don't think it has been tried too many times in practice, because software binary translation is so proven (eg. like in android x86, or rosetta on mac, or fx!32 on nt, etc etc). Itanium is the only one that comes to mind. Any others? Then there are several that have lower level "programmable microcode" kind of level in the hardware, ranging from the Transmeta stuff to mainframe-era writable control store...

quacker 13y ago

Emulating a processor of another architecture will not be as quick as having the hardware, will it?

jonmrodriguez 13y ago
Indeed, I guess it depends whether your x86 application is going to be MS Word or some new game. It would be cool if both the ARM and the x86 cores could use the same GPU.