What hardware need to upgrade to run Java programs faster?
doe a separate video card help?
or its all based on CPU performance?
Jun 17th, 2016 6:34 pm
Jun 17th, 2016 7:11 pm
Jun 17th, 2016 8:31 pm
Jun 17th, 2016 8:35 pm
Jun 18th, 2016 11:03 am
Jun 18th, 2016 11:52 am
Jun 18th, 2016 7:02 pm
Jun 18th, 2016 7:55 pm
Jun 18th, 2016 8:40 pm
No, most Java programs rely on raw CPU power - also very few programs are multi-threaded correctly, so you should be interested in the fastest single threaded performance over more cores.
Jun 19th, 2016 12:53 am
Jun 19th, 2016 7:38 am
Jun 19th, 2016 10:26 am
Jun 19th, 2016 5:41 pm
The google's guy who wrote jGit (and Gerrit) threw in the towel, regardless what he tried (he's pretty smart) Java is still way slower than C.
JGit struggles with not having unsigned types in Java. There are
many locations in JGit where we really need "unsigned int32_t" or
"unsigned long" (largest machine word available) or "unsigned char"
but these types just don't exist in Java. Converting a byte up to
an int just to treat it as an unsigned requires an extra " & 0xFF"
operation to remove the sign extension.
JGit struggles with not having an efficient way to represent a SHA-1.
C can just say "unsigned char" and have it inline into the
container's memory allocation. A byte in Java will cost an
*additional* 16 bytes of memory, and be slower to access because
the bytes themselves are in a different area of memory from the
container object. We try to work around it by converting from a
byte to 5 ints, but that costs us machine instructions.
C Git takes for granted that memcpy(a, b, 20) is dirt cheap when
doing a copy from an inflated tree into a struct object. JGit has
to pay a huge penalty to copy that 20 byte region out into 5 ints,
because later on, those 5 ints are cheaper.
Jul 2nd, 2016 2:07 pm
What you're quoting doesn't really mean what you think it does, its basically a description that git was designed with the behaviour and advantages of of C in mind which makes it difficult to implement in Java. jgit is also actively maintained last I heard, though I don't know if Pearce is involved /shrug.
Jul 4th, 2016 8:49 am
Any program that needs fast access to largish data (which is most of them) would tremendously benefit from "direct" mmap() (not the crap Java gives you). Last month I needed and wrote a program to quickly retrieve key-ed data (~25M keys, ~1G dataset). I used a trie (not tree) to get O(1) complexity (vs O(log n) like most database packages) and use mmap() to take advantage the OS's on-demand loading. The code was beautifully simple and very efficient/fast. Doing the same thing in Java would be order of magnitude slower.luthair wrote: ↑What you're quoting doesn't really mean what you think it does, its basically a description that git was designed with the behaviour and advantages of of C in mind which makes it difficult to implement in Java. jgit is also actively maintained last I heard, though I don't know if Pearce is involved /shrug.