Question about Cassandra
Why the hell on earth would anybody write a database ENGINE in Java ?
I can understand why you would want to have a Java interface, but the engine...
I was under the impression that there's nothing faster than C/C++, and that a database engine shouldn't be any slower than max speed, and certainly not use garbage collection...
Can anybody explain me what possible sense that makes / why Cassandra can be faster than ordinary SQL that runs on C/C++ code ?
Edit:
Sorry for the "Why the hell on earth" part, but it really didn't make any sense to me.
I neglected to consider that a database, unlike the average garden-varitety user programs, needs to be started only once and then runs for a very long time, and probably also as the only program on the server, which self-evidently makes for an important performance difference.
I was more comparing/referencing to a 'disfunctional' (to put it mildly) Java tax program I was using at the time of writing (or rather would have liked to use).
In fact, unlike using Java for tax programs, using Java for writing a dedicated server program makes perfect sense.
views:
3060answers:
5
+26
A:
What do you mean, C++? Hand coded assembly would be faster if you have a few decades to spare.
Martin
2010-02-26 13:29:27
+1, I was about to write a similar comment
ammoQ
2010-02-26 13:32:58
No, he said "C/C++", which is the mythical faster than everything language, but whose value depends on unspecified execution order.
Pete Kirkham
2010-02-26 14:14:27
Hahaha, that answer was to be expected. I found it funny, though.PS: C (the speed of light) is not MYTHICALLY faster than everything. If you benchmark, you see that it ACTUALLY is (ranging from 5 to up to 30 times) faster than Java, at the same investment of development time and level of competence). Besides, nowadays, larger amounts of hand coded assembly is in most cases slower than C, because the C compiler optimization is quite good, and the C stdlib is heavily optimized. It's still faster than C++, though. And you can throw away your assembly when the processor changes. Not so with C.
Quandary
2010-03-04 10:34:26
+7
A:
Don't forget that Java VMs make use of a just-in-time (JIT) engine that perform on-the-fly optimisations to make Java comparable to C++ in terms of speed. Bearing in mind that Java is quite a productive language (despite its naysayers) and portable, together with the JIT optimisation capability, means that Java isn't an unreasonable choice for something like this.
Brian Agnew
2010-02-26 13:29:43
+4
A:
The performance penalty for modern Java runtimes is not that big and programming in Java is less error-prone than in c.
Otto Allmendinger
2010-02-26 13:30:37
"Programming in Java is less error-prone than in C". That's a heck of a statement, care to back it up with some evidence?
Dominic Rodger
2010-02-26 13:31:46
Come on, Dominic. Yes, we all know it's more than possible to write (mostly) error-free code in C. But you can't deny Java gives you less rope to hang yourself with.
Matthew Flaschen
2010-02-26 13:34:17
+1 for Dominic. i've seen so many issues with carelessly written java code, that none of that java magic (gc, etc) can help. java apps don't leak memory like C? haha yeah, you wish!
pulegium
2010-02-26 13:35:14
@Matthew - sure. *I* can't think of any project *I'd* rather do in C than Java, I just object to the blanket statement. I can think of people around here who could write something in C that'd be a heck of a lot more solid than something I could write in Java. All I'm saying is that there's good C, and there's good Java - one isn't necessarily superior to the other.
Dominic Rodger
2010-02-26 13:40:49
@pulegium: I'd take memory leaks over buffer overflow any time
Otto Allmendinger
2010-02-26 13:41:18
there might be even people who write even better assembly, that doesn't mean you can't compare the difficulty of writing safe code between languages
Otto Allmendinger
2010-02-26 14:05:44
I don't think one's superior to the other either. They each have different strengths and emphases (and of course different experts). But I do believe Java is less error-/prone/.
Matthew Flaschen
2010-02-26 15:19:28
+1 for Dominic: I have seen sooooooo many bugs in Java (and PHP and Python and TCL and any other language you want) code that I won't believe any promises stating "this model is less error-prone than that one". You have got to be careful with such statements!
2010-07-01 17:50:19
The errors in these languages are a subset of the errors possible in C
Otto Allmendinger
2010-07-03 18:08:15
+13
A:
I can see a few reasons:
- Security: it's easier to write secure software in Java than in C++ (remember the buffer overflows?)
- Performance: it's not THAT worse. It's definetely worse at startup, but once the code is up and running, it's not a big thing. Actually, you have to remember an important point here: Java code is continually optimized by the VM, so in some circunstances it get faster then C++
Kico Lobo
2010-02-26 13:31:44
+11
A:
Why the hell on earth would anybody write a database ENGINE in JAVA ?
Platform independance is a pretty big factor for servers, because you have a lot more hardware and OS heterogenity than with desktop PCs. Another is security. Not having to worry about buffer overflows means most of the worst kind of security holes are simply impossible.
I was under the impression that there's nothing faster than C/C++, and that a database engine shouldn't be any slower than max speed, and certainly not use garbage collection...
Your impression is incorrect. C/C++ is not necessarily faster than Java, and modern garbage collectors have a big part in that because they enable object creation to be incredibly fast.
Michael Borgwardt
2010-02-26 13:32:00
Michael - can you elaborate on your comment re object *creation* being fast because of the garbage collector ?
Brian Agnew
2010-02-26 13:35:49
(note this is simplified...) Object creation (not destruction) can be more efficient with managed code as a compacting garbage collector will try arrange all free memory for the proccess in a contiguous area. When one needs to allocate a certain amount of memory we already know if we have enough, and can avoid trying to walk the memory of the process trying to find a free area big enough for what we need. The collorary to this though is that after the GC cleans up memory it needs to compact all GC survivors together in memory
saret
2010-02-26 14:03:47
@Brian - with a modern GC, freed memory is compacted, making memory allocation trivially simple compared with a typical `malloc`.
Stephen C
2010-02-26 14:49:05