Hacker News Reader

Comment by pjmlp | Hacker News Reader

Native compilation! This are great news.

Never got the point why Java and .NET adopted a VM approach, back in the days when we already had safe systems programming languages like Modula-2, Modula-3, Oberon, Ada, Delphi with AOT compilers on their canonical toolchains.

View on HN

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.

There 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..)

I'd call that the static compiling approach, not just the Go approach. It's possible to statically compile in a wide range of languages.

I 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.

You 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.

>>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.

So they provide implementations on all targets supported by Go compilers for the features required outside stdlib?

The 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.

You are avoiding to answer the question.

There isn't pure Go code if it requires to touch the file system, talk to OS using APIs not available in the stdlib.

The moment you depend on libraries outside stdlib, you are opening yourself to dependencies to cgo and/or OS syscalls outside your control.

Even some stdlib packages are UNIX specific, e.g. os.user and log.syslog.

>You are avoiding to answer the question.

I'm really not, I am missing your point.

The majority of 3rd party Go code simply uses the Go stdlib just like our hypothetical program.

Go is no less platform independent then Java, for example, yes there are some 3rd party Java libraries that use JNI, just like some Go libraries use cgo.

The fact that these native bindings to (often) platform dependent code exist does not make pure Go/Java programs non-platform independent.

Maybe our misunderstanding is what we mean my 3rdp party libraries, I'm thinking of the Go repos people put on github or the Gorilla project (http://www.gorillatoolkit.org/), I am not talking about using cgo to call glibc or something similar.

> Maybe our misunderstanding is what we mean my 3rdp party libraries, I'm thinking of the Go repos people put on github or the Gorilla project (http://www.gorillatoolkit.org/), I am not talking about using cgo to call glibc or something similar.

The thing is, there aren't first and second class 3rd party libraries, all are 3rd party.

Back in the day all languages allowed this.

Go design leaves a lot to be desired, but at least it is a way to show the younger generations that didn't learned the above listed languages, how memory safe languages can be compiled to native code without a VM in the middle.

You 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.

From 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.

Yes, however ngen has the caveat that the required .NET version has to be present on the system.

A 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?

It's slow, complex, and unnecessary?

What about when it's a machine for which hardware doesn't actually exist... like a virtual one? How is that less unnecessary?

I 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.

One good reason to use a VM - JIT's can generate very very fast code. Hotspot has gotten so good that there are several cases where numeric java code I've written is faster than reasonably tuned C.

Can you show us some Java code that's faster than reasonably tuned C compiled with a good C compiler with all optimizations on? Performance issues in Java are often related to memory management and lack of control over the layout of your objects and JITs also have real-time constraints, you can't sit all day while the JIT does it's thing.

I do machine learning, I don't particularly care about object layout - almost everything I deal with is just arrays of floats, doubles, or longs. I'm also not bothered by GC issues as I simply iterate over the same arrays many times. Lastly, with the type of code I run, JITing of hotspots is done long before the first iteration over the data is complete.

A coworker bet that java would be within 30% of similarly structured c code. I didn't believe him, so I rewrote two of my companies computationally expensive algorithms; a variant of matrix factorization and a neural network.

The production version of the C code did some tricks that would not be possible in java, so I rewrote the C versions to be a bit simpler. I then ported the simpler C programs to java, a fairly straight forward and mostly mechanical job.

The MF code was 5-6% slower than in C, the RBM code was about 1% faster than C.

Granted the tricks I was able to exploit in the production versions made those versions decisively faster than the simple java version, but java was and is much better than I realized.

I'd be interested in seeing the code. I guess my perspective is that with C++ or C getting something to run fast is a process. The first naive implementation will run pretty fast with a good compiler but then you whip out the profiler and look at the generated assembly. It's not just the language it's also the tooling. As an example, you might find that to make good utilization of SSE you want to process multiple matrices concurrently. You may arrange your input data such that you can quickly load the corner element of 4 matrices into an SSE register. You may further rearrange things so that you hide the latency of certain instructions. A good compiler can do some of that for you but the biggest thing is having visibility and being able to exert control at this level. This is often an order of magnitude difference in performance.

Now with a VM you can't really do that. Even if you could for a given implementation of the VM you might get terrible performance somewhere else. The run anywhere VM approach means you're giving up the ability to fine tune things and there's really no way around that. All you can do is try to minimize the impact and I guess JIT is one way. It's certainly true it's a lot faster than it used to be but presumably there are some sweet spots, patterns the JIT is very good at, and some less than sweet spots, patterns where it's not, and your visibility and ability to engineer things is reduced...

So, you wrote the C code to be slower, and then Java seemed fast? :-) I do numeric software for a living - similar to you: lots of arrays allocated once and iterated over. It would be great if Java could cut it, but I'll never believe when Java people claim that it's nearly the speed of C until they show me a Java FFT that compares to FFTW. One simple benchmark, and I'll believe the Java believers.

I work on ml code as well.

one awesome trick the jit does is in the case of child classes with virtual functions, if there is only one child class used in a run, it can remove the virtual-ness and inline the function used.

so, for example, one place you would see this is if you have distributions, and eg class Distribution has a virtual member function like deviance or some such. However, for a given run of your code, you only ever use one distribution. Also say that the loop that uses the deviance is hot enough that you can see the slowdown from the vtable and the function call. The java jit will inline the deviance function for the distribution you use (assuming the method is small enough, which it often is). The only way to get this behavior in c++ is to lift the decision out of the hot loop and generate one function for each distribution. I've done this and seen noticeable performance gains (10-15% on hours/days long runtimes), but it does not make the code nice to work with.

Very much true, but Sun had to pump lots of research money to make it so.

Had it been an optimizing compiler since day one, it wouldn't had to be like that.

Well... A lot of hotspots potential comes from runtime profiling, this is not necessarily the same as having an optimizing compiler generating code at compile time.

Modern C compilers have profile guided optimization for that. You run your code, profile it, and the optimizer uses that data in the next pass. So this is something you can get without a JIT compiler.

In my experience, PGO is something that relatively few C/C++ programmers know about or at least use... roughly the same percentage of java programmers know how JIT works. But all java programmers get to benefit from JIT.

Don't get me wrong, a lot of java bugs the hell out of me and I'm personally much more comfortable writing c++. I'm just pointing out that a code running on a virtual machine isn't some horrible back water.

Reply on news.ycombinator.com