Well, to point to evidence otherwise, if by JIT your taking about dynamic translation/recompilation for optimization purposes then no
That is the definition of a JIT I have always used, thus my confusion. All of the reasons you state are performance arguments against JIT, but there are other reasons for JIT compilation, including architecture independence. But since all the world's an x86 these days, that feels less important now than it did 15+ years ago.
Speaking of dynamic recompilation, back in 1998 or so I was running Windows NT on a Digital Alpha. Since there were few native apps, Digital included a translator to run Windows apps (Office etc.) compiled for x86 natively on Alpha, and I'm sure it was some sort of JIT. Those apps would run slowly the first time, but get noticeably faster the next 2-3 times they run. And it legitimately translated and ran the apps faster than a good Pentium Pro machine of the day. That was due to an edge that Alpha had over Intel, rather than software, but the hardware advantage didn't last long.
1) Sure. When I said "performs very well" I mean within an order of magnitude. I've heard claims that JIT technology will surpass ahead-of-time compilation. I don't quite believe that either, and at any rate it's clearly not there yet. I didn't claim the JIT was equally fast or faster, but it's close enough that there just wasn't a ton of people interested in using a compiler like gcj.
2) I'm skeptical that JIT requires a GC (in the general case, though for Java it is clearly required by the JVM). Do you have a reference for this claim?
3) Yes, and of course real Java code does bounds checking too. Back when I was using gcj extensively, I was finding examples of duplicate array bounds checks, one added by the developer and one inserted by the compiler. A good compiler should be able to eliminate the redundant check. At times this is hard, such as when the caller does the bounds checking, and does so in a different translation unit.
4) Interesting. There are examples, such as the complex type, that would be far more efficient as a value object. But I agree with your point that passing objects that are too large as value objects is probably counter-productive.
Mostly I agree with your points. Especially that Perl is dog slow.
A good JIT actually performs very well compared to ahead of time compiling, and can take advantage of execution profiling (for things like branch prediction) by deferring compilation until the bytecode runs a few times.
The main advantages of gcj are improved startup times, porting to unusual architectures, and maybe for memory constrained targets.
When comparing C++ performance to Java, there are many things to keep in mind aside from the JIT compiler:
- Java also has GC overhead. You get a fairer comparison by adding garbage collection to your C++ app. The performance effects of garbage collection are complicated, but one of the difficult problems is that it tends to fill the processor data cache with useless entries. - Java adds overhead required by the JLS such as array bounds checking or class initialization tests. - Exception handling can also impact code generation. Java requires null pointer dereferencing (for example) to be trapped and handled, which adds abnormal edges to a CFG which places restrictions on e.g. instruction scheduling. Strict expression evaluation order, required by the JLS, has the same effect. - Java has a more limited type system. In particular objects other than primitive types cannot be passed by value, which tends to result in more frequent memory allocations, more garbage collection, and more pressure on the memory cache than languages that can make more efficient use of the stack.
The biggest reason worked stopped on gcj was the release of OpenJDK, since one of the main reasons for gcj in the first place was to have a fast and free Java runtime. OpenJDK satisfies both.
Alpha and MIPS are completely different than IA64. Alpha was a true RISC chip with a fixed 32-bit instruction length, superscalar, out-of-order execution. IA64 was a VLIW chip with in-order execution that relies on the compiler to do anything efficient.
HP made a fatal mistake cancelling PA-RISC and Alpha in favor of IA64. The could have picked either of the other two as a successor, and have been better off as a result. Instead they chose a dead-end, probably because (at the time) it looked like the entire hardware industry would go that way. Before SGI, IBM, Dell and others backed out.
I was a little surprised by GvR's answer to this. RHEL 6 ships with Python 2.6, last I checked, and we don't normally deviate from Red Hat packages without good reason. Getting the masses off pre-2.7 versions of Python will also entail releasing newer OS distributions and retiring older ones, both of which happen slowly.
Not everyone can keep up with the latest/greatest versions out there, especially when they have hundreds of servers and big legacy applications to support.
We have a ton of "enterprise" Java applications, from multiple *large* vendors, that we run at work, and they are the most buggy, slow, crashy things I have ever experienced.
Alright, I'm with you. I'll bet that any apps you get from those "large" vendors are going to suck, Java or otherwise.
And "enterprise" software? Our company is arguably an "enterprise", though I have yet to use any enterprise software that felt it was designed for us. I don't get that market at all. Don't sell me software that does everything, give me instead something simple that integrates cleanly with all the other software I already use.
Try hanging out in the open source circles, like some of the Apache Java projects, if you want another perspective. Then again, you probably don't. Just trust me... lousy software that happens to be written in Java isn't a reflection of Java.
You've never benchmarked any of these yourself, have you? (Please tell me you're not talking about benchmarking some "Hello World" application that can be measured in microseconds...)
I won't go into details now, but Perl 5 is really *spectacularly bad* at runtime performance. Pretty much at the other end of the spectrum from C/C++/.NET/Java (all of which compile to native, whether ahead of time or JIT, and all of which perform in the same ballpark for typical applications).
Wow, this is new. A rational, reasonable argument from a self-described Java hater... not just another "Java is slow because it's interpreted" or "Java is insecure" bullcrap post.
I've seen legions of developers grow frustrated with the gigantic frameworks and libraries that have grown up around Java, and react by abandoning Java and building something insanely simple in another language.
I wish just one of those guys would have instead tried abandoning the bloated frameworks and instead build something insanely simple in Java. I've done that, and found it very satisfying. But I'm aware I'm firmly in the minority having tried that, and in more than one case some other engineer grabbed my small code and bloated it up again.
You're kidding, right? We've been using MySQL replication for 10 years in production. Multi-master replication, statement-based and row-based. We've replicated between servers adjacent in a rack and servers that are separated by thousands of miles. And for the most part, everything Just Works.
The product may not be as academically pure, or whatever, as Postgres but that doesn't matter in a business setting. We use the tools that get the job done. On the other hand our team has been trying for the past month to get a Postgres (actually EnterpriseDB) instance to run in multi-master replication, or replicate DDL, without success. As far as we can see those are not supported features which make it almost useless to us.
It's comical how envious Postgres backers seem to be of MySQL's commercial success. And the quality of intelligent, thoughtful discourse on this forum is discouraging. Guess slashdot isn't what it used to be:(
Can't really agree more. My challenge is the "cool kids" come along and rebel against anything from the 90's. I've seen newcomers build in Python, Ruby, and (the latest) Node.JS.
All of those are interesting in their own right, but for what we do I don't see them really solving practical problems that we haven't solved before. Except for stroking someone's ego--that they seem to solve nicely.
And as pointed out elsewhere on this topic, it's not as though Java has stood still. The most common complaint I've heard is that Java is verbose and Java code has far too much boilerplate "junk" (I tend to agree for legacy code--things like useless getter/setter methods and needless interfaces drive me bonkers). Then I ask them, what have you tried in Java lately? If you try to write compact, readable, maintainable code, you'll find it's not only possible but straightforward. Pick a few patterns that work well for you and stick to them (like chaining methods together as a builder pattern--one of my favorites).
Java gets a bad rap (and Oracle doesn't help) but there's nothing wrong with it per se. If I had the choice of starting a project in C, C++ or Java I'd always pick Java--call it obsolete if you want but those alternatives are archaic. (And I'm not fully sold on interpreters languages either, partly because my applications are very sensitive to runtime performance and memory overhead. Are the JIT compilers for Python et al any good?)
The security exploits are in the Java plugin. I don't care much about those because I disabled the plugin in my browsers years ago. Don't folks understand that 99.99% of Java users are unaffected by the plugin exploits???
When programming Java, you sure don't have to wrap everything in an object. Everything is in a class, but so what? Classes provide a namespace for your code, which is useful. They also give you lazy loading so you don't have to wait for an entire app to load.
There are a lot of bad Java programmers though. It seems too few of them have really learned CS and don't understand the internals or runtime well. That's a mistake when using any language.
Yes. We switched 6 years ago and never looked back. The java.util.Calendar classes in Java are pretty horribly broken--usability aside, they get some key calculations wrong, like ISO week of year.
The best part is that Joda doesn't need or use the time zone database bundled into Java SE, so they aren't affected at all by Oracle's support policies.
I just RTFA, from what I can tell this affects anyone who needs to run untrusted code in a JVM with a SecurityManager, not just applets.
That said, I can't think of any reason to do that besides applets, so most vulnerable users are those with browser plugins. Virtually everyone I know who runs Java deploys it within a servlet container where untrusted code is not normally a concern. Given that, the story seems a bit overblown.
As another poster pointed out, this is a false dichotomy. We're emerging from a technology monoculture of "every DBMS must be SQL" to "it's possible, even viable to design, implement and use a DBMS that does not implement SQL". Anyone advocating a mass exodus from SQL-land is a fool. Props to the NoSQL guys for opening our eyes to fresh ideas.
There's no need to stick with any single DBMS platform for 100% of your organization, unless you're so small that you have but one server total, and then I suspect this debate is largely irrelevant to you anyhow.
We're not Google, but we have some of the same problems Google faced with scaling up our applications for the Internet. We do use MySQL, having some 35+ instances of it. Our application processes in excess of 1000 transactions each second, and we know it'll be difficult to scale to tens of thousands of transactions per second without some fundamental changes. Today we survive by imposing limitations on developers writing OLTP applications--things like "all row operations must search by primary key" and "no table scans, ad-hoc queries or file sorts". The access language is still SQL, but increasingly we don't *need* SQL for OLTP transactions. We could plug in something today that is equivalent and far simpler.
What we're lacking in SQL-land is a good way to host DBMS applications on distributed infrastructure, e.g. in the cloud. There are clustered databases available, but these often require fast/short interconnects, may have difficulty scaling above bandwidth limits on a local network or SAN, and can be frustratingly fragile to use in the "real world". Not to mention expensive. This is due to the consistency model imposed on such systems, i.e. the "AC" in ACID.
Data sharding is a popular way to exceed the limits of SQL, but once you introduce sharding you're treading on "NoSQL" waters already. You can't retrofit sharding onto an application that isn't aware of it, not very successfully, in my experience. So developers need to become acutely aware of the storage tier and design for it, meaning they've already lost the perfect abstraction of SQL.
I'm keenly interested in emerging products like the Cassandra database, and while I have no intent of ever abandoning SQL (and probably even MySQL) in our organization, we're absolutely going to take "NoSQL" for a spin to see what it delivers in terms of cost, complexity, relability and performance.
The NDB releases basically forked from mainline MySQL. Latest is NDB 7.x, which is actually very good at what it does. Not *quite* ready for what we need but getting very close. ALTER ONLINE is a nifty feature... I've used it to add/drop indexes on the fly from tables in continuous use.
Earlier releases of NDB required that all indexes and data fit in main memory, but that has been remedied with disk data tables. Currently, disk data tables can only store fixed-length data (all strings are padded to their full length). Once that limitation is addressed, I'll be ready to look at it again.
If you applications need frequent table scans, forget about NDBCLUSTER. If however you meticulously access all your data by primary key, I find NDB scales just fine with workload.
Okay I'll bite. I'm not familiar with postgresql versions since about 7.x.
From http://www.postgresql.org/about/:
An enterprise class database, PostgreSQL boasts sophisticated features such as Multi-Version Concurrency Control (MVCC), point in time recovery, tablespaces, asynchronous replication, nested transactions (savepoints), online/hot backups, a sophisticated query planner/optimizer, and write ahead logging for fault tolerance. It supports international character sets, multibyte character encodings, Unicode, and it is locale-aware for sorting, case-sensitivity, and formatting. It is highly scalable both in the sheer quantity of data it can manage and in the number of concurrent users it can accommodate. There are active PostgreSQL systems in production environments that manage in excess of 4 terabytes of data. Some general PostgreSQL limits are included in the table below.
Which of these are not also true of mysql? The InnoDB storage engine also has MVCC, snapshot recovery, hot backups, etc.
Everytime I see this debate on slashdot it invariably degenerates into claims of mysterious missing features (what are they?) or non-transactional characteristics of MyISAM. Too bad, because I'm genuinely interested in a good comparison. I use MySQL extensively today but have worked on both in the past.
Anyone still tempted to go with the "non-acid" argument... give it up, else risk looking ignorant or foolish. MySQL is designed to support many storage engines. Anyone using MySQL this past decade who cares about their data creates most of their tables as InnoDB tables. And InnoDB is a very very good storage engine, if it matters.
I may have to try postgresql myself, if only to get to the bottom of this. What doesn't it have that I sorely need? Perhaps nothing. Then again mysql isn't missing much, either, for our needs. Perhaps, in the end, this is more like comparing AMD to Intel--no clear winner.
Basically, I think the effort of the Open Source community, of those that like Java, would be much pretty spent on making GCJ integrate seemlessly with a compliant Java VM using JNI.
I doubt that it would be practical. JNI does a lot of bookkeeping and is doomed to be far slower than whatever internal calling convention a JVM uses. You'd lose whatever advantages native compilation may have.
I hope developers would rather innovate and improve the java standard than to fork off a clone.
How can they innovate that for which they have no source code? The free implementation must come first. First they make it complete, then make it fast, then make it better.
Technically all that is true... but I can't help but remember some comp.arch discussions arguing the effectiveness of EPIC's technology in Intel's target market.
Specifically, there are problems in compiler technology that are hard to solve, especially in enterprise computing, which is where the money is that presumably will be spent on McKinley hardware.
Developers of enterprise software don't write code that is conducive to ILP. Those who do, in the HPC arena, aren't relevant to Intel's presumed target market of mid and upper-range servers.
There is as of yet little evidence that Intel can adequately solve the problems of branch prediction, alias analysis and operand prefetching in typical enterprise code to a degree that justifies the great expense of R&D they have poured into this experiment known as IA-64.
It is interesting to note that Java, because of lack of pointers produces impressive code for EPIC processors and is highly amenable to optimizations targetting EPIC.
Can you elaborate on this? Though Java doesn't understand pointers at the source level, surely most implementations represent object references as pointers.
I'd suppose Java doesn't have the aliasing problem as C/C++ but it suffers from other limitations, like overly strict language semantics, i.e. strict left-to-right evaluation.
Slashdot Mirror
Thanks. When you say:
Well, to point to evidence otherwise, if by JIT your taking about dynamic translation/recompilation for optimization purposes then no
That is the definition of a JIT I have always used, thus my confusion. All of the reasons you state are performance arguments against JIT, but there are other reasons for JIT compilation, including architecture independence. But since all the world's an x86 these days, that feels less important now than it did 15+ years ago.
Speaking of dynamic recompilation, back in 1998 or so I was running Windows NT on a Digital Alpha. Since there were few native apps, Digital included a translator to run Windows apps (Office etc.) compiled for x86 natively on Alpha, and I'm sure it was some sort of JIT. Those apps would run slowly the first time, but get noticeably faster the next 2-3 times they run. And it legitimately translated and ran the apps faster than a good Pentium Pro machine of the day. That was due to an edge that Alpha had over Intel, rather than software, but the hardware advantage didn't last long.
1) Sure. When I said "performs very well" I mean within an order of magnitude. I've heard claims that JIT technology will surpass ahead-of-time compilation. I don't quite believe that either, and at any rate it's clearly not there yet. I didn't claim the JIT was equally fast or faster, but it's close enough that there just wasn't a ton of people interested in using a compiler like gcj.
2) I'm skeptical that JIT requires a GC (in the general case, though for Java it is clearly required by the JVM). Do you have a reference for this claim?
3) Yes, and of course real Java code does bounds checking too. Back when I was using gcj extensively, I was finding examples of duplicate array bounds checks, one added by the developer and one inserted by the compiler. A good compiler should be able to eliminate the redundant check. At times this is hard, such as when the caller does the bounds checking, and does so in a different translation unit.
4) Interesting. There are examples, such as the complex type, that would be far more efficient as a value object. But I agree with your point that passing objects that are too large as value objects is probably counter-productive.
Mostly I agree with your points. Especially that Perl is dog slow.
A good JIT actually performs very well compared to ahead of time compiling, and can take advantage of execution profiling (for things like branch prediction) by deferring compilation until the bytecode runs a few times.
The main advantages of gcj are improved startup times, porting to unusual architectures, and maybe for memory constrained targets.
When comparing C++ performance to Java, there are many things to keep in mind aside from the JIT compiler:
- Java also has GC overhead. You get a fairer comparison by adding garbage collection to your C++ app. The performance effects of garbage collection are complicated, but one of the difficult problems is that it tends to fill the processor data cache with useless entries.
- Java adds overhead required by the JLS such as array bounds checking or class initialization tests.
- Exception handling can also impact code generation. Java requires null pointer dereferencing (for example) to be trapped and handled, which adds abnormal edges to a CFG which places restrictions on e.g. instruction scheduling. Strict expression evaluation order, required by the JLS, has the same effect.
- Java has a more limited type system. In particular objects other than primitive types cannot be passed by value, which tends to result in more frequent memory allocations, more garbage collection, and more pressure on the memory cache than languages that can make more efficient use of the stack.
The biggest reason worked stopped on gcj was the release of OpenJDK, since one of the main reasons for gcj in the first place was to have a fast and free Java runtime. OpenJDK satisfies both.
Alpha and MIPS are completely different than IA64. Alpha was a true RISC chip with a fixed 32-bit instruction length, superscalar, out-of-order execution. IA64 was a VLIW chip with in-order execution that relies on the compiler to do anything efficient.
HP made a fatal mistake cancelling PA-RISC and Alpha in favor of IA64. The could have picked either of the other two as a successor, and have been better off as a result. Instead they chose a dead-end, probably because (at the time) it looked like the entire hardware industry would go that way. Before SGI, IBM, Dell and others backed out.
I was a little surprised by GvR's answer to this. RHEL 6 ships with Python 2.6, last I checked, and we don't normally deviate from Red Hat packages without good reason. Getting the masses off pre-2.7 versions of Python will also entail releasing newer OS distributions and retiring older ones, both of which happen slowly.
Not everyone can keep up with the latest/greatest versions out there, especially when they have hundreds of servers and big legacy applications to support.
Why are you still using prefork? You have at least two good alternative MPMs, one of which can use epoll().
We have a ton of "enterprise" Java applications, from multiple *large* vendors, that we run at work, and they are the most buggy, slow, crashy things I have ever experienced.
Alright, I'm with you. I'll bet that any apps you get from those "large" vendors are going to suck, Java or otherwise.
And "enterprise" software? Our company is arguably an "enterprise", though I have yet to use any enterprise software that felt it was designed for us. I don't get that market at all. Don't sell me software that does everything, give me instead something simple that integrates cleanly with all the other software I already use.
Try hanging out in the open source circles, like some of the Apache Java projects, if you want another perspective. Then again, you probably don't. Just trust me... lousy software that happens to be written in Java isn't a reflection of Java.
Perl faster than Java? Perl faster than .NET?
You've never benchmarked any of these yourself, have you? (Please tell me you're not talking about benchmarking some "Hello World" application that can be measured in microseconds...)
I won't go into details now, but Perl 5 is really *spectacularly bad* at runtime performance. Pretty much at the other end of the spectrum from C/C++/.NET/Java (all of which compile to native, whether ahead of time or JIT, and all of which perform in the same ballpark for typical applications).
Wow, this is new. A rational, reasonable argument from a self-described Java hater... not just another "Java is slow because it's interpreted" or "Java is insecure" bullcrap post.
I've seen legions of developers grow frustrated with the gigantic frameworks and libraries that have grown up around Java, and react by abandoning Java and building something insanely simple in another language.
I wish just one of those guys would have instead tried abandoning the bloated frameworks and instead build something insanely simple in Java. I've done that, and found it very satisfying. But I'm aware I'm firmly in the minority having tried that, and in more than one case some other engineer grabbed my small code and bloated it up again.
"...by experience with Java apps is that they are incredibly slow, rather unresponsive and crash often."
Then you have no experience with Java application development. Or you're trolling, whichever.
Or possibly you're talking about browser applets, but that's not what this story is about.
If you don't have knowledge on the topic to contribute, why post at all?
You're kidding, right? We've been using MySQL replication for 10 years in production. Multi-master replication, statement-based and row-based. We've replicated between servers adjacent in a rack and servers that are separated by thousands of miles. And for the most part, everything Just Works.
The product may not be as academically pure, or whatever, as Postgres but that doesn't matter in a business setting. We use the tools that get the job done. On the other hand our team has been trying for the past month to get a Postgres (actually EnterpriseDB) instance to run in multi-master replication, or replicate DDL, without success. As far as we can see those are not supported features which make it almost useless to us.
It's comical how envious Postgres backers seem to be of MySQL's commercial success. And the quality of intelligent, thoughtful discourse on this forum is discouraging. Guess slashdot isn't what it used to be :(
Stop judging MySQL users. We use it because it has simple, foolproof replication. Period. And that's a damn good reason.
I know also what Oracle and pgsql can do. I've used both.
Can't really agree more. My challenge is the "cool kids" come along and rebel against anything from the 90's. I've seen newcomers build in Python, Ruby, and (the latest) Node.JS.
All of those are interesting in their own right, but for what we do I don't see them really solving practical problems that we haven't solved before. Except for stroking someone's ego--that they seem to solve nicely.
And as pointed out elsewhere on this topic, it's not as though Java has stood still. The most common complaint I've heard is that Java is verbose and Java code has far too much boilerplate "junk" (I tend to agree for legacy code--things like useless getter/setter methods and needless interfaces drive me bonkers). Then I ask them, what have you tried in Java lately? If you try to write compact, readable, maintainable code, you'll find it's not only possible but straightforward. Pick a few patterns that work well for you and stick to them (like chaining methods together as a builder pattern--one of my favorites).
Java gets a bad rap (and Oracle doesn't help) but there's nothing wrong with it per se. If I had the choice of starting a project in C, C++ or Java I'd always pick Java--call it obsolete if you want but those alternatives are archaic. (And I'm not fully sold on interpreters languages either, partly because my applications are very sensitive to runtime performance and memory overhead. Are the JIT compilers for Python et al any good?)
The security exploits are in the Java plugin. I don't care much about those because I disabled the plugin in my browsers years ago. Don't folks understand that 99.99% of Java users are unaffected by the plugin exploits???
When programming Java, you sure don't have to wrap everything in an object. Everything is in a class, but so what? Classes provide a namespace for your code, which is useful. They also give you lazy loading so you don't have to wait for an entire app to load.
There are a lot of bad Java programmers though. It seems too few of them have really learned CS and don't understand the internals or runtime well. That's a mistake when using any language.
Yes. We switched 6 years ago and never looked back. The java.util.Calendar classes in Java are pretty horribly broken--usability aside, they get some key calculations wrong, like ISO week of year.
The best part is that Joda doesn't need or use the time zone database bundled into Java SE, so they aren't affected at all by Oracle's support policies.
I just RTFA, from what I can tell this affects anyone who needs to run untrusted code in a JVM with a SecurityManager, not just applets.
That said, I can't think of any reason to do that besides applets, so most vulnerable users are those with browser plugins. Virtually everyone I know who runs Java deploys it within a servlet container where untrusted code is not normally a concern. Given that, the story seems a bit overblown.
As another poster pointed out, this is a false dichotomy. We're emerging from a technology monoculture of "every DBMS must be SQL" to "it's possible, even viable to design, implement and use a DBMS that does not implement SQL". Anyone advocating a mass exodus from SQL-land is a fool. Props to the NoSQL guys for opening our eyes to fresh ideas.
There's no need to stick with any single DBMS platform for 100% of your organization, unless you're so small that you have but one server total, and then I suspect this debate is largely irrelevant to you anyhow.
We're not Google, but we have some of the same problems Google faced with scaling up our applications for the Internet. We do use MySQL, having some 35+ instances of it. Our application processes in excess of 1000 transactions each second, and we know it'll be difficult to scale to tens of thousands of transactions per second without some fundamental changes. Today we survive by imposing limitations on developers writing OLTP applications--things like "all row operations must search by primary key" and "no table scans, ad-hoc queries or file sorts". The access language is still SQL, but increasingly we don't *need* SQL for OLTP transactions. We could plug in something today that is equivalent and far simpler.
What we're lacking in SQL-land is a good way to host DBMS applications on distributed infrastructure, e.g. in the cloud. There are clustered databases available, but these often require fast/short interconnects, may have difficulty scaling above bandwidth limits on a local network or SAN, and can be frustratingly fragile to use in the "real world". Not to mention expensive. This is due to the consistency model imposed on such systems, i.e. the "AC" in ACID.
Data sharding is a popular way to exceed the limits of SQL, but once you introduce sharding you're treading on "NoSQL" waters already. You can't retrofit sharding onto an application that isn't aware of it, not very successfully, in my experience. So developers need to become acutely aware of the storage tier and design for it, meaning they've already lost the perfect abstraction of SQL.
I'm keenly interested in emerging products like the Cassandra database, and while I have no intent of ever abandoning SQL (and probably even MySQL) in our organization, we're absolutely going to take "NoSQL" for a spin to see what it delivers in terms of cost, complexity, relability and performance.
The NDB releases basically forked from mainline MySQL. Latest is NDB 7.x, which is actually very good at what it does. Not *quite* ready for what we need but getting very close. ALTER ONLINE is a nifty feature... I've used it to add/drop indexes on the fly from tables in continuous use.
Earlier releases of NDB required that all indexes and data fit in main memory, but that has been remedied with disk data tables. Currently, disk data tables can only store fixed-length data (all strings are padded to their full length). Once that limitation is addressed, I'll be ready to look at it again.
If you applications need frequent table scans, forget about NDBCLUSTER. If however you meticulously access all your data by primary key, I find NDB scales just fine with workload.
Okay I'll bite. I'm not familiar with postgresql versions since about 7.x.
From http://www.postgresql.org/about/:
Which of these are not also true of mysql? The InnoDB storage engine also has MVCC, snapshot recovery, hot backups, etc.
What are the compelling differences?
Everytime I see this debate on slashdot it invariably degenerates into claims of mysterious missing features (what are they?) or non-transactional characteristics of MyISAM. Too bad, because I'm genuinely interested in a good comparison. I use MySQL extensively today but have worked on both in the past.
Anyone still tempted to go with the "non-acid" argument... give it up, else risk looking ignorant or foolish. MySQL is designed to support many storage engines. Anyone using MySQL this past decade who cares about their data creates most of their tables as InnoDB tables. And InnoDB is a very very good storage engine, if it matters.
I may have to try postgresql myself, if only to get to the bottom of this. What doesn't it have that I sorely need? Perhaps nothing. Then again mysql isn't missing much, either, for our needs. Perhaps, in the end, this is more like comparing AMD to Intel--no clear winner.
HP now sells Compaq, remember. The servers are actually quite good.
I'll bite... how is SFU deficient compared to Cygwin?
Basically, I think the effort of the Open Source community, of those that like Java, would be much pretty spent on making GCJ integrate seemlessly with a compliant Java VM using JNI.
I doubt that it would be practical. JNI does a lot of bookkeeping and is doomed to be far slower than whatever internal calling convention a JVM uses. You'd lose whatever advantages native compilation may have.
I hope developers would rather innovate and improve the java standard than to fork off a clone.
How can they innovate that for which they have no source code? The free implementation must come first. First they make it complete, then make it fast, then make it better.
Technically all that is true... but I can't help but remember some comp.arch discussions arguing the effectiveness of EPIC's technology in Intel's target market.
Specifically, there are problems in compiler technology that are hard to solve, especially in enterprise computing, which is where the money is that presumably will be spent on McKinley hardware.
Developers of enterprise software don't write code that is conducive to ILP. Those who do, in the HPC arena, aren't relevant to Intel's presumed target market of mid and upper-range servers.
There is as of yet little evidence that Intel can adequately solve the problems of branch prediction, alias analysis and operand prefetching in typical enterprise code to a degree that justifies the great expense of R&D they have poured into this experiment known as IA-64.
It is interesting to note that Java, because of lack of pointers produces impressive code for EPIC processors and is highly amenable to optimizations targetting EPIC.
Can you elaborate on this? Though Java doesn't understand pointers at the source level, surely most implementations represent object references as pointers.
I'd suppose Java doesn't have the aliasing problem as C/C++ but it suffers from other limitations, like overly strict language semantics, i.e. strict left-to-right evaluation.