Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

marc.info

Post reply on HN
Print view View original

81–90 of 110 posts

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

#81

Post by kscaldef »

tentonova wrote: post #76
dasil003 wrote: post #69

Earlier quoted context omitted.

What type of work do you do that you never have urgent bug fixes and/or never have features that take more than a day to complete? Sure it's optimal to work linearly, but in the real world things come up. Now if you are looking for a reason to tell stakeholders to suck it up and wait, then poor branching support may help you, but that's a technical solution to a managerial problem. If you're interested in having the…

What type of work do you do that you never have urgent bug fixes and/or never have features that take more than a day to complete? I've always worked to constrain non-linear development to the absolute minimum required because the technical costs are easily dwarfed by the human communication overhead and inherent organizational complexity engendered in multiple disparate branches of development.

This still feels like the sort of statement that comes from having not worked with a (D)VCS that does branching well. There is no "inherent organizational complexity" in me having a private branch that I share with no one and which is only used for an hour or two while I work on a critical bug fix.

What you're talking about seems to be multiple, long-running development or release branches. Those are hard to manage and generally a bad idea in any VCS. But, with a system like Git, you don't tend to have long-lived divergent development branches. Typical branch lifetimes are more like hours or days, rather than weeks or months. There are exceptions, but by-and-large, branches are just used differently in git.

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

#82

Post by cschep »

JulianMorrison wrote: post #28
DarkShikari wrote: post #7

Earlier quoted context omitted.

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…

I always though that what that one quote meant was: measure, then optimize. It's no use tuning the hell out of a function that hardly features in your profiler results.

Yes, or even just figure out HOW (you're going) to measure it.

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

#83

Post by jwinter »

dschobel wrote: post #70
jwinter wrote: post #54

Earlier quoted context omitted.

Check out nailgun if you're interested in using the JVM as a command-line tool without a cold-start. http://martiansoftware.com/nailgun/index.html

I was looking at this the other day and am concerned that it hasn't been updated since February, 2005. That's practically ancient in terms of software.

This looks unofficial, but Github has a version that has updates over the past few years:

http://github.com/ato/nailgun/tree/master/nailgun/

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

#84

Post by fauigerzigerk »

richardw wrote: post #19
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

What you link to are tests using the server VM but without warmup. You need to select "Java 6 steady-state" to get the warmup.

[Edit] Actually the state-state one averages over multiples restarts including JITed and non-JITed runs.

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

#85

Post by igouy »

fauigerzigerk wrote: post #84
richardw wrote: post #19

Earlier quoted context omitted.

'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

What you link to are tests using the server VM but without warmup. You need to select "Java 6 steady-state" to get the warmup. [Edit] Actually the state-state one averages over multiples restarts including JITed and non-JITed runs.

See how little difference that "warmup" makes for these tiny programs - with the obvious exception of the binary-trees program -

http://shootout.alioth.debian.org/help.php#java

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

#86

Post by vii »

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…

This completely misses the point. The reason JGit cannot compete with Git is not that it is using an extra cycle or two to make function calls. The problem is that Java cripples you in the sort of data-representations you can use -- no mmap, no value types -- forcing lots of extra copying. There's no reason a language can't provide these features, and I don't know that they require significant extra programmer effort. C# does it, etc.

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

#87

Post by jrockway »

tentonova wrote: post #64
adw wrote: post #40

Earlier quoted context omitted.

Most likely they can drop it into their existing systems for deploying Java apps.

As well as use it as a library API, and integrate it with their other libraries/services/etc.

Indeed. Git may be fast, but if you ever want to wrap a reliable program around it, good luck.

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

#88

Post by emerose »

kelnos wrote: post #31
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.

I'm actually a bit curious as to why they're using JGit as a git server. Is there something lacking in git-daemon, etc.?

They use it in Gerrit — http://code.google.com/p/gerrit/ — which is an open-source code review system built to mimic Google Mondrian, but which uses Git rather than Perforce. Shawn Pearce, the author of the linked email, is also the primary maintainer of Gerrit.

-sq

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

#89

Post by delackner »

barrkel wrote: post #55
blasdel wrote: post #43

Earlier quoted context omitted.

Anything but 'managed' -- while conceptually it covers things quite nicely, in practice it's used almost exclusively to mean "runs on the CLR", by those living solely within the Microsoft ecosystem whose knowledge of programming languages comes from Microsoft marketing materials. It's a loaded term. There's plenty of nomenclature abuse in that ecosystem, like using 'assemblies' to refer to packages or 'blittable' for…

I don't use it to exclusively mean CLR-hosted, and to be frank, I think the meaning is pretty clear outside of MS contexts. I believe "GCed" focuses too much on the memory allocation strategy; which while important for many of the practical advantages of managed languages, I think it ends up lopsided. Finally, more people using a word in an alternative way is the path to controlling its meaning, rather than avoiding…

What meaning does "managed" have to you? I wasn't aware of a generic meaning. A virtual-machine-based language that happens to include garbage collection?
Post reply on HN