Why git is so fast (or why Java is not as fast as C) • Hacker News Board

Re: Why git is so fast (or why Java is not as fast as C)

#11

Post by barrkel » Sat, Jan 02, 2010, 10:05 AM UTC

I find it interesting to read that every single one of his criticisms of JGit would not need to apply to a C# implementation. Unsigned types, unmanaged memory allocation (Marshal.Alloc), unsafe code with pointers, native P/Invoke access, value types (e.g. fixed arrays for his SHA-1 point), and an IDisposable convention for managing all the unmanaged trickery, C# has pretty much all the needed features.

When optimizing C# for space use in particular (which ends up being a time optimization for I/O heavy loads), I've leaned heavily on arrays of structs, and even bit-packed arrays (e.g. an Int32 array storing 14-bit integers, packed so that they don't align on index boundaries).

Programming at the level of C in C# loses most of the benefits, of course, but at least you can hide the optimizations behind pretty APIs, and write the non-critical parts in terms of an easier to work with lower layer.

Re: Why git is so fast (or why Java is not as fast as C)

#12

Post by rdtsc » Sat, Jan 02, 2010, 10:05 AM UTC

DarkShikari wrote: post #3

This has always been true and will continue to be true. It's possible to build a high level language that's as fast as C? Sure--but only if you restrict the programmer to the same amount of effort in both languages. If your application is one where it's worthwhile applying a great deal of extra programmer time in order to improve performance, a low level language will always win because it exposes more of the native…

Another thing to keep in mind before optimizing is the 80/20 rule. Usually only a small part of the program (20%) needs optimizing.

Of course one needs actual performance numbers (via profiling for example) before knowing what to optimize. There is nothing worse than faith-based performance assumptions. I have seen months being wasted re-writing code in a lower level language to "make things faster" only to find out that it didn't make a difference, the code was disk or network bound and not CPU bound.

Re: Why git is so fast (or why Java is not as fast as C)

#13

Post by barrkel » Sat, Jan 02, 2010, 10:08 AM UTC

DarkShikari wrote: post #7

Locke1689 wrote: post #5

Earlier quoted context omitted.

Couldn't agree more. One thing to remember though: "Premature optimization is the root of all evil." C Git is optimized and fast. Mercurial, with a combination of Python and C, is almost as fast. Maybe not quite as fast, but fast enough for me. A lot of the time those optimizations just don't pay off in terms of programmer time.

Slightly tangential, but I think "Premature optimization is the root of all evil." is the most misquoted statement in the history of computer science. Most importantly, people tend to misinterpret "premature" to mean "any time before the software is done" or similar. I can't even count the number of times where I've worked on or watched a project where performance is important and the following series of events occur…

Well, the fact that it says that something "premature" is causing a problem seems to me to mean that it's actually a tautology. It's like saying kids are immature; but of course, what is more of the nature of an immature person than a child?

So yes, optimizations that are made before they should have been made, should not be made. It tells us little about optimizations other than that there is a time for which they are premature, and doing them at that time is premature.

Re: Why git is so fast (or why Java is not as fast as C)

#14

Post by thibaut_barrere » Sat, Jan 02, 2010, 10:15 AM UTC

From the last line:

"But, JGit performs reasonably well; well enough that we use internally at Google as a git server."

Rings the 'good enough' bell to me.

Re: Why git is so fast (or why Java is not as fast as C)

#15

Post by axod » Sat, Jan 02, 2010, 10:20 AM UTC

>> "why Java is not as fast as C"

Not actually true in reality. Modern JVMs can make on the fly optimizations based on the runtime profile, which would need to be done by hand in C.

As said elsewhere though, Java excels when used for long running tasks - servers - backends etc where it can optimize for the long term. It doesn't excel when you try and start up the jvm loads of times for quick individual jobs.

I don't understand why people are optimizing source control :/ fast vs fast meh I don't think it's an issue really.

Re: Why git is so fast (or why Java is not as fast as C)

#16

Post by richardw » Sat, Jan 02, 2010, 10:20 AM UTC

While I'd never claim Java is comparable to C, I'd like to note that the C codebase has, by their admission, 4 years of work in it. I'd be surprised if the JGit codebase isn't much faster in 3/4 years.

Re: Why git is so fast (or why Java is not as fast as C)

#17

Post by barrkel » Sat, Jan 02, 2010, 10:24 AM UTC

DarkShikari wrote: post #3

This has always been true and will continue to be true. It's possible to build a high level language that's as fast as C? Sure--but only if you restrict the programmer to the same amount of effort in both languages. If your application is one where it's worthwhile applying a great deal of extra programmer time in order to improve performance, a low level language will always win because it exposes more of the native…

Of course, managed languages can buy you other things, such as inlining indirect method calls by rewriting the call site (polymorphic inline caching), dynamic profile-guided optimization, not to mention the fact that garbage collection is often faster than manual deallocation, depending on the nature of the problem and the pattern of allocations. (Of course, design of managed applications can benefit greatly from awareness of how the GC works).

WRT SIMD operators, I'll point you to Mono.Simd.

Re: Why git is so fast (or why Java is not as fast as C)

#18

Post by fauigerzigerk » Sat, Jan 02, 2010, 10:27 AM UTC

axod wrote: post #15

>> "why Java is not as fast as C" Not actually true in reality. Modern JVMs can make on the fly optimizations based on the runtime profile, which would need to be done by hand in C. As said elsewhere though, Java excels when used for long running tasks - servers - backends etc where it can optimize for the long term. It doesn't excel when you try and start up the jvm loads of times for quick individual jobs. I don't…

The post specifically mentiones Java's implementation of memory mapped files, Java's lack of value types and Java's lack of unsigned types. These are very different areas but none of them can be solved by on the fly optimizations or longer running processes.

Re: Why git is so fast (or why Java is not as fast as C)

#19

Post by richardw » Sat, Jan 02, 2010, 10:28 AM UTC

axod wrote: post #15

>> "why Java is not as fast as C" Not actually true in reality. Modern JVMs can make on the fly optimizations based on the runtime profile, which would need to be done by hand in C. As said elsewhere though, Java excels when used for long running tasks - servers - backends etc where it can optimize for the long term. It doesn't excel when you try and start up the jvm loads of times for quick individual jobs. I don't…

'Modern JVMs can make on the fly optimizations based on the runtime profile'

That's something I've heard ever since hotspot came out, but it's not a silver bullet to beating C/C++ etc. Here are some server tests. Some are comparable, some are definitely not: http://shootout.alioth.debian.org/u64q/java.php

Re: Why git is so fast (or why Java is not as fast as C)

#20

Post by axod » Sat, Jan 02, 2010, 10:34 AM UTC

thibaut_barrere wrote: post #14

From the last line: "But, JGit performs reasonably well; well enough that we use internally at Google as a git server." Rings the 'good enough' bell to me.

Agree. If your bottleneck is your source control tool, you're doing something wrong.