Live data from Hacker News

Why is C faster than Java: git vs JGit

marc.info

61–70 of 106 posts

Re: Why is C faster than Java: git vs JGit

#61

I build fairly high-performance Java code. And get hit with three major gotchas which prevent it from approaching C code. - There's no way to do array access without null pointer and index checks each and every time. - Generics with basic types, and their unfortunate embedding into syntax (like the new for() syntax), are awful. Boxing and unboxing incur a ludicrously high penalty, and generics push coders away from u…

I would also add inability to create objects in stack, if you are doing anything recursive. The overhead of heap object creation is pretty visible. So I had to either reuse objects and essentially create my own memory management layer or try to stick data into primitive types which obfuscated code logic quite a bit.

Re: Why is C faster than Java: git vs JGit

#62
post #7

I find it kind of interesting that in Haskell, which is arguably even higher level than Java, most of these optimisations are eminently possible.. EDIT: This obviously came across a bit as language fanboyism, so I guess I should mention that the language features that let you do many of them let you shoot yourself in the foot just as easily as you can in C, and you can certainly argue that with a strong FFI you might…

That may be, but what good is it if no one uses it? Hadn't heard that http://hackage.haskell.org/package/git-object or http://hackage.haskell.org/package/ght or http://hackage.haskell.org/package/hit or gat http://evan-tech.livejournal.com/254793.html were especially fast.

Re: Why is C faster than Java: git vs JGit

#63
This is an old email... there's been many improvements to both JGit, Java/JVM and other areas of interest.

Shawn and I gave a presentation at the Googleplex not so long ago about JGit [1]. In particular, you may be interested in the 'JGit at Google' section.

There are some cases where JGit is faster than CGit, but the benefits of JGit are that it's easy to embed. There are projects like gitblit and other IDEs that use the library. On top of that, you have crazy folks like NGit [2] who cross compile the library using Sharpen so it can be used by the .NET community...

[1] - https://docs.google.com/present/edit?id=0ATM14GNiXaXfZGZkeHp... [2] - https://github.com/slluis/ngit

Re: Why is C faster than Java: git vs JGit

#65

I almost skipped this link; I assumed it was typical borring blog noise. It's not. This is an insightful post from the git mailing list which shows some of the real limitations that a top tier developer hits when trying to write Java code as fast as neatly optimized C code. Definitely worth reading.

Yep. The usual "Program X is faster in C than Java" gets a barrage of "That's because you know C better". Shawn is a performance-obsessed Java expert, Eclipse committer and longtime Google coder who works on JGit. If he says Java is slower than C at this, then Java is slower than C at this. EDIT: but as wcoenen points out, this was written in 2009 and Java 1.7 does a better job with some of this.

> "If he says Java is slower than C at this, then Java is slower than C at this."

Yes. I like how you qualify the statement. Furthermore, on the C side you have Linus and other C gurus that really, really know how to exploit the strengths of the C language.

Re: Why is C faster than Java: git vs JGit

#66
post #50

Earlier quoted context omitted.

> - There's no way to do array access without null pointer and index checks each and every time. That's not happening anymore for years already.

??? There are easy ways to miscode your way around the optimizations.

But it's not true that "there's no way." I think that was the distinction being drawn here.

Re: Why is C faster than Java: git vs JGit

#67
>So. Yes, its practical to build Git in a higher level language, but you just can't get the same performance, or tight memory utilization, that C Git gets. That's what that higher level language abstraction costs you. But, JGit performs reasonably well; well enough that we use internally at Google as a git server.

I think that this is the key takeaway for the entire post.

One of the reasons I generally dislike any of the "X IS BETTER THAN Y" bakeoffs is that performance is now so implementation dependent that these comparisons are pretty much moot. Given that basically any non-trivial implementation can be improved, it's difficult to say that anything is faster, especially when one considers developer skill.

Developers should not be chasing the abstract, absolute best performance. Instead, the language used should be the one that delivers performance that is good enough for their client's needs. If they can get it with something that we're familiar with, that's great. If they need to learn a new tool, that's also good. But it doesn't make much sense to throw away all the knowledge that a developer has about a certain language to chase "better performance" with a different one. Most likely, the first effort implementations on a new language won't be nearly as good as the implementations on the more familiar language.

It's generally true that optimized Java won't ever be as fast as optimized C. But for the vast majority of cases, it doesn't need to. Java's speed is enough for those cases. And in the small minority where it's not sufficient, C is still around.

Re: Why is C faster than Java: git vs JGit

#68
post #23

All the points are valid but they are peculiar to Java, not to all managed high-level languages. C#/.NET, for example, have unsigned types, value-type arrays and structs, memory mapped files and specialized collections. As an example, the C# port of Sqlite is sometimes faster than the C version on queries, although updates are slower, despite Sqlite is a highly optimized C library. EDIT: link http://code.google.com/p…

All the points are valid but they are peculiar to Java, not to all managed high-level languages. C#/.NET, for example, have unsigned types, value-type arrays and structs, memory mapped files and specialized collections.

I heard about related stuff happening while I was working at a Smalltalk vendor. The programmer who was implementing the network cryptography library would just call up the VM engineer and ask for goodies like support for large bit arrays, and he'd get them in for the next VM release. The programmer was able to beat some of RSA data security's (poorly implemented) reference DLL's written in C by 3% with a Smalltalk program.

In the Smalltalk environments, it's easy to implement "primitives" coded in C, just in case you weren't internal to the vendor. With open VMs like Squeak, you can add your own bytecode to support optimizations if you want to.

Re: Why is C faster than Java: git vs JGit

#69
post #28

Earlier quoted context omitted.

I've heard the argument before that in need, one can use a FFI to optimize bottlenecks in high-level code, but I've never understood. Won't using a high-level language incur an omnipresent speed slump? And even if a bottleneck exists, how would using a FFI remedy crucial problems in the language, like the absence of unsigned types or that all types are boxed. The types will have to be unboxed anyway, so whether that…

> Won't using a high-level language incur an omnipresent speed slump? Yes, but most programs don't require high performance everywhere - in a library like JGit for instance, most operations are probably plenty fast written in Java even for very large projects; it's likely only a few are problematic. > And even if a bottleneck exists, how would using a FFI remedy crucial problems in the language, like the absence of u…

You'll notice the author works at Google. Assume that the projects are "very large" :)

Re: Why is C faster than Java: git vs JGit

#70
A lot of this is poor API design, and the product of Java's baggage as something that needs to have well-defined safety semantics for internet applications. It is not a necessary constraint of high-level languages that they don't offer the ability to get down to the metal. SBCL, for example, offers a lot of mechanisms for unboxed primitive arrays, unsafe declarations, and these days even SSE intrinsics.
Post reply on HN