5 ms·
The purpose of using a VM is that the developer ships one version of their compiled software that can be run by anyone who has the VM on their system. Otherwis
by andymcsherry 13y ago
The purpose of using a VM is that the developer ships one version of their compiled software that can be run by anyone who has the VM on their system. Otherwise, the developer needs to anticipate every single architecture a user might want to run it on. They might not be able to anticipate all these cases which might not even exist yet.
- sneak 13y agoA fat binary with both common native architectures and also vm code would seemingly take care of this edge case, no? Also, what's wrong with emulation?
- emn13 13y agoIt's slow, complex, and unnecessary?
- sneak 13y agoWhat about when it's a machine for which hardware doesn't actually exist... like a virtual one? How is that less unnecessary?
- emn13 13y agoI wouldn't call a JIT compiler an emulator. However, it's certainly unnecessary (why not just generate the machine code already?), and it generates slower code because JIT compiling is a more difficult task due to the fact that the time limits on the optimizer itself are pretty harsh.
- voidlogic 13y agoThere is also the Go approach, which is your code is platform independent, but you need to compile it for each platform. You get native code that is portable, best of both worlds. (Some might argue "Good C" can do this, but that is often quite hard and C doesn't have the kind of stdlib that Go has..)
- beefsack 13y agoI'd call that the static compiling approach, not just the Go approach. It's possible to statically compile in a wide range of languages.
- voidlogic 13y agoI was using Go as an example of this. The majority of statically compiled languages don't support compiling the same source code to a multitude of platforms. The same Go code and be compiled for x86, amd64, ARM and runs on Linux,OSX,Windows,FreeBSD,OpenBSD,NetBSD,Dragonfly,NaCL,Solaris and Plan 9. Not many statically compiled languages pull that off.
- pjmlp 13y agoYou can only pull that off in Go as long as you only use the runtime library, which is no different than other language. As soon as you bring a third party dependency, game over.
- voidlogic 13y ago>>As soon as you bring a third party dependency, game over. There are tons of 3 party libraries written in pure platform portable Go that will cause you no issues. In fact the vast majority of 3rd party Go libraries are just as portable as the stdlib.
- pjmlp 13y agoSo they provide implementations on all targets supported by Go compilers for the features required outside stdlib?
- voidlogic 13y agoThe point is they don't have to- while Go compiled binaries are platform specific, pure Go code is platform independent. That means any platform that runs "go build" can run your Go program.
- pjmlp 13y agoYou don't need a VM for that, just as portable assembly kind of. OS/400 binaries use portable bytecodes which are compiled into native code at installation time. Alphas had binary translation between binary formats.
- josephcooney 13y agoFrom your description that sounds very similar to NGEN-ing your .NET apps during install time, which is a bit fiddly but one .NET deployment option.
- pjmlp 13y agoYes, however ngen has the caveat that the required .NET version has to be present on the system.