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

Why is C faster than Java: git vs JGit

marc.info

Post reply on HN
Print view View original

71–80 of 106 posts

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

#71

Post by erichocean »

ot wrote: 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…

Although Sqlite is highly optimized, it's got what amounts to its own VM internally, and doesn't really use C to the fullest.

It's not surprising to me that the C# version of that VM does as well (or better) for this particular codebase.

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

#72

Post by erichocean »

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

So does Factor: http://factorcode.org

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

#73

Post by azakai »

dochtman wrote: post #48
malkia wrote: post #44

I wonder if mercurial gets rewritten in "C" whether there would be any speedup.

I'm sure there would be some speedup, the question is whether it would be worth it (and I suppose that can only be adequately be assessed by the developers, who now have to maintain C code instead of Python). But for some perspective from a former Mercurial developer: lots of the more performance-sensitive code has already been rewritten in C. Rewriting the rest of it would simply be a question of diminishing returns…

> One thing that would improve is hg's startup time; starting up Python just takes a while

Python starts up very fast for a language runtime (much much faster than Java). But yes, if you run a large amount of extremely short tasks, the startup might become significant I guess.

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

#74

Post by gelliott »

zxypoo wrote: post #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 us…

That's really interesting - according to this presentation JGit clone is significantly faster than native git clone (2.3x in the example).

I'd love to hear more about any code changes that lead to this result.

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

#75

Post by CountHackulus »

SeanLuke wrote: post #43

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'd just like to point out that your complaints are specific to the Oracle JVM (except for the new for() syntax obviously).

Even the collection classes can change between JVM versions. I'm not saying that they're all necessarily better, just that different versions are different. So the Dalvik or IBM J9 versions might do what you want better.

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

#77

Post by yassim »

huherto wrote: post #65
jaylevitt wrote: post #41

Earlier quoted context omitted.

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.

I would also expect them to know how it works _all_ the way down through the OS, which can also have an impact on performance. IE, they know how the supporting systems operate thus can make further assumptions/optimisations.

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

#78

Post by willy1234x1 »

huherto wrote: post #65
jaylevitt wrote: post #41

Earlier quoted context omitted.

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.

He actually qualified it before that part of his comment.

>Shawn is a performance-obsessed Java expert, Eclipse committer and longtime Google coder who works on JGit.

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

#79

Post by oconnor0 »

erichocean wrote: post #71
ot wrote: 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…

Although Sqlite is highly optimized, it's got what amounts to its own VM internally, and doesn't really use C to the fullest. It's not surprising to me that the C# version of that VM does as well (or better) for this particular codebase.

Can you explain more what you mean about SQLite having roughly its own VM?

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

#80

Post by erichocean »

oconnor0 wrote: post #79
erichocean wrote: post #71

Earlier quoted context omitted.

Although Sqlite is highly optimized, it's got what amounts to its own VM internally, and doesn't really use C to the fullest. It's not surprising to me that the C# version of that VM does as well (or better) for this particular codebase.

Can you explain more what you mean about SQLite having roughly its own VM?

See: http://www.sqlite.org/different.html

Money quote about half-way down the page: "SQL statements compile into virtual machine code"

Every SQL database engine compiles each SQL statement into some kind of internal data structure which is then used to carry out the work of the statement. But in most SQL engines that internal data structure is a complex web of interlinked structures and objects. In SQLite, the compiled form of statements is a short program in a machine-language like representation. Users of the database can view this virtual machine language by prepending the EXPLAIN keyword to a query.

The use of a virtual machine in SQLite has been a great benefit to the library's development. The virtual machine provides a crisp, well-defined junction between the front-end of SQLite (the part that parses SQL statements and generates virtual machine code) and the back-end (the part that executes the virtual machine code and computes a result.) The virtual machine allows the developers to see clearly and in an easily readable form what SQLite is trying to do with each statement it compiles, which is a tremendous help in debugging. Depending on how it is compiled, SQLite also has the capability of tracing the execution of the virtual machine - printing each virtual machine instruction and its result as it executes.

Post reply on HN