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

51–60 of 106 posts

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

#51

Post by nvarsj »

bajsejohannes wrote: post #10

> when you do use Java NIO MappedByteBuffer, we still have to copy to a temporary byte[] in order to do any real processing Does anyone know why this is the case?

Well, with a MappedByteBuffer (or any DirectByteBuffer), if you want to manipulate the data as a Java type (e.g. byte[]) you have to copy the data into the heap. byte[] cannot exist outside of the heap.

Still, I wonder why they're using a MappedByteBuffer in the first place if they're working with the data in the Java heap.

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

#52

Post by hello_moto »

jgw wrote: post #38
kokey wrote: post #24

Earlier quoted context omitted.

Actually, it also makes me want to get into another project in C again.

So this. It's truly liberating to get back to C after having programmed in something higher level for a long time. It actually makes me appreciate C more. I mean, at first, I shoot myself in the foot, elbow and groin with alarming regularity, but it's nice to actually have access to the bullets. :) [EDIT: dodgy grammar]

You won't know what you're missing until you don't have them :).

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

#53

Post by SeanLuke »

soc88 wrote: post #50
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…

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

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

#54

Post by mdeicaza »

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…

Additionally, C# collections do not need to box.

List uses an actual array of integers as its backing store instead of an array of objects that contain boxed copies of the integers.

There is a port of JGit to .NET called NGit, which is what we use for MonoDevelop.

The port is maintained with an automatic tool that converts Java code to C# code, you can find it here:

https://github.com/slluis/ngit

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

#55

Post by andy_boot »

nvarsj wrote: post #49
dons wrote: post #36

Earlier quoted context omitted.

At least in Haskell you have unboxed primitive types, memory mapped IO, bump-pointer allocation, and compilation to direct loops that are often identical to what GCC produces (or very close).

All of those things also exist in hotspot/Java. Primitive types have been available since the creation of Java. It's up to the programmer to use boxed types or not. Memory mapped IO - see Java.nio. Bump-pointer allocation/compilation to direct loops all exist in hotspot.

>>Primitive types have been available since the creation of Java. It's up to the programmer to use boxed types or not.

You can't use a primitive in a collection: eg HashMap / ArrayList

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

#56

Post by jcdavis »

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…

> - There's no way to do array access without null pointer and index checks each and every time.

Actually there is. Have you checked out the sun.misc.Unsafe class? Lots of very dangerous gems in there, among them the ability to calculate array offsets and access the array elements directly. (check out arrayBaseOffset + arrayIndexScale + getObject/getLong/etc)

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

#57

Post by oconnor0 »

andy_boot wrote: post #55
nvarsj wrote: post #49

Earlier quoted context omitted.

All of those things also exist in hotspot/Java. Primitive types have been available since the creation of Java. It's up to the programmer to use boxed types or not. Memory mapped IO - see Java.nio. Bump-pointer allocation/compilation to direct loops all exist in hotspot.

>>Primitive types have been available since the creation of Java. It's up to the programmer to use boxed types or not. You can't use a primitive in a collection: eg HashMap / ArrayList

Which is why nifty little libraries like Trove, FastUtil, and HPPC exist.

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

#58

Post by ww520 »

andy_boot wrote: post #55
nvarsj wrote: post #49

Earlier quoted context omitted.

All of those things also exist in hotspot/Java. Primitive types have been available since the creation of Java. It's up to the programmer to use boxed types or not. Memory mapped IO - see Java.nio. Bump-pointer allocation/compilation to direct loops all exist in hotspot.

>>Primitive types have been available since the creation of Java. It's up to the programmer to use boxed types or not. You can't use a primitive in a collection: eg HashMap / ArrayList

Can you use GNU Trove or Apache Commons Primitives that support primitive types in collections?

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

#59

Post by jshen »

wcoenen wrote: post #29

This was posted in 2009. I think that some of the arguments are no longer valid, e.g. Java 1.7 now uses escape analysis to eliminate heap allocations where possible: http://weblogs.java.net/blog/forax/archive/2009/10/06/jdk7-d...

"I think that some of the arguments are no longer valid"

Has anyone measured it?

Post reply on HN