Cassandra Rewritten In C++, Ten Times Faster

urdak writes: At Cassandra Summit opening today, Avi Kivity and Dor Laor (who had previously written KVM and OSv) announced ScyllaDB — an open-source C++ rewrite of Cassandra, the popular NoSQL database. ScyllaDB claims to achieve a whopping 10 times more throughput per node than the original Java code, with sub-millisecond 99%ile latency. They even measured 1 million transactions per second on a single node. The performance of the new code is attributed to writing it in Seastar — a C++ framework for writing complex asynchronous applications with optimal performance on modern hardware.

Comments

First post

[Anonymous Coward]

Because it was written in Seastar

Re:First post

[Anonymous Coward]

and had absolutely nothing to do with the comparison being Java

Re:First post

[interval1066]

Actually, this is a serious point; I'm curious to know what the results might have been had the re-write been in strait C/C++, no distributed framework.

%ile? Are We Texting?

[Anonymous Coward]

Seriously. WTF?

Re:%ile? Are We Texting?

[sexconker]

IDK, my BFF Jill?

Re:%ile? Are We Texting?

[Anonymous Coward]

%ile? What's wrong with %ile? :/

Re:%ile? Are We Texting?

[Anonymous Coward]

y u no txt bak?

Re:%ile? Are We Texting?

[RightwingNutjob]

Well, let's see. % means its a conversion code, l means the converted quantity is a long, i means its an integer, so a long integer, but e means it's a float to be converted to exponential notation. But it was supposed to be an integer. Does not compute.

Re:%ile? Are We Texting?

[Anonymous Coward]

it's a long int that should be converted to exponential notation.

Re:%ile? Are We Texting?

[jandersen]

Well, let's see. % means its a conversion code, l means the converted quantity is a long, i means its an integer, so a long integer, but e means it's a float to be converted to exponential notation. But it was supposed to be an integer. Does not compute.

Well, yes and no - this is obviously a python string formatting operator and ile is the variable they want to format into the string; the error is laughable, really: 99 is not a valid string. Talk about clueless.

Re:%ile? Are We Texting?

[Anonymous Coward]

u misspld srsly

Re:%ile? Are We Texting?

[pr0nbot]

le is obviously for little-endian.

Lies!

[Anonymous Coward]

That is a lie!

I think they mean the C++ port is 10X SLOWER than Java.

Java is faster than C,C++ everyone knows that!

Maybe if they ran the code on a java interpreter, written in java, running on a java interpreter...

More recursive use of java == more speed!

Why slow a system down with all that C++ bloatware?

Re:Lies!

[Anonymous Coward]

LOLOLOL!!!

There are tooooo many mods who just don't get jokes like this.

+5 Funny.

Re:Lies!

[hackwrench]

I thought it was partially because of people (alright, maybe they were all from marketing) saying that after bytecode was recompiled into code targeted to that specific environment, all future calls to the code would run faster than if the code had been compiled to target processor families. Or something like that.

Re:Lies!

[narcc]

It comes from an old (15+ years) defense of Java. The claim was that Java was no longer slow thank to JIT, with HotSpot making it possible for Java code to run faster than equivalent code written in C or C++.

OP is playing the part of a turn-of-the-century die-hard Java zealot cracking under the harsh light of reality, desperately clinging to their long-cherished beliefs.

Re:Lies!

[Anonymous Coward]

And back in 1997 I remember telling a C.S. prof. that java was running like a narcoticized slug. True I was running a 66 MHz '486 at home and the university labs were Sparc 1+'s (and since the profs were running some kind of global process 'lightly' on each, they ran slower than molasses in January anyway), but Java seemed to slow them even more. He told me all the stuff about just in time compilers, byte code yadda yadda. In the end, Java is a flavor of the month from 1997. I like javascript though. Its a crap language, has lots of problems, not that fast, but as a built-in on every browser, it allows more to be done in this medium than 'bolt-ons', is generally cross platform, and easy enough to code that even kids can learn it fast and easy.

Re:Lies!

[mwvdlee]

And it would have been funny (or atleast, less unfunny) 10 years ago. Right now it's the equivalent of making jokes about what fools people who believed in flat earth were. The people made fun of no longer exist.

Re:Lies!

[Anonymous Coward]

Not all true. Over the years I have compared "slow" languages Lisp, Java, and .Net to the "fast" C. For various odd reasons the slow languages were faster each time.

The modern Jit compilers have a huge advantage over C because they can do whole of program optimization and they can aggressively inline. Sure, one can declare C methods inline, but I compared Java and .Net to real production code where the programmers forgot to. So in practice the slow languages really were faster. And in-lined routines kill binary compatibility, particularly for access methods of opaque types -- not a problem for Java/.Net. Modern garbage collection is often actually faster than malloc/free, and certainly faster than any reference counting schemes.

Sure, there are some idiot restrictions in Java that make .Net faster, such as no structs and no way to turn off array bounds checking. But C is a technology that was out of date when it was first introduced 30 years ago. If any C compiler can beat .Net for some particular case it will be by a few tens of percent at most.

If this speed increase is real, it is nothing to do with C vs Java.

Re:Lies!

[jandersen]

The claim was that Java was no longer slow thank to JIT, with HotSpot making it possible for Java code to run faster than equivalent code written in C or C++.

Really? Sounds a bit rich to claim that an interpreted language would be faster than a compiled one, but I suppose if your interpreted program calls into some really well-written libraries, and you compiled program doesn't....

Be that as it may, I don't think it is all relevant any more. In many practical situations, Java is fast enough, and the fact that it defines and complies with a huge number of valuable standards - and is portable across HW and OS - is the main selling point. It is not a bad language to work with, and there are many practical applications for it. Good enough for the job at hand is, well, good enough.

Re:Lies!

[Dr_Barnowl]

Yeah, it's more to do with using a framework that helps with the aggressive use of computer resources than being in one language over another.

Some of the latency gains might be down to C++ vs Java, but the throughput is probably because the CPU is less idle.

Re:Lies!

[phantomfive]

Really? Sounds a bit rich to claim that an interpreted language would be faster than a compiled one,

The reasoning is because any bottleneck in code will be in a loop (or recursion, or whatever).
Java is roughly only interpreted on the first iteration of a loop, when it gets compiled by JIT. After that, it's assembly code, just like C.
Add to that, there are some optimizations that can be done at run-time by the JIT that can't be done at compile time.

These are typically the reasons people claim Java is faster than C or C++.

Also, it seems the Java creators at Sun were really competitive and got upset when people said their language was slower than C++, so they spent a lot of time optimizing the efficiency of their standard library, more than the C++ compiler writers of the time.

Re:Lies!

[TheRaven64]

Why are you talking about an interpreted program? We're specifically talking about JIT-compiled Java. Modern JITs use trace-based optimisation, which means that they will generate straight-line binary code for hot paths that span multiple method calls and returns. This is something that an AoT-compiled implementation can't do without a lot of profiling information. A JIT compiler can also optimise based on assumptions that are true for one phase of the program, then throw away the result if it stops being true for a later phase.

There are also other trades. For example, if you're writing memory-safe C++ and sharing pointers across threads, then you're going to be using std::shared_ptr, which performs an atomic operation (MESI bus traffic) on every assignment. In a typical JVM, copying pointers doesn't require atomic operations, but the cost of this is the GC pass. Depending on your workload, the GC cost can be a lot cheaper, a lot more expensive, or about the same as doing it correctly with smart pointers.

Unfortunately, a big part of the current 'Java is slow' claim is from idiots who don't understand that different GC implementations are all on a spectrum trading throughput for latency and who then build big distributed systems where tail latency in the edge nodes is important, then run a throughput-optimised stop-the-world collector on the edges and wonder why it sucks.

Re:Lies!

[Anonymous Coward]

Proving that Java is slow is as easy as running a java program with a chronometer. And it's not slow, it's sloooooooow. The only way you cannot notice it is if you measure it with a chronometer implemented in Java, or the awfully inaccurate GetSystemTimeInMilliseconds().

It is slow because the designers ARE idiots. I mean, just look at that horrible mess called JNI. Method calls for everything? Interface so unusable that Google had to spend 4 years of Google Summer Code to create a generating tool that bypasses having to learn its ugly syntax? Performance so poor that most of times calling native methods is slower than writing them in Java?

Java is the OSI of the programming languages, too many levels of abstraction that add a lot of junk code. And that junk code will still be there even after compiling to machine code. In addition to that, Java does not offer any way to efficiently implement algorithms to write or read efficient data formats, as the designers have refused for decades to implement bit fields and other basic tools available in C, as that would stain the purity of their vision. The result is a toy language that is always suboptimal for any purpose.

There is a reason Android is a far worse platform than iOS in every aspect, and that reason is Java. In fact, every step Google makes to improve the platform invariably consists in rewriting things that were implemented in Java.

Re:Lies!

[fisted]

The people made fun of no longer exist.

That's only because they fell off the damn rim, silly.

Re:Lies!

[Anonymous Coward]

I feel the need to point out that your post is unsubstantiated garbage. If your comparison has found that "slow languages are faster than fast because of compiler", your methodology is flawed. You're making a form of the argument of "the sufficiently smart compiler" which doesn't exist. Yes, if you had a compiler that could do everything you just said, it could be faster, but it doesn't exist. http://c2.com/cgi/wiki?SufficientlySmartCompiler

Re:Lies!

[Anonymous Coward]

Ok, I'll be switching all my ATtiny projects over to java as soon as I can find a JVM that runs in 512 bytes of ram. I mean, my C code sure is out of date. ...even C is damn bloat in some cases. Yes, different situations need different tools. If you want something multiplatform doing really simple (programming, timing etc wise) things java is just fine I guess. If you need to have actual control of hardware java isn't even on the "consider these" list.

Re:Lies!

[Anonymous Coward]

Java can be faster, but it really depends on what kind of fast we are talking about.

It takes time for the JIT compiler to kick in. It's configurable, but you gain nothing prior to it working.

Also, most of the stuff that is done to make Java fast is likely not going to look like code that the average Java programmer will write. Either the code will look embarrassingly small, or the code will contain specific provisions to avoid the garbage collector from ever finding anything to collection (with an eye for hardware sympathy). Neither one of these techniques are going to be found in your average Java programmer's code; but in your way-above-average Java programmer's code, you can make Java fly.

So, we are back to the main problem, which is that to do a decent job in C++ you need a better than average programmer (because the language has so many gotchas that average programmers don't excel) and to get C++ like performance in Java you need a better than average programmer. Perhaps the real problem is that you just need a better than average programmer.

I work in a shop with a lot of "better than average" programmers. They manage to break the "enum" contract, and occasionally they mess up the "equals" contract. You have to explain to them why doing Swing calls outside of the event dispatch thread is a bad idea, and they constantly violate the Liskov Substitutability Principle. They always complain about needing more manpower to fix anything and 90% of them are from India. Our code is a mess, but they are all "very good" programmers. In short, our team is comprised of a bunch of people who excel at patting themselves on the back, but after five years of using Java, they haven't discovered unmodifiable lists.

We could probably reduce our code side to a third, quadruple speed, and clean up our API with a team half of our size. However, we will never do that, as we now have Indian management, who's first order of concern is how to get more people, which means laying off the older developers to hire new cheap Indian developers. While it is true that these new people are able to program, it is as if they are programming without much study in what their code does to a machine. I see a lot of stack trashing as they put class specific logic outside of the class and then fetch all the data needed through get methods. Polymorphisim is rarely used, and when it is, often there's a method in the interface that lets you know which kind of base class it is. In short, if you want all of the maintainability of C in a Java language, I know the team for you.

I would like to hear more about the reasons Cassandra sped up, as I doubt it's just a 100% pure languages switch. Does the C++ version do automatic garbage collection? Did it restructure anything? I'll bet it did, as i don't think it uses Java's collections.

Re: Lies!

[Anonymous Coward]

Unfortunately Java ends up on tons of embedded devices that don't have a lot of horsepower, making for a very laggy experience.

I have a little game I play where I try to guess "Java" or "not Java" with any embedded device I find. Slow, laggy interfaces that take a couple of seconds just to change from one low res screen with a couple of buttons to another are always Java based. From BD players to car head units, the Java ones feel like you are on an RDP session over a 9600 baud modem.

I don't think it is impossible to make decently performing Java apps (Cisco ASDM surprised me), but it seems the norm are standalone apps that have all the responsiveness and lag of websites.

Re:Lies!

[gbjbaanb]

Except....

The modern JIT compilers do not do the kind of performance optimisations that they could, in theory, do. It simply costs too much in development time to cater for all the combinations and possibilities, or it costs more much in CPU time to calculate the optimisations than it would save in executing the slower code.

GC is faster than malloc for allocating, but when it comes to deallocating.. its a lot slower. Obviously, it has to do a lot more like compact the heap which is a pretty slow operation.

Most functions in C are inlined - the compiler has plenty of time to optimise a C program (ie the compile stage is a lot slower) that is can decide which functions are better inlined (based on size and/or call quantity).

Now you don't tend to notice much performance difference because modern CPUs are sitting spinning their wheels with cycles to spare - so the slower Java/.NET code still runs roughly as fast. But when you get server-side code that heavily uses the hardware - like this Database system - then you are really going to notice the difference.

There's one killer way to know if Java/.NET code is in fact slower than C++ native code: if the companies that produce it decide to create a native compiled version of their language. Which Microsoft has finally decided to do - .NET Native is building .NET source using the old C++ backend technology to produce native binaries. Microsoft says this makes their .NET programs run 30% faster. Still not as fast as C++ due to design limitations such as greater memory usage than a C++ program, but still - faster than old-style bytecode .NET.

The proof that C/C++ is faster than Java/.NET doesn't get more damning than that.

Re:Lies!

[ThePhilips]

Add to that, there are some optimizations that can be done at run-time by the JIT that can't be done at compile time.

The problem with the statement is that it misses HUGE number of over-expensive optimizations which can't be done at run-time because, duh, they are slow and very resource-consuming.

Which is why Java's HotSpot might produce fast code - but the code typically is times larger than what normal compiler would do. (Consider a simple example: It is easy to unroll the loop - but optimizing the resulting code duplication to improve the i/d-cache usage is a no-go at run-time.) The consequence is that HotSpot has to be limited in how much memory can be dedicated to the generated code, meaning that only small fraction of the code is actually optimized, and optimized only using the methods which can be actually performed in real-time.

The myth of the "good" Java performance is perpetuated mostly because the Java these days is stuck in the server-side niche (fat niche - but still a niche) where it has literally no competition, and nothing to be compared to.

so they spent a lot of time optimizing the efficiency of their standard library, more than the C++ compiler writers of the time.

That's a load of blatant BS.

First, Java standard library is full of slow retarded crap (consider the dead horse example of the String.split()).

Second, unlike Java, C/C++ are used heavily in the HPC (High Performance Computing) and there are people whose full-time job is nothing but optimizing the code, optimizing the compilers and optimizing the libraries. And some of the people are actually employed by Intel/AMD/HP/etc, the companies which actually produce the hardware and the compilers and the libraries. The vertical integration doesn't get more vertical as in this case.

Re:Lies!

[gbjbaanb]

i agree with Android. You can get apps that inspect the code frameworks used to create your installed apps (typically to check which of the many the ad libraries are being used). This inspection will tell you whether the app uses the Android native dev kit.

I use Addons Detector for this.

When I last looked, *all* of the games I had, ie that required good performance, were written using the NDK.

It beats me why they don't just dump Java completely (and tell Oracle to shove it) and use the NDK as the primary development platform.

Re:Lies!

[NostalgiaForInfinity]

It comes from an old (15+ years) defense of Java. The claim was that Java was no longer slow thank to JIT, with HotSpot making it possible for Java code to run faster than equivalent code written in C or C++.

High performance software requires several things, among them good native code generation and good libraries. Java used to have neither, then it got the JIT. Unfortunately, Java's semantics and built-in data types make writing high performance software in it really hard.

C++ started out with good native code generation, and its standard library and built in data types make writing high performance software a bit easier if you know what you are doing. Most C++ programmers don't know what they are doing, though, so their software ends up bloated and inefficient anyway.

Re:Lies!

[NostalgiaForInfinity]

You're right that Java's JIT is really good, but good code generation is not sufficient for developing high performance software. The problem with Java is that it doesn't support efficient abstractions. In C++, you can define high level abstractions and still have them compile down predictably to efficient code due to the existence of template classes, overloading, and value classes. In Java, using abstractions frequently kills performance. And unlike C++, in Java, you can't even "drop down' to a lower level easily: there are no unsafe or low-level operations in Java itself, and the JNI is also quite inefficient.

So, theoretically, you can write high performance code in Java if you use a good, modern implementation. But the experience is so tedious and cumbersome that you're better off using C++ anyway.

Re:Lies!

[DuckDodgers]

To address the parent post author's point and yours, you can game benchmarks a bit. If you know that a particular algorithm goes through 550MB of memory in Java, then you can set the Java Virtual Machine for your micro benchmark to use 550MB of memory and never incur the cost of the garbage collector during benchmark execution. Then you get very fast times for Java - but it may not translate to your long-running production application because unlike the benchmark, that is likely to make extensive use of the garbage collector.

Going forward, two things will help Java. Project Jigsaw for Java 9 attempts to make the Java Virtual Machine modular, so that instead of loading the whole standard library into memory before you can run "Hello World", it only loads the libraries your program will use. That will obviously dramatically speed Java start times and for most programs reduce total memory use, though it won't affect execution times. Project Shenandoah for the OpenJDK is an attempt to make a garbage collector that sacrifices about 10% raw speed for much better latency guarantees ( https://www.youtube.com/watch?... ) - in its alpha status in mid 2014, the benchmarked application had its garbage collector pauses dropped to a max of 15 ms versus a max of 75 ms using the OpenJDK G1 garbage collector. But neither of these things will put Java program execution speed on par with well-written C++ or C speed.

On the other hand, for any non-trivial application I wonder at the number of security flaws that will creep into the C++ or C code vs. the Java code. If you need ultra fast and also secure, the new hotness seems to be Rust.

Re:Lies!

[SQLGuru]

An *that* is why I think JavaScript should be the first language that new devs learn. I agree it sucks as a language, but it is SOOOO accessible with plenty of examples (good and bad) online. But the barrier to entry is essentially nil. Almost any computer (and certainly any computer released since Windows 95) comes with everything you need to get started --- a text editor and a browser (and modern browsers also include developer tools).

I'll take my offtopic mod back to my cave, now.

Re:Lies!

[Anonymous Coward]

Oh look, it's the guy who was clueless in 1998 and... still is.

Re:Lies!

[DuckDodgers]

I know it's only micro benchmarks, but according to this: http://benchmarksgame.alioth.d... C++ run through GCC 4.9.2 maintains a roughly 3x speed lead over Java JDK 1.8.0_45b14 in three benchmarks, a 2x speed lead in another three, a lead in another three, and a loss in two. That speaks very well for the JVM, really. There are a huge number of applications where that gap is acceptable.

But it also speaks to your point that JIT compilation still doesn't bring Java to the speed of well-written, optimized native code. There are plenty of other applications where a 2x or 3x speed advantage for C++ or C is critical.

Re: Lies!

[Anonymous Coward]

Read the information on their website. They provide quite a lot of detail. This was hardly a rewrite of cassandra in C++. It is a completely different database system implementing the same protocol as Cassandra. The internal architecture is different. The caching subsystem is different. Threading model is different. The feature set is a fraction of original Cassandra. And none of the things they did there are really exclusively available in C++. It could have been just as well written on Java or C# and still get all the benefits.

Re:Lies!

[DuckDodgers]

Just to be clear:

1. The Java Virtual Machine loads most of the standard library at startup, which is part of reason it starts so slowly and uses so much memory just for "Hello World".
2. Java bytecode is interpreted and profiled for the first 10,000 or so runs through any code path, so at that point it's not much faster than Python or Perl. Then after 10,000 times through a code path, the JIT-compiler kicks in and uses the profile information to rewrite the interpreted code as native code. Then Java becomes much faster than traditional interpreted languages, though still usually much slower than well-written C++ or C.
3. The amount of memory you allocate to the Java Virtual Machine can have a huge impact on performance for long-running processes. If your process keeps running near the memory limit, the garbage collector will have to run very often, maybe multiple times per second, and you'll spend large amounts of time in garbage collection. If you are able to allocate enough memory that the garbage collector rarely needs to run, that in turn will help a lot.

So if you're benchmarking "Hello World" in Java, or a Java program that has an execution time of just a few seconds, then your benchmarking methods are fine and Java is definitely not what you want. If you're trying to get an accurate evaluation of Java speed for a web server or some other long-running service, you need to test Java running as a web server or long-running service, run the benchmark for a few minutes to get an accurate picture of throughput in production, and tune the memory allocation to see how that impacts speed.

Re:Lies!

[DuckDodgers]

Also - Android was written in Java so developers could work on Windows, Linux, or OS X and so Google could attract the millions of existing developers that know Java around the world. Google didn't pick the language because they wanted the language, they picked the language because they wanted the ecosystem.

Also, arguably JVM applications are easier to audit for security and sandbox than native applications.

Re:Lies!

[T.E.D.]

Still, there's no good reason for it to be that much faster, unless the Java was also incredibly crappily written (which is quite likely). They are both compiled languages, written at about the same level. Something seriously wrong must have been going on in that code.

Note: This is from a professional C++ developer, who also happens to have done his Master's thesis on Compiler Construction. Admittedly, I don't care that much about Java, except in theory. Have only used it a few times. But either there was something going on with that Java program I'm seriously missing, or the rewrite speedup wasn't primarily about language.

Re:Lies!

[cb88]

It's a microbenchmark which is the worst case for a JIT... that said Java is pretty darn bloaty.

It would probably perform better on a long running calculation etc... given the same algorithms.

Re:Lies!

[Anonymous Coward]

On the other hand, for any non-trivial application I wonder at the number of security flaws that will creep into the C++ or C code vs. the Java code.

Well if you really want to start tossing security into the mix, then we need to have a rather frank discussion about all the security issues that Java itself has had over the years.

Re:Lies!

[naris]

I once had one of our "web admins" argue this point with me, and he was serious!

Re:Lies!

[naris]

Replace "flat earth" with "the earth is 6000 years old" and/or "evolution is a theory (which is wrong)" and/or "climate change doesn't exist". There are plenty of those around and I think some of them also believe in a flat earth!

Re:Lies!

[ZeroWaiteState]

I'm guessing it has more to do with the share-nothing message-passing design of the library the rewrite of the system was built on, meaning it scaled better across high processor core counts. There's an upper limit to how well Java scales if you run everything in a single JVM, due to all memory being shared between threads, the global garbage collection process, increased memory consumption (which affects cache locality), the Java security manager, etc. Due to the above, multiprocessor hardware has to do more work to keep the shared state synchronized between all of the cores. Notice in the memcached graph that even moving to separate processes and away from threads had a significant impact as the number of cores increased. The overall design of Cassandra is pretty distributed in nature, so the java version is probably sharing things between cores that don't really need to be shared in order for Cassandra to work as intended. Cassandra and other NoSQL databases (particularly CHORD-oriented designs) are probably fringe cases, though. I don't expect you would see differences this great in every application. I also suspect that if you were having to hit the disk a little harder the difference wouldn't be as pronounced either.

Re:Lies!

[DuckDodgers]

Sure. Oracle has really goofed with the Java Virtual Machine security. Funny thing, though: the JVM is written in C++. So:
1. You're making my point for me.
2. The JVM today is under a lot of scrutiny for security flaws, and is no longer getting a new zero day discovered every 87 minutes. Your new C++ code, or my new C++ code, doesn't get that same level of scrutiny. If we write our new code in Java, we get the benefits of the security audits in the JVM and aside from JVM errors the JVM prevents buffer overruns, pointer arithmetic, etc...

Re:Lies!

[ZeroWaiteState]

If you are relying on the JVM for security you are doing it wrong to begin with. In fact, there are some cases where you have to disable certain features of the Java security manager in order for some Java reflection APIs to work. You're asking the JVM to police itself. Mandatory access control implemented by the OS (i.e., SELinux), outside of the memory space of the application you are trying to sandbox, is the crutch you should be leaning on if you're really worried about security. Android is drifting in this direction anyway. Good security is hard, and pushing the easy button in Java only gets you so far.

Re:Lies!

[mrchaotica]

but I suppose if your interpreted program calls into some really well-written libraries, and you compiled program doesn't....

This is the key! Start out by writing your program in the quickest, easiest, highest-level (i.e., most appropriately idiomatic for the problem domain) language you can find, then benchmark it and re-write the slow parts to call some really fast C library.

Re:Lies!

[naris]

malloc/free and "reference counting schemes" would be just as fast, if not faster than" garbage collection if they never actually free memory and just continually use all memory available and then halt the program to free everything only when the memory is exhausted, which is what garbage collection does.

Re:Lies!

[Anonymous Coward]

Most Java CVEs are related to being able to break out of the security sandbox. They are only exploitable if your running untrusted code. Java does occasionally have a standard exploit though, like one I remember a while ago that a specific input to Double.parseDouble() would loop infinitely This allowed DoSing various Java frameworks such as allowing specially crafted HTTP requests to Apache Tomcat to DoS the server.

Re:Lies!

[phantomfive]

That's a load of blatant BS. First, Java standard library is full of slow retarded crap (consider the dead horse example of the String.split()).

I hope you're not one of those idiots who assumes C++ is automatically faster because it has templates. If you haven't timed it, you don't know.

Re:Lies!

[Anonymous Coward]

Not just Seastar, but because of Seastar and DPDK (a framework for doing very fast network applications). This is going to be a common pattern. Make it work in a high level language with good developers (that can program in C), and this version WILL be faster than a C program that was given the same amount of time and money. But once it matures and stops moving around, write it in a good C/C++ framework. Memcached and Cassandra now, HDFS later, etc.

Re:Lies!

[Anonymous Coward]

It happens all the time though. We have gotten calls from people porting our work to C++, asking us "how did you make this (java) code so FAST?". It mostly had to do with using simplistic data structures in C, and scalable ones in Java. However, once the design has become stable; it's pretty easy to imagine a C rewrite that is 10x faster.

But most projects do NOT survive that long. You can more easily go out of business before you ship your first version of a large C project. In the beginning, it must work. In the middle, it must absorb the pressures of success by scaling up. If it survives this, then it can be optimized.

Re:Lies!

[phantomfive]

The danger is they'll never move beyond Javascript. Your reasons are good, though.

Re:Lies!

[phantomfive]

Unfortunately, a big part of the current 'Java is slow' claim is from idiots who don't understand that different GC implementations are all on a spectrum trading throughput for latency and who then build big distributed systems where tail latency in the edge nodes is important, then run a throughput-optimised stop-the-world collector on the edges and wonder why it sucks.

More of the current "java is slow" claim comes from idiots who have never touched a profiler.........

Re:Lies!

[gbjbaanb]

don't confuse the runtime, whether its Java runtime environment or JVM or C+ runtime libraries, with user code.

C++ runtime libs are subject to scrutiny - you can see the updates regularly posted. At least with the C++ libs, apt-get or Winows update will patch your system quickly.. When I get a JVM update ... its a PiTA worthy of not bothering to update and simply uninstall the damn things instead.

C++ libs are also fitted with plenty of security checks too, though you tend to turn many of them off in optimised code, things like buffer overflows are still made for you. However you can bypass them with very unsafe techniques if you want to, unlike Java where you have little choice.

At least I've never accidentally installed a f***ing toolbar with a C++ runtime.

Re:Lies!

[david_thornley]

There was a case in the 1980s or 1990s when somebody wrote a numerical routine in Fortran running on their standard compiler and CMU Common Lisp. The Lisp version was faster. It turned out to be that the Lisp function calling was a touch faster than what the Fortran compiler used, so they improved the Fortran compiler.

Re:Lies!

[Anonymous Coward]

And funnily enough Java still runs a ton of the high volume networking code out on servers. WOW used JAVA for its networking layer.

What this story mostly proves is that highly specialized and skilled people can optimize the hell out of code with enough time and access to whatever tooling they like. In practice your average development team has 0 of these people on it, once in awhile it has 1.

When I write Java code the number one thing I go for is readability, because most applications simply don't have crazy optimization requirements.

So use the right tool for the job, but really, most jobs benefit most from readable and maintainable code.

Re:Lies!

[david_thornley]

There's other ways to do shared memory pointers in C++, to avoid the std::shared_ptr problem. If there's no real need to delete what it points to immediately, for example, allocate it before starting the threaded portion and hand out raw pointers to the threads, using a std::unique_ptr in a scope that outlives the threads. Most single memory uses aren't a problem. If the pointer owns some other resource that does have to be freed properly, standard Java practice is going to fail, but std::shared_ptr will work, if a bit inefficiently. (Garbage collection is typically a better way to handle memory, but RAII handles all resources in a uniform manner, and is therefore more powerful.)

Disclaimer: I know something about making C++ programs efficient. I know very little about making Java problems efficient. If somebody has an idea for making Java handle the single non-memory resource in multiple threads well, I'd be interested in reading it.

Re:Lies!

[Alomex]

Then after 10,000 times through a code path, the JIT-compiler kicks in and uses the profile information to rewrite the interpreted code as native code.

If only we had a way to compile into native byte code from the get go.

If there ever was a good reason for the JVM, I think it is long gone. Yet not only it is still around, now it is being copied by other languages without the least bit of thought as to the need for it.

For the normal program all it does is add a layer of intermediation slowing down your code with very little to show for it.

Re:Lies!

[Alomex]

They are both compiled languages,

Except that one is compiled off-line into blazingly fast native code, while the other is compiled to super-slow JVM interpreted p-code, and then at best compiled after a while into native code, while still carrying the overhead of JNI, baby-OS security, OO religion, incorrect parameter passing model, sacrifices in the name of portability (which at the end of the day isn't there: compile once, debug everywhere), etc.

Re: Lies!

[Anonymous Coward]

LOL !!

Re:Lies!

[DuckDodgers]

Good points. I meant the code developers write for their applications, not popular libraries. Of course popular libraries get good security audits.

I use OpenJDK on Linux instead of the Oracle JDK, and "apt-get update" or "yum update" (or now on Fedora, "dnf upgrade") takes care of everything for me. For Windows, I just switched to the Azul Systems Zulu build of the OpenJDK for Windows. So far it works fine, but the only use it gets is running Minecraft for my kids. I do everything on Linux.

Re:Lies!

[DuckDodgers]

For that benchmarks site, they run the benchmark 66 times and discard the first run. That stops the JVM startup from counting as part of the benchmark. But 65 runs probably isn't enough for the JIT to kick in, at least not on some benchmarks.

Re:Lies!

[DuckDodgers]

Good points. However, I think the JVM gives you things that might be difficult to add with cgroups and SELinux. But I may be wrong:

1. The JVM zeroes out all memory before handing it to an application, so your applications can't leak information to each other that way.
2. The javap disassembler makes easy decompiling of any Java application into a standard format that has specific references to APIs in the Java standard library, so I imagine it's straightforward to write code that disassembles each Java binary submitted to the Android store and then checks for illegal operations. Disassembling native binaries and scanning the code in an automated way for root exploits and malware is, I presume, technically more difficult. I would guess detecting code that, for example, mallocs a big buffer and then just reads the contents hoping to find a segment that cached your banking password would be difficult.
3. Require any code that your application loads dynamically have its digital signature checked first, and an absent or invalid signature blocks the load.

Otherwise yes, you can block file access and network access, constrain memory usage, constrain thread creation, etc... with security features native to Linux and not to the JVM. If I'm wrong, do correct me.

Re:Lies!

[Nicolay77]

IMHExperience, Java is much faster than C++ when it does heap object instantiation.

C++ new and the underlying malloc are just not as good as Java new.

However, if you can allocate your objects in the stack (or avoid using new/malloc in some other way), C++ really shines, and Java simply can't compete.

About everything else that's not memory allocation, yes, C++ seems to be a bit faster than Java, for the normal interpreted vs compiled reasons.

Re:Lies!

[Nicolay77]

> But the experience is so tedious and cumbersome that you're better off using C++ anyway.

Or use D and help us make D better. It's like a C++ with more powerful abstractions (do you like the auto keyword? it started in D) and similar performance to C++.

Re:Lies!

[Dog-Cow]

JIT can do runtime optimizations, which can take into account how the program is used, not just how it's written.

Re:Lies!

[Alomex]

Yes, I'm aware of this. Those optimizations consist mostly of relocating variables on the fly to reduce cache misses. Highly optimized code for applications like Cassandra is already cache aware and uses data structures which make optimal use of the cache. So all in all there are very little gains from JIT as compared to a highly optimized C/C++ version.

Re:Lies!

[Z00L00K]

The only case of fast byte code I have experienced was when I was coding Basic on the Zilog Z80-based computers running at 3MHz named ABC80 and ABC800. Not as fast as assembly, but got decent performance from that processor.

Compared to the Microsoft Basic on the IBM PC of that time with the 8088@4.77MHz that Basic was lightning fast.

Re:Lies!

[Xest]

Your professor may well have been a time traveller, as in 1997, Java was still interpreted, and it was only in 1999 that they switched to JIT compilation.

Also, Javascript has nothing to do with Java other than being a hastily cobbled together PoS designed to cash in on the hype surrounding the Java name in its early days.

In 1997 Java WAS slow, but it was also a completely different platform back then.

Re:Lies!

[Anonymous Coward]

Why is it the only people who argue against the speed of JIT compilation are people who clearly don't know what they're on about like you?

And no, the fact Microsoft has said that .NET native allows applications to START 30% faster (though actually it's 60%) is not the same as them performing 30% faster. We all know JIT has a first-run penalty, no one with a clue would ever argue that it doesn't. So .NET native lets you precompile the bulk of the application (but still executes on a minimal version of the CLR so isn't compiling to a native non-CLR binary like you seem to believe), so what? we already know this. It doesn't mean it allows faster run-time performance however. It just means you've read something you wanted to read, rather than something that was actually there and true.

Re:Lies!

[interval1066]

Actually, good point. I've been frequently amazed by some of the stuff I've seen written in js. The browser as a platform is alive and well, I guess.

Re:Lies!

[interval1066]

C++ libs are also fitted with plenty of security checks too

Uh, they can be. As a rule- don't expect a rule. But then that's the charm of open source. One can look and see what all that churning cruft actually does.

Re:Lies!

[interval1066]

IMHExperience, Java is much faster than C++ when it does heap object instantiation.
C++ new and the underlying malloc are just not as good as Java new.

First, I'd love to see some numbers to back up that statement. B) C/C++ has an actual use for those memory allocation paradigms; they're call pointers, actual locations in memory, and math can be performed on them, making them very powerful and fast compared to reference indexes. Java uses references, and they are completely different. You're comparing apples and oranges there.
C a bit faster than java in some kind of fantasy land? You're off your rocker, m8.

Garbage collected virtual machines!

[Anonymous Coward]

Almost as fast as native! Maybe even faster for some tasks!

sure

Re:Garbage collected virtual machines!

[fragMasterFlash]

"C++ is my favorite garbage collected language because it generates so little garbage"

-Bjarne Stroustrup

Re:Garbage collected virtual machines!

[Anonymous Coward]

"C++ is my favorite garbage collected language because it collects all of the garbage and keeps it out of other code."

- Me, when I read the first few words of your post

Re:Garbage collected virtual machines!

[Luke Wilson]

Most of what they've done seems to be rearchitecting, not getting a simple speed boost from using an unmanaged language. They're bypassing the OS to get more locality and cache retention. Those problems would not be addressed by merely rewriting in C++.

For one, they've replaced the OS network stack with an in-process one, where each thread gets its own NIC queue so they can have "zero-copy, zero-lock, and zero-context-switch[es]"

They're also keeping more data in memory and eschewing relying on the the OS file cache. It seems like they're taking every opportunity to use the in memory representation to avoid using sstables. They try harder than Cassandra to update instead of invalidate that cache on writes.

Re:Garbage collected virtual machines!

[IamTheRealMike]

The headline is rather misleading. This isn't just a plain port of the code from Java to C++ to get a magical 10x speedup. Amongst other things they appear to be running an entire TCP stack in userspace and using special kernel drivers to avoid interrupts. This is the same team that produced OSv, an entirely new kernel written in C++ that gets massive speedups over Linux ..... partly by doing things like not using memory virtualisation at all. Fast but unsafe. These guys are hard core in a way more advanced way than just "hey let's switch languages".

Re:Garbage collected virtual machines!

[Anonymous Coward]

But needless abstraction and virtualisation is precisely the core reason behind Java being so slow. It's not just the language that sucks, but also the coding practices, the "Java way" of doing things that is wrong. John Carmack's style guide specifically tell new programmers to AVOID most of the things suggested by the morons that designed java, such as writing getters and setters for everything. Java trains developers to become inefficient in any language.

Re:Garbage collected virtual machines!

[Anonymous Coward]

such quotes are really BS. quality of code has little to do with the language used. I've seen some amazing java code written and I've seen terrible C++ code written. yes, C++ produces little garbage as long as you are aware of how memory allocation works and how to take care of it. if you don't ... well... memory leaks and segmentation faults lay ahead...

Re: Garbage collected virtual machines!

[O('_')O_Bush]

It is a reasonable assumption that at most people writing in C++ made it past the first week of a CS101.

Re:Garbage collected virtual machines!

[DrXym]

I'm shocked that Stroustrup shows such a blatant bias for his own language.

Re:Garbage collected virtual machines!

[DrXym]

John Carmack writes games for a living. Games have to bend or break every rule to get as much performance out of the software. e.g. writing a square root approximation instead of calling a more expensive but proper square root function. It does not mean that those techniques are universally applicable or even represent good programming practice.

As for Java vs C++, I expect that most enterprises put stability and portability well above raw speed when developing software. Modern JVMs do just in time compilation meaning the performance differential is fairly slight particularly for IO / database bound middleware.

Re: Garbage collected virtual machines!

[Anonymous Coward]

It is not. There is plenty of terrible C++ code out there and it is not any better than Java or C# code on average. Anyone remembers KDE 4.0? I remember fixing one of their apps when in a single evening I submitted about 10 patches only to make the program barely usable and not crash every 5 minutes. Also, every router I ever had suffered from memory leaks and needs to be restarted once a week. The same is true about Android (and when they switched to more native execution engine ART things got much worse - many native, builtin android apps made by Google suddenly started being laggy and I heard they have some of the best C++ coders). And Android lags have always been due to poor native parts of the system, not Java. Android 5.0.2 leaks memory like crazy.

Re: Garbage collected virtual machines!

[dwpro]

Not really. My first and only programming course in high school was in c++. It was long enough ago that I don't remember well what we did, but it seemed pretty easy to make small functional applications without any knowledge of the basics of memory management. I bet with better tooling and language progression it would be even easier than it was 20 years ago.

Re:Garbage collected virtual machines!

[ZeroWaiteState]

It's 110% awesome.

Re:Garbage collected virtual machines!

[ZeroWaiteState]

Until it crashes, at which point it's all garbage.

Re:Garbage collected virtual machines!

[Anonymous Coward]

NASDAQ's largest stock exchange INET, touted as the fastest stock exchange system in the world, is written entirely in Java. All fast stock exchange systems attracting speed obsessed High frequency traders, are written in Java or C++.

The secret for Java speed, is to turn off the GC. NASDAQ do that by preallocating lot of objects that are constantly reused. That way GC is never triggered and you get extreme speed.

Re: ASS FUCK SHITCOCK FUCKWADS!!

[Anonymous Coward]

Ah... Crapple will do that Macbooks are much worse though.

Because it was written in Seastar or C++

[Anonymous Coward]

This is the trademark reason why Java shouldn't be used in performance sensitive environments in the first place.

As for would it have been any faster if it was written in C or straight ASM, probably not worth chasing down that extra 1%. Generally the justification for straight C or ASM is to remove runtime bloat, and you'd first have to give up using any frameworks to get there.

Just to remind potential programmers. Lean C before you learn any other programming language, otherwise you will not understand why your code's performance is terrible.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

But, but... Java is enterprisey!

Re:Because it was written in Seastar or C++

[Anonymous Coward]

Just to remind potential programmers. Lean C before you learn any other programming language, otherwise you will not understand why your code's performance is terrible.

This, and learn assembler or a basic flavor that doesn't call memory addresses for references or pointers before you go to C, otherwise you will most likely have troubles with pointers.

The thing isn't that you should program in C or assembly, it is that you need those to understand how to properly use higher level languages.
And if you are going to program C or assembly, learn a proper object oriented language before you write any serious programs, then you will have a better understanding on how to structure your program and solve complex problems.

Re: Because it was written in Seastar or C++

[Anonymous Coward]

Cassandra is nothing to sneeze out since it outperforms other db-engines (which are written in C, like MySQL).

Anyhow, you use the right tool for the job, and the big question is: would ScyllaDB even exist if Cassandra wasn't written first?

Re:Because it was written in Seastar or C++

[Anonymous Coward]

Just to remind potential programmers. Lean C before you learn any other programming language, otherwise you will not understand why your code's performance is terrible.

You can write terrible shitty code in C from a performance standpoint.
Thing is when all your culture is centered on Java, it's like the old adage "when the only tool you have is a hammer everything looks like a nail". There is a time and place for Java. Writing database engines in Java is not one of them if you care for performance.

Re: Because it was written in Seastar or C++

[Anonymous Coward]

Cassandra is nothing to sneeze out since it outperforms other db-engines (which are written in C, like MySQL).

Cassandra and MySQL are very different types of databases designed to handle different tasks. It's like saying a hammer is better than the saw without mentioning what job needs to be done with it.

Re:Because it was written in Seastar or C++

[Dutch Gun]

Just to remind potential programmers. Lean C before you learn any other programming language, otherwise you will not understand why your code's performance is terrible.

It may not be apparent even then. Java looks an awful lot like C++ at the code level. So... what's different? Java (and other managed languages like C#) have a bunch of neat features like reflection and automatic memory management, which inherently comes at the cost of runtime efficiency. Simply learning C or C++ won't point out exactly why those languages are so much faster than managed languages. You can write nearly the same code in C++, Java, and C#, and you'll see C++ win performance benchmarks - at least in all but the most contrived examples.

Among the more significant differences are that C++ compilers are extremely good at optimizing, and C++ code generally compiles down to better cache-coherent structures than other languages. The difference is in the language itself, which adheres to a zero-cost principle, in that you don't pay for features you don't use. A lot of C++ abstractions are eliminated *entirely* at runtime, and are only used to protect the code's integrity during the compilation phase. We were told for years that native-equivalent performance was just around the corner or even already here, and it just never really happened outside of small, contrived benchmarks.

I don't think it's necessary to always learn C or C++ first, although I do think it's worthwhile to learn it at some point, simply because there's a lot of it out there. I'm primarily a C++ programmer myself, but I tend to be a bit more pragmatic about language preference. Use the language that's right for the job. For example, C is a *horrible* choice if you're writing a simple application that needs to do a bunch of string processing. In many cases, high performance isn't even a consideration, rather than correctness, security, and development speed.

Re:Because it was written in Seastar or C++

[The Evil Atheist]

Just to remind potential programmers. Lean C before you learn any other programming language, otherwise you will not understand why your code's performance is terrible.

C doesn't let you understand why people's code has terrible performance. C has the same problems that make code slow - reference semantics. It's a mistake to conflate low level with "performance". For example, std::sort is faster than qsort, and you can't understand why just by understanding C.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

Just to remind potential programmers. Lean C before you learn any other programming language, otherwise you will not understand why your code's performance is terrible.

This, and learn assembler or a basic flavor that doesn't call memory addresses for references or pointers before you go to C, otherwise you will most likely have troubles with pointers.

The thing isn't that you should program in C or assembly, it is that you need those to understand how to properly use higher level languages.
And if you are going to program C or assembly, learn a proper object oriented language before you write any serious programs, then you will have a better understanding on how to structure your program and solve complex problems.

Learning how to resolve complex problems is what all the theory course at University are for... I have a BS in Computer Science from a respectable university, earned at a time when it was required to understand the underlying hardware architecture and the tools to be used to exploit it.

I have yet to meet a corporate problem I couldn't design a solution. Over the years .. I've picked up more than a dozen programming and scripting languages, which has kept me employed.

The answer isn't how well you program, it is how well you understand the problem and the infrastructure used to implement the solution.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

Um, this is assuming that the claims hold any truth. It seems highly unlikely there would be anything better then 2x as high throughput, and 10x is an extraordinary claim requiring actual supporting evidence.

And based on this dubious claim you make a sweeping claim that Java should be avoided. Classy.

I actually find it unlikely C++ rewrite that has functional parity would offer significant throughput improvements; it might have some incremental improvement (20-50% sounds plausible). Will be waiting for an independent third-party testing before claiming "C++ 10x faster than Java!".

Re:Because it was written in Seastar or C++

[Anonymous Coward]

While it isn't particularly surprising the C++ would come out faster than Java, a full order of magnitude of difference is. Either the java code was horribly inefficient (even for java), the C++ code is missing functionality, or some combination of both.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

They said to learn C first, not to actually use C in your performance critical application.

Re:Because it was written in Seastar or C++

[angel'o'sphere]

I would say that 95% of all people I know in person, who learned C first and not: Assembler, Pascal, SmallTalk, Lisp are extremely bad on advanced language concepts like functional or oo programming. Most of them shifted to scripting and operating servers and don't "code". A minority is doing embedded programming in C++ which mainly looks like C.

The idea that learning C first has any advantage is completely bollocks, a /. myth.

I started with C in 1987 ... on Sun Solaris (after 6 years Assembler, Pascal and BASIC) ... 1989 I switched to C++. I never looked back.

Only masochists would look back at C of that period.

ANSI C is much better ... but still: when I see a self proclaimed C genius with 30 years experience program Java or C++ ... shudder.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

Well said.

I would like to add to what you are talking about.

It is about abstraction. Abstraction buys you 'standup speed'. By that I mean it is 'easier' to stand something up quickly and make it work. Many times that is good enough. But when it goes down the shitter once you get past that infection point you have little idea why. You are being killed by a thousand little cuts. No one silver bullet will fix your code. It takes tearing it apart at the 'asm' level and figuring out oh that simple code is actually calling out to 20 different frameworks. Those frameworks are what help the standup speed. But they come at a crushing cost.

To give an idea. I am working with a C#/Java framework currently. None of my fellow programmers do not understand why the performance is getting slowly crappier. I do. One of our simplest calls in our system has a stacktrace of about 30 calls deep. All due to the frameworks that glue it all together.

Re: Because it was written in Seastar or C++

[Anonymous Coward]

Lisp is the first functional language.

Re: Because it was written in Seastar or C++

[Anonymous Coward]

And Smalltalk one of the first and most influential OO languages.

Re:Because it was written in Seastar or C++

[fyngyrz]

For example, C is a *horrible* choice if you're writing a simple application that needs to do a bunch of string processing. In many cases, high performance isn't even a consideration, rather than correctness, security, and development speed.

That is only true if you haven't written a string processing library. Which pretty much anyone who is going to address tasks like this will do, presuming they just don't go out and find one already written. Same thing for lists, dictionaries, trees, GEOdata, IPs, etc. Whatever. There's nothing that says one has to use C's built-in model for strings, either. Make a better one. It was one of the first things I did, and I did it in assembler, as soon as I ran into the convention of an EOT embedded in the actual text being the end marker -- I thought it was stupid then, and I didn't think a zero was any smarter when C first came to my attention lo those many decades ago. It's also a bear trap anyone can throw a bear into with regard to vulnerabilities -- one that can be entirely obviated by a decent string handling module.

C isn't a bad language to do *anything* in. It's just a language that requires you to be competent, or better, and to address it through the lens of that competence in order to get enough out of it to make the result and the effort expended worth the candle. And no, if the programmer doesn't write in such a way as to almost always create generally reusable components, I'd not be willing to apply the appellation "competent" to the programmer.

C's key inherent characteristics are portability, leanness and close-to-the-metal speed. It doesn't hold your hand. It's a language for experienced, skilled programmers when we're talking about creating actual products that are expected to perform in the wild. Lean code isn't nearly the issue it used to be, but it's still "nice" to have.

Re:Because it was written in Seastar or C++

[UnknownSoldier]

> Among the more significant differences are that C++ compilers are extremely good at optimizing,

LOL. No they aren't

Mike Acton gave an excellent talk Code Clinic 2015: How to Write Code the Compiler Can Actually Optimize where he picked an integer sequence to optimize the run-time to calculate the sequence. Techniques include: memoization, and common sub-term recognition. For 20 values pre-optimization time was: 31 seconds, post-optimization time was: 0.01 seconds.

Linked above.

Re:Because it was written in Seastar or C++

[RightwingNutjob]

Lean code is always an issue. If your code incurs a x2 to x10 overhead associated with the virtual machine, that's either 2-10x the hardware you need to spend money on to achieve the same throughput as before, and 2-10x the electric bill for compute-intensive applications. If you're nowhere near the limit of your box, you don't notice. If you've got rooms upon rooms of computers doing the same thing, and you're writing your code in not C/C++, then you're wasting money.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

The point of EOT strings is direct processor support for them, on ancient processors that no one uses anymore.

Re:Because it was written in Seastar or C++

[Entrope]

C++ compilers are pretty good at optimizing the code you write (subject to aliasing issues inherited from C, and so forth). They're not functional compilers that construct all kinds of state behind your back in hopes that it will be useful. If your complaint is that they don't do things like memoize results for you, somebody probably has a nice C++11 header that will, and most C++ developers will ask why you think a C++ compiler should memoize things without you asking.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

And the first version of ANSI C was C89, not very long after you claim to have started with C.

Re:Because it was written in Seastar or C++

[tepples]

But how long after C89 was ratified did it take angel'o'sphere's employer or school to acquire a compiler that conforms to C89?

Re:Because it was written in Seastar or C++

[phantomfive]

It may not be apparent even then. Java looks an awful lot like C++ at the code level. So... what's different? Java (and other managed languages like C#) have a bunch of neat features like reflection and automatic memory management, which inherently comes at the cost of runtime efficiency. Simply learning C or C++ won't point out exactly why those languages are so much faster than managed languages. You can write nearly the same code in C++, Java, and C#, and you'll see C++ win performance benchmarks - at least in all but the most contrived examples.

All that stuff comes at a cost, but not a 1000% cost.
If you're seeing that much of a speedup, then it's likely you were doing silly things in the Java version.

I'd rather write C than Java, but let's be honest about the performance: Java's not that much worse.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

I had a look at your YouTube link and 31 seconds was for the naive pre-optimized version in JavaScript. The post-optimized version in Javascript got down to 0.5 milliseconds. And then translating the JavaScript to C got down to 0.01 milliseconds. So, optimizing the JavaScript got a speed-up of about 60,000 and then rewriting in C got a speed up of about 50.

And that's consistent with my experience. The biggest speed gains are typically at the level of the overall algorithm. And then it's usually possible to get just a little bit more with language and compiler optimizations.

Re:Because it was written in Seastar or C++

[SQL Error]

C is ideal if you value raw performance over getting the job done.

Re:Because it was written in Seastar or C++

[phantomfive]

I would say that 95% of all people I know in person, who learned C first and not: Assembler, Pascal, SmallTalk, Lisp are extremely bad on advanced language concepts like functional or oo programming. Most of them shifted to scripting and operating servers and don't "code". A minority is doing embedded programming in C++ which mainly looks like C.

Almost no one learns to program in assembler, Pascal, SmallTalk, or Lisp as their first language these days. It's all Python now, or Java.

Re:Because it was written in Seastar or C++

[phantomfive]

That is only true if you haven't written a string processing library.

Memory management is still a pain though, because a lot of times you want to create a lot of new strings when you are doing splicing and inserting etc.

Re:Because it was written in Seastar or C++

[Dutch Gun]

I'm not trying to slam C. You can do just about anything in C - that's one of it's strengths. I'm just pointing out that it's not the *optimal* choice for certain types of tasks, in my opinion. C has advantages in it's relative simplicity, portability, and power. Moreover, it works very well as a "least common denominator" language, in that nearly every other language can easily interop with it because of it's stable ABI. This is why nearly every OS and many widely-used libraries are written in pure C.

That being said, it's very easy to make simple mistakes in C that can cause significant security or stability issues. The notion that you simply need to be "competent" in C to avoid making critical mistakes is a fallacy. ALL programmers make mistakes, as we're only human. There's really no getting around the fact that the language is inherently dangerous.

One of C++'s strength is that it allows you to create zero-cost or near-zero-cost abstractions that prevent the programmer from making those mistakes. C simply doesn't have those same mechanisms. Of course, this comes at the cost of language complexity.

There's a reason we have a wide variety of languages available - they all have different strengths and weaknesses. As for anyone believes a single language to be the end-all and be-all, I'd submit they simply don't have enough experience in other languages to make that judgement.

Re:Because it was written in Seastar or C++

[Dutch Gun]

You have to consider that compilers are also going to perform a wide variety of micro-optimizations that humans simply couldn't do on a massive scale, over millions of lines of code. No one would argue that a compiler can radically restructure your algorithms during optimization, because it doesn't know which side-effects are acceptable and which are not. So, yes, human programmers still need to be aware of how to structure code for best results on a given platform.

Of course, you can always find specific examples to highlight where optimizing compilers fail badly, and then build examples to highlight that deficiency. I took a quick look at that video, and to be honest, it seems a bit contrived, although interesting enough that I may watch it in full later. Thanks for the link.

Re:Because it was written in Seastar or C++

[TsuruchiBrian]

I know plenty of people who only learned C, but have no fucking clue how anything works.

Re:Because it was written in Seastar or C++

[UnknownSoldier]

The points are two fold:

1. Naive use of algorithms and OOP without understanding the data flow will always be slower then understanding and optimizing for the (data) cache usage.

Pitfalls of Object Oriented Programming

2. C/C++ compilers do a really shitty job of optimizing even trivial code.

CppCon 2014: Mike Acton "Data-Oriented Design and C++"

Mike demonstrates a simple example where a bool member flag is used as a test. MSVC does a horrible job at O2; Clang does a much better job, but still crappy. (Note: Using a different compiler backend on MSVC wasn't even an option until recently.)

Even a more slightly more complicated example blows up:

struct Foo
{
    bool m_NeedParentUpdate;
    int Bar( int count );
    int Baz( int count );
};
 
int
Foo::Bar( int count )
{
    int value = 0;
    for( int i=0; i < count; i++ )
    {
        if( m_NeedParentUpdate )
        {
            value++;
        }
    }
    return value;
}
 
int
Foo::Baz( int count )
{
    int value = 0;
    for( int i=0; i < count; i++ )
    {
        if( Bar( count ) > 0 )
        {
            value++;
        }
    }
    return value;
}

*Ugh.*

Why am I forced to remove ghost reads and writes and manually hoist common static evaluation out of loops?? Why can't the compiler deduce this information?

As Mike says, the compiler is not a magic wand. It is really good at only a _few_ transformations; it is really stupid about most other ones.

Re:Because it was written in Seastar or C++

[UnknownSoldier]

You may also be interested in my followup

I linked to second trivial case, which in practice tends to show up time and time again in typical game code, using member bools where C++ compilers fall completely over.

Compilers have a very narrow range where they are very good. Outside that domain, they suck at generating optimal code.

As I say there are 3 levels of optimizations:

1. Micro-optimization aka bit twiddling
2. Algorithm optimization
3. Data-flow optimization. Data Orientation Design focusing on the common (multiple) case, not the uncommon (single) case, and optimizing for throughput, not latency.

Re:Because it was written in Seastar or C++

[TsuruchiBrian]

The fact that compilers are better at optimizing some types of things than others, doesn't make them not extremely good at optimizing. On average they are better at optimizing than a human could ever be.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

NASA-JPL's Mars rovers run on C. Seems that C somehow has gotten the job done for them. Of course, with that sour-grapes sentiment, I very much doubt your ability is anywhere near theirs... :P

Re:Because it was written in Seastar or C++

[Dutch Gun]

Yep, I don't disagree with you. When I talked about optimizations, I was of course only talking about case 1. Anything above that certainly requires human-level work, and typically a substantial effort and deeper knowledge of the compiler and platform.

I wonder if the compiler does a better job if const is properly used? It's meant as a compiler hint, so that the compiler can be more aggressive because it knows there are supposed to be no side effects in the functions.

Also, I'd have a serious talk with a programmer who wrote crap like that in the first place. ;-)

Re:Because it was written in Seastar or C++

[dgatwood]

I would say that 95% of all people I know in person, who learned C first and not: Assembler, Pascal, SmallTalk, Lisp are extremely bad on advanced language concepts like functional or oo programming.

Not sure why people learning Pascal, assembler, or Lisp first would be better at OO. There's nothing OO about any of those. I would turn that around and say that 95% of programmers are bad at OO programming, period, regardless of what language they started with. Most folks frequently forget what are, IMO, some of the most basic rules of OO:

1. A class should be a mostly self-contained. If you have two or three classes that are tightly coupled, you should probably merge them into a single class unless there are data structure reasons not to do so.

2. A subclass should be used only when all of the following are true:

   • You need two objects that behave very differently, but share some common behaviors
   • The differences are easily achieved by replacing a few specific chunks of functionality that are reused in multiple places
   • The classes need to coexist

   Otherwise, if the behavior differences are minor, or if the functionality you're changing requires hundreds of tweaks, each of which is different from the next, you're probably better off using a property that switches from one behavior to the other and just using "if" statements.

3. Never create a subclass until you are ready to create at least two subclasses at the same time. Otherwise, you will invariably get the boundary between subclass and superclass wrong and will have to refactor it again anyway.
4. When you've created two or more classes that are substantially similar, that's the appropriate time to step back and ask yourself if you should create a superclass and fold the common functionality into it.
5. If your subclasses are more than about one or two levels deep (unless you're just using subclasses because your language lacks categories/class extensions), you almost certainly have a serious design problem.
6. Document your methods, their side effects, and their expected calling conventions early so that when you refactor it into a couple of subclasses, you can be certain that they all obey they same rules.

Re:Because it was written in Seastar or C++

[bondsbw]

Lean code may be an issue if performance is critical for your application/system.

If you are writing an app to manage photos, you had better favor reliability over performance or you might receive death threats from moms and dads whose baby photos have vanished.

Re: Because it was written in Seastar or C++

[Anonymous Coward]

Also learn functional programming so you can write good OOP code.

Re:Because it was written in Seastar or C++

[narcc]

Not sure why people learning Pascal, assembler, or Lisp first would be better at OO. There's nothing OO about any of those. I would turn that around and say that 95% of programmers are bad at OO programming, period, regardless of what language they started with.

For the Lispers at least, they'll, hopefully, understand the absurdity of the OO landscape. (They giggle when they see GoF "design patterns", and wonder how things went wrong.) It is, quite possibly, the worst trend, in history, to hit software development. OO is poorly defined, failed to fullfill any of the promises made by the great OO hype machine, and resulted in monstrously over-engineered products.

It's difficult to criticize OOP as no matter what you say about it, someone will come along and claim "that's not OO!". The worst part about that, of course, is that no matter your criticism, they're right. No one agrees on what constitutes OOP. What applies to Java doesn't necessarily apply to C++, Smalltalk, Python, ECMAScript, CLOS, C#, etc.

You've even fallen for the trap:

A class should be a mostly self-contained.

Are classes essential? "Obviously not!" say the Self folks,"They're extremely limiting! Even harmful!". "They're absolutely essential!" scream the Java lobby "It's impossible to do without them!". With perfectly reasonable arguments following from each side.

You said 95% of people are terrible at it, but I think that's an underestimate. I'd say it's closer to 100%. (Ask anyone and they'll tell you that you're doing it wrong, I'm doing it wrong, that guy over there is doing it wrong... The only one not doing it wrong is the person you asked. Ask someone else, and they'll tell you the first guy is doing it wrong!)

Either way, the promise that OOP was going to revolutionize software, making our lives easier, our programs more reliable, easier to change, and faster to develop has not only not been fulfilled, it's actually done the exact opposite. It's made our software less reliable, more difficult to change, and significantly increased the time it takes to deliver.

Worse, it's slowed progress on other approaches to development, and heaped countless distractions designed to ease the pain of OOP. From bloated IDE's to snake-oil "development methodologies" for leading your harried team through another over-designed project that follows the latest "best practices" from whatever trade-rag hit your supervisors desk that morning.

That ball-of-yarn dependency diagram and impossibly deep class hierarchy you see every day isn't a result of the applications inherent complexity. The OOP hype machine, coupled with the save-OO-at-all-costs consultancy industry, are to blame. Billions upon billions of dollars have been wasted chasing the empty promises made by marketing departments in the 90's. We're like the citizens of Idiocracy repeating "It's what plants crave!" despite the overwhelming evidence that it's all been a horrible mistake. Still, even conscientious developers, like yourself, defend it.

The LISP guys got a lot of stuff right. That's why they've endured and we're finally seeing a move toward functional programming. Here's hoping that we get the good parts, and not merely the superficial bits. (I'm hoping against hope, I know.) I'm no purist, don't get me wrong. Functional languages just aren't a practical choice for most modern development. That said, a healthy dose of functional influence just might save us from the OOP hell we've suffered from for the last 20+ years.

Re:Because it was written in Seastar or C++

[UnknownSoldier]

At the micro level, yes, agreed.

At the macro level. Not even close.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

That's a classic toy example. So making any conclusion based on that example doesn't mean much.

That said, I don't know what compiler you're using, but compile that code with GCC and you'll find that Baz has one loop, no calls to Bar, all invariants are hoisted out, etc, etc. Some other commercial compilers even completely eliminate the loop. You or Mike don't understand how much modern compilers can deconstruct the programs given chance - aliasing and lack of interprocedural compilation being typically the main bottleneck, but once those are removed/dealt with, compilers can do wonders.

Re:Because it was written in Seastar or C++

[TsuruchiBrian]

As a software engineer, I pretty much expect to be doing macro level optimizations, and I expect the compiler to be doing the micro level stuff that I can;t be bothered with. I still agree with the claim that C++ compilers (and really it's the language) allow the developer to better convey intent which in theory (and I am pretty sure in practice), allow the compiler to make better optimizations than it would otherwise.

Re:Because it was written in Seastar or C++

[ZeroConcept]

1. C is not portable, it's tied to the architectures/OSs/APIs the programmer chose to target at write time.
2. Leanness and close-to-the-metal speed are irrelevant in most business scenaios (time to market rules, cores and memory are commodity, see ABAP and related monsters successfully running most of the world transactions regardless of C).
3. C is not a language meant to implement business solutions, it's a wrapper for ASM for idiots who can't write ASM themselves.(rethorical)
4. Writing string processing libraries is tuff stuff, text can have different endings, (rethorical)
5. You haven't done anything really complicated that requires your focus to shift away from "bare-metal" to "time-to-value", by your own logic ASM is better than C.

Re:Because it was written in Seastar or C++

[balajeerc]

Not true much longer. Ever used QString?

Re:Because it was written in Seastar or C++

[dgatwood]

*shrugs*

I find functional programming to be dubious as a general tool, because it doesn't map onto the way people think about doing things. When I think about how to cook a meal, I think about putting particular ingredients together. I don't think about creating a list of items and combining operators, then magically evaluating those combinators all at once and getting a cake. The entire notion of lazy evaluation is simply antithetical to the way most people think about doing things. Functional programming, to me, ranks right up there with C preprocessor macros in the "Ooh, neat, I can do horrible things that will terrify mere mortals, but I probably shouldn't" category. I've done it; I understand it; I can't imagine ever, at least while in my right mind, trying to write a real-world application with it.

By contrast, OOP at least maps fairly cleanly onto the procedural mindset that most people use when describing processes without having to introduce clever hacks like monads. And OOP can be done well; I've just never seen it done well in Java. I can only assume that this is because most programmers learn by reading other people's code, and when you get enough terrible code out there, the natural trend is towards producing more terrible code. With that said, I've seen lots of Objective-C code that is reasonably well architected. I've seen lots of code written in C that uses structs as glorified classes that is mostly well architected. I've seen PHP code that uses classes well (along with a few absolute abortions, but I digress).

Re:Because it was written in Seastar or C++

[Anonymous Coward]

OOP advocates confuse encapsulation with all the syntactic sugar in their favorite OOP language. They even conflate the generic notion of an object--an object isn't always something that has methods.

Encapsulation is the skill to master. Methods on objects are not necessary, and in many cases not even sufficient to properly encapsulate a task.

Lexical closures, for example, are much more powerful than an object with methods.

Code generators (compile time and runtime; yacc, C++ templates, LPeg's grammars, and various other forms) are also a form of encapsulation and likewise much more powerful than OOP constructs. In high level languages these will return first-class functions or objects. Prototype-based languages (Self, JavaScript, Lua) are very helpful when implementing such a pattern.

Symmetric coroutines allow you to invert producer/consumer patterns, which is an extremely powerful form of encapsulation that hides caller/callee relationships. It allows you, for example, to transform a push-parser into a pull-parser. Lua is the only language I know of with completely transparent coroutine support that doesn't require decorations and is thus fully capable of hiding the relationships. (It also doesn't play games with the C stack.)

Lisp is an excellent language in the sense that it makes it easy to implement the first two, although s-expressions are kind of too low-level for my tastes, yet that's why it's so easy to do code generation in Lisp. But Lisp, in the form of Scheme, went the route of continuations instead of coroutines, which is again too low-level IMO.

Then there's things like lazy evaluation, a la Haskell, which is another spin altogether on encapsulation.

If people really want experience with proper encapsulation, they _must_ leaves the confines of popular OOP languages.

And the thing is, once you gain experience with all these different forms of encapsulation, you can implement some really amazing code in a language as simple as C, because while the syntactic sugar isn't there, you can emulate the patterns, often with very little code. I'm not aware of any language that offers all 4 of the features I mentioned above, certainly none of the most common ones (C++, Java, C#, Python, JavaScript, etc) so I tend to either code inplain C (clean, portable, interoperates with everything, few surprises), or pick a high-level language with features most appropriate to my task (often Lua), or both.

Re:Because it was written in Seastar or C++

[ZeroConcept]

Barring specialized service providers, compute costs are seldom the biggest item in company expenses.

Re:Because it was written in Seastar or C++

[ZeroConcept]

I agree, legacy technology is the best case use for C.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

C is portable. Platform-specific pieces can be controlled to individual elements of files fairly easily. Do you mean it's compiled?

Er yeah. If you're using platform-specific APIs. How would you use platform specific APIs in Java again (a DirectX JNI)?

Re:Because it was written in Seastar or C++

[ZeroConcept]

Re-read your statement:
"Platform-specific pieces"

Means Not Portable.

Java has no "Platform-specific pieces" as part of the spec.

Java is not meant for 3D game programming.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

And your point? Hardware is a very significant portion of that project, so they can't just throw more hardware at the problem. Even though their programmer and testing cost is quite high, they value the performance over the time it takes to get things done. This is not always an option for businesses where a piece of code not run very often or for very long means that the hardware is far cheaper than programmer time.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

Don't forget this is a distributed database; latency is everything.
If your Java runtime starts garbage collecting inside a transactio, the latency of the transaction goes up. Even if just a few transactions have a higher latency, the whole system suffers from this exponentially.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

If you're slicing and dicing arbitrary strings in C, you're doing it wrong.

If you're juggling strings that way, it means you're dealing with a lot of unstructured data. If you're dealing with unstructured data like that t almost certainly means:

1) You're implementing a rapid prototype. In that case, you should use an appropriate dynamic language.

2) If you're not implementing a rapid prototype and you haven't implemented a layer that turns arbitrary strings into structured objects, then you're not a very good programmer. Good C programmers make use of things like parser generators. They know how to write state machines and implement or make use of domain-specific languages. With the exception of text editors, well written C code doesn't juggle arbitrary string data. If your idea of a parser involves regular expressions and if/then ladders, then you definitely shouldn't be coding in C. And you probably shouldn't be coding at all, because the string libraries in proper languages make it too easy to write brittle and bug-ridden string processing code. I think Perl is a decent language, but the way it popularized regular expressions set software engineering back decades. Perl 6 has grammars as first-class objects, but alas nobody uses Perl 6. (The Lua module, LPeg, implements grammars as first-class objects with novel and cutting-edge capturing extensions, making Lua perhaps the best modern language for string processing.)

This is why people who complain that C doesn't come with a library of generic data structures miss the point. Programming isn't about slapping together hash trees and bloom filters. Those are easy to deal with (anyhow, POSIX provides both hash tress and red-black trees in search.h). It's about structuring your application and the code around the data, which often requires transforming string data into well-structured objects using robust parsers. If your task is so simple that a few regular expressions and a built-in hash object are more than enough, then there's little reason to be using C.

(People claim that C++ is a good middle ground, but I'm more of a use-the-best-tool-for-the-job kind of person. If you feel the urge to make use of the STL or Boost, then that's a strong hint that you might want to consider a higher-level language--Lua, Python, JavaScript, Haskell, etc. C++ programmers tend to rely on template gymnastics when they should really be learning how to use a better tool--e.g. Ragel, yacc, ANTRL, a domain-specific language, etc.)

FWIW, in my experience C is an _excellent_ language for writing both parsers and low-level data structures. Pointers are an incredibly powerful abstraction when dealing with trees or parsing binary data. Those who think of pointers as low-level constructs instead high-level constructs really are missing the point of C. If you think references are always better/safer/more convenient than pointers, then I don't know what to say. (Again, this is why I don't like C++. When C's constructs are not appropriate for a task--as they often aren't--even if you still want to stay close to the so-called bare metal, there are far better languages than C++, such as D, Go, Rust, etc.)

Re:Because it was written in Seastar or C++

[goose-incarnated]

I would turn that around and say that 95% of programmers are bad at OO programming, period, regardless of what language they started with.

That's because 95% of written OO solutions don't fit an OO domain. There is this myth that OO is the best we have, but in reality OO is very counter-intuitive to the human brain. Most OO solutions would be better off structured. The human brain handles that much better than OO.

Re:Because it was written in Seastar or C++

[rioki]

learn a proper object oriented language before you write any serious programs

Although I agree with the general gist of your comment; I could not disagree more strongly about learning a "proper object oriented language". I would rather have you learn functional programming than object oriented; but optimally both. The problem is that allot of object oriented code is redundant and bloated, generally stemming from kingdom of the nouns type syndrome. Hybrid languages like C++ or JavaScript are genius in that you can mix functional and object oriented programming to form a concise solution to the problem.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

Guess its a corner case where C is king. You wouldn't want my job, and I don't want yours. :)

Re:Because it was written in Seastar or C++

[omfgnosis]

Your characterization of functional programming is pretty astonishing, to me as a person who was most recently employed writing and maintaining software in Clojure. The following are all surely idioms, features or possibilities of one or another FP language/approach, but none of them are essential to FP:

1. "creating a list of items and combining operators, then magically evaluating those combinators all at once and getting a cake" — I think the reality is that this can be overdone (and sometimes it is), but for people who live and breathe the abstractions that come with a FP language, it tends to reflect the expressive qualities of core concepts and operators-as-functions. (reduce + 0 args) is just a whole lot more expressive, when familiar, than total = 0; for (val in args): total += val; return total.

2. "lazy evaluation" — I'm not really sure this needs to be specific to FP, but it does really shine with abstractions often associated with FP (e.g. map, reduce, filter, and so on).

3. "macros" — I cherry-picked this away from the C preprocessor reference to contrast with lispy/homoiconic macros, which are hardly the nightmare of metaprogramming in languages with every-which-way syntax, but even when macros are sane they tend to be strongly discouraged.

4. "monads" — I see monads far more in imperative code than functional, so I don't even. (I'm talking about the lovely Promise pattern, which is excellent.) Then again, I don't write Haskell.

I'd characterize FP differently: a function of a given set of arguments should always return the same value, without side-effects; in non-pure languages, add the caveat unless you have a good reason, which should be identified clearly in code; with that caveat, you can kinda do FP in any language (though it may be horribly inefficient).

In other words, stateful code is hard to reason with, and the greatest care should be taken to making it clear when it cannot or must not be avoided. This should be true in any programming environment.

You're right that people tend to mentally model in terms of objects—that is, the combination of data and action. But it doesn't have to be stateful by default, and there's a lot to gain from reversing that.

- - -

A little anecdote: for kinda silly reasons, I've been doing some one-off work in Node.js after spending a good long while in Clojure. It came time for me to reverse an array, and I wrote code like the following: var foo = bar.reverse();. With almost no real JS work for over a year, I could not recall the following:

1. Will bar be reversed?
2. Does Array#reverse actually return a reversed array value, or something else?

I couldn't know what that very simple code does, simply by reading it. I had to go evaluate it! It turns out that Array#reverse is a bit unusual in JS as it is both stateful (it reversed bar) and it sort of looks like it returns a value (it returned a reference to bar). That code which should do an obvious thing actually caused a bug, because I had to make guesses about state, and I guessed wrong.

- - -

There are reasons to choose a stateful implementation—performance, expressiveness, interop with stateful environments or libraries—but it's not a given, and not even always consistent with a normal mental model, for statefulness to be assumed.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

A subclass should be used only when all of the following are true:

• You need two objects that behave very differently, but share some common behaviors

Congratulations, you don't get OO either.
Inheritance for re-use is quite possibly the worst reason ever to use subclasses. Inheritance should be used when you need polymorphism and the two objects behave *alike* - AKA the Liskov Substitution Principle. (Public) Inheritance that violates some of the assumptions of the parent class is really painful.

But you know what, you are still entirely correct that probably about 3 programmers in the world "get" OO, and I'm not one of them either.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

This is a horrible example. Yes, std:sort can be faster than qsort. But I could also implement a sorting algorithm as a macro and stuff it in a header. It might be ugly with all the backslashes, but it'll be just as fast as std::sort and just as type safe. And it's the kind of thing you write once and never go back to, assuming you have to write it at all. All the BSDs, for example, have which implement red-black trees this way. All the BSDs and Linux have (from BSD), which implement various lists this way. (The BSDs have better versions; the glibc people have destroyed their fork.)

This is penny ante stuff. Templates are a great construct, but not because of performance. All that code generation resulting from abusive template usage destroys CPU caches. And C++'s penchant for creating dynamically allocated temporaries... don't even get me started. I've seen C++ code with orders of magnitude more memory allocations and frees than comparable C code, so if you want to to go head-to-head with idiomatic C code vs idiomatic C++ code, you might not like the results.

In the grand scheme of things, C++'s improvements over C are not that great. And by grand scheme I mean looking at the amazing constructs in Haskell, OCaml, D, Go, Rust, etc, which will all compile to native code. C++ is only a nice language when you arbitrarily exclude everything else, including excluding features added to C with C99 and C11 and rejected by the C++ committee (compound literals are helluva useful and very performant).

Personally, I use C because of the simplicity and the fact that it will integrate well with almost every other language, whereas with C++ you have to deal with exceptions, ABI issues, standard library issues, etc. I recently wrote a perfect hashing algorithm which can generate a perfect hashing function for millions of keys in a few seconds or less. I originally wrote it in C I decided to port it to C++ to make use of templates. After all the hassles--such as struggling with namespaces and scope (turns out preventing C++ from exporting symbols is often impossible without making use of compiler-specific extensions), and making std::string compile-time optional so that when loaded in Lua or Perl it didn't load the gargantuan C++ library and possibly conflict with modules using a different C++ library--I almost felt I'd have been better off using M4 to generate type safe code.

Re:Because it was written in Seastar or C++

[phantomfive]

I'll have to think about your idea of grammars to parse everything......that seems like overkill to me.
Certainly there things which are more easily parsed by regular expression.

Re:Because it was written in Seastar or C++

[dinfinity]

Ask anyone and they'll tell you that you're doing it wrong, I'm doing it wrong, that guy over there is doing it wrong... The only one not doing it wrong is the person you asked. Ask someone else, and they'll tell you the first guy is doing it wrong!

This is a notable truth. The thing with (even mildly complex) OOP (and programming in general) is that there is not one perfect solution. The solutions only differ in the tradeoffs one has to deal with at that time and in the future. The (very hard) challenge is thus to choose a solution (a set of design patterns, a sensible entity model, etc.) that has the least troublesome tradeoffs for the project at hand.

Given that people tend to become fanboys of pretty much everything they have some extended experience with and investment in, they tend to choose and prefer solutions that they have come love, even if those solutions aren't the best choice for the project. These guys also tend to attack other solutions to prove that theirs is the One True Solution. They use all kinds of hyperbole, make tons of unfounded bashing statements and say stupid shit such as "That said, a healthy dose of functional influence just might save us from the OOP hell we've suffered from for the last 20+ years."

Re:Because it was written in Seastar or C++

[Anonymous Coward]

Ummm no. Totally disagree, but I think its one of those "Some people memorize and some people visualize." situations. I can do both OOP and structured, but for complex multi-relational programs, structured SUCKS. I like the idea of having objects hang in the air that behave certain ways. Once I define the interface to it, I can dive into it and optimize the objects implementation without altering its behavior. After which, I can totally forget the implementation and just keep the simple interface in mind. I can do this with each and every object followed by stringing them together in various ways to complete the task. It also flows very well into Parallel programming as each entity becomes a simple state machine.

Its that ability to go from the ants, to the 50th floor, to the bird's eye of OOP that makes it so appealing. Not to mention how easy it is to split the implentations up across teams and individuals. I can kind of do this in structured too, but there just appears to be so much overhead in doing so. You build so much infrastructure using files, headers, and locks. OOP is like having legos, structured is like having grains of sand. For really big stuff, OOP is just easier.

Re:Because it was written in Seastar or C++

[Dr_Barnowl]

C++ code generally compiles down to better cache-coherent structures than other languages

It's possible to do cache-coherent programming in managed runtimes - it's mostly about knowing the rules though, and people who've never used unmanaged languages are less likely to know the rules.

Everything that's an "object" is a pointer, and they'll be scattered all over the heap. The only way you get cache-coherency is using structs, which not all managed languages have, or arrays, which even managed languages allocate as a contiguous block of memory.

I've written sorted collection classes in Java that use this principle, they handily beat the included framework classes like TreeMap in terms of both performance and memory overhead, using nothing more exciting than byte[] as index blocks.

Re:Because it was written in Seastar or C++

[phantomfive]

As for would it have been any faster if it was written in C or straight ASM, probably not worth chasing down that extra 1%.

Assembly can give you huge performance gains, much more than 1%. One of the reasons why is because it gives you more control of caching. Paul Hsieh has written quite a bit on this topic, it's worth checking out.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

How does using a simple, straightforward, portable and easy-to-read language stop you from getting the job done?

Re:Because it was written in Seastar or C++

[phantomfive]

On average they are better at optimizing than a human could ever be.

What? No way! If you want to do better than the compiler, follow these steps:

1) Compile your program, get the assembly output from the compiler.
2) Find improvements (this will not be hard). Profile to determine how much faster your changes are.
3) After many repetitions of this, you will get good enough to write faster than the compiler without getting the assembly output.

Compilers do better than an average human writing assembly, but that's only because most humans aren't good at writing assembly. It's not hard to get your skill level up to the point where you can beat a compiler regularly.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

I write C every day, but if I'm going to do string processing it's going to be in python, bash, or some other scripting language.
Any string processing I do doesn't end up in any product though, and is purely for data analysis by me, so there is no point in wasting my time writing a string processing library imho.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

Common Lisp (only the first letter is upper-case) is a multi-paradigm language and unfortunately Common Lisp is not an especially good functional progamming style language in any current implementation. In particular, it is not safe for space in tail call optimizations, it lacks mechanisms to allow for precise beta-reduction optimizations, and the two combine to force the programmer to think about the tail call slot. That's part of the reason why the loop DSL exists in Common Lisp and why it's used instead of FP idioms that lean heavily on recursion (which is liable to blow your runtime stack).

From R4RS onwards, Scheme became a fully safe-for-space Lisp-like language for any conforming implementation, and eager FP idioms are no problem for modern Scheme compilers. Ignoring the vast minimum library set in Common Lisp, translating from idiomatic Scheme to working CL is often a lot harder than from idiomatic CL to working Scheme, and that's mainly because CL is usually *not* purely (and sometimes not even mostly) functional programming style. (And related languages such as Emacs elisp are even less likely to use functional programming style). Compilers suffer because they are not forced to deal with full-blown FPS, and full-blown FPS is heavily constrained because the compilers can't cope with it.

Note that that's *style*. CL functions are typically referentially transparent compositions of referentially transparent functions, and so meet the most basic criterion of FP. But you can do that in C89 too, and nobody really calls that approach functional programming.

Re:Because it was written in Seastar or C++

[TheRaven64]

OO, as defined by Alan Kay (who invented the term, so in my mind gets to decide what it means) is about decomposing your problem into isolated parts, constructing small special-purpose computers that solve individual parts and communicate by well-defined interfaces. There's a lot of cargo-cult cruft built up around the idea since he came up with it in the '60s, but the core idea is still very important (especially once security matters and you want to compartmentalise your application).

Re:Because it was written in Seastar or C++

[TheRaven64]

Note that r-value references and move semantics in C++11 improved the state of this a lot. Templates still create a lot of potential bloat, but if you're writing templates well (i.e. for things that should be templates, not simply calling methods) then the specialisation means that you can do a lot of inlining and then deletion: 3-4 specialised instances of a template can often end up being smaller in binary code than one generic implementation.

Re:Because it was written in Seastar or C++

[angel'o'sphere]

I doubt any school/univeristy around that time in Germany used C as teaching language.

C is horrible as a teaching language. Typical languages where Pascal, in small extend C++, then Java, Eiffel, Sather. Most European universities prefer to use their own pet languages for teaching, e.g. Sather-K in my case at University of Karlsruhe (TH), now called KIT. In Swizerland it was Oberon, in France partly Eiffel, in Scandinavia Simula and BETA.

A few years after I started studying (I learned programming in school, so I did not bother attending any classes in the University) beginners programming classes where in Haskell (mine before was in Pascal). At that time I was in the 4th Semester and learned during 4 month, lambda-calculus, Prolog, Lisp and SQL and some esotheric logic calculi or languages.

For my own education I did IBM-Mainframe Assembler and Fortran and a little bit of Assembler on a Cyber 205. Later I maintained a PasPar (massive multiprocessor super Computer) programmed in a Special "parallel Pascal" or "parallel C", don't remeber.
My Institute did lots with Transputers, but I never really got into them.

Anyway: I never met a Person my age or up to ten years older, that had C as their first programming language.

Everyone who even could do C had learned an Assembler first (General Data, Amdahl, Unisys, Honywell etc.) And everyone who later went into C already could program in Pascal or Modula 2.

My employer at that time was the University, obviously. And I doubt they keenly jumped onto a C89 compatible compiler. They usually used the vendor supplied compilers (we had SUNs, HPs, DECs mainly ... and ofc: Macs for the students to program in Pascal or C++ on)

Oh, I forgott: I indeed worked as a C programmer around 1990 or a bit later in robotics under Prof. Rembold. We had a roboter with Mercanum Wheels, https://en.wikipedia.org/wiki/...
I did program the distance and ranging with ultrasonic sensors around the vehicle.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

Having used GCC I can tell you is probably one of the worst in the bunch, lacking basic optimizations that have been present in introductory books written more than 20 years ago. In fact, the only good thing I can say about GCC is that their incompetence and stuborness made possible Clang, a compiler written by a far more competent team.

With GCC, I have been forced to reorder code or add useless commands that do nothing just so that the stupid compiler notices a trivial optimization. And not a single time I could trust the compiler to perform even the basic task of moving a variable declaration out of a loop. In fact, years ago I came to the conclusion that they do not perform optimization at all, but if you do not set the -O3 flag its add junk code on purpose so that it runs slower.

Re:Because it was written in Seastar or C++

[Entrope]

Your first link doesn't say anything about compilers -- it's about cache locality and branch prediction, and how the application's architecture can make those more or less of an issue.

I watched part of the first Mike Acton video you linked, and was reminded why I hate watching videos to try to learn something: People talk too slowly and basically never organize their information for efficient understanding or consumption. I'm not about to sit through another one to find out he is mostly complaining about how slow some Javascript interpreter's general-purpose function calls are.

I will grant you that MSVC has traditionally been an awful compiler, and Clang is too new to be very uniformly good yet. As an AC pointed out, gcc does a decent job with your toy example.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

I agree quite strongly.

I make most of my living these days moving utility methods out of remote public static final locations into the class instances that they solely access. It's like the people who were writing this code never have heard of encapsulation, and they only put "get" methods around the instance variables because that's what they were taught they should do. If they weren't taught that, odds are good they'd have public member variables (and occasionally they do)!

I'm all for learning C so you can learn how the conceptual "computer model" works. However, I would strongly recommend "learning C" to become better at a different language, which means that you will have to learn that different language. If you only have time to learn one, learn the language you will be using, and skip the C, as doing it the other way around has you programming C in your new (mostly unlearned) language.

Re: Because it was written in Seastar or C++

[Anonymous Coward]

Not to mention that object oriented programming is abstracted from what is being done at lower levels. It would be better to first understand how the program "flows" before learning the object oriented paradigm that had little to do with the underlying processing going on.

Re:Because it was written in Seastar or C++

[NostalgiaForInfinity]

Java (and other managed languages like C#) have a bunch of neat features like reflection and automatic memory management, which inherently comes at the cost of runtime efficiency

Reflection and automatic memory management have almost no runtime cost. In fact, C++ pretty much offers both.

Simply learning C or C++ won't point out exactly why those languages are so much faster than managed languages.

Switching from Java to C++ won't make your code magically faster. In fact, if you continue to write in Java style, your C++ code will probably be even slower than the equivalent code would have been in Java (not to mention a lot buggier).

The difference between Java and C++ is that a competent programmer can write code that uses abstractions yet predictably compiles into something efficient in C++. But taking advantage of that requires a lot of skill and experience.

For most people, Java (or C#) is probably the right choice: it gives them acceptable performance and keeps them from screwing up too badly. Most programmers simply lack the skill and experience to write halfway decent C++ code.

Re:Because it was written in Seastar or C++

[NostalgiaForInfinity]

C's Achilles heel is the lack of standardization of common programming facilities. That is, you can write a kick-ass piece of software in your mom's basement using your own homegrown set of string libraries and OO abstractions, but the guy in the next basement over will have a completely different set of tools, and making the two work together will be an exercise in frustration.

C++ tried to build on C's strengths while standardizing a lot of stuff; that's why it has become so popular.

Re:Because it was written in Seastar or C++

[SQLGuru]

And most enterprises don't really need the performance they think they do.......and if they DO need performance, they can afford to throw hardware at it. Outside of those rare instances, having a consistent development language makes it easier to use your devs across all projects instead of having a specialized group just for the performance needs.

When people around me are all stressing because of deadlines, I just remind them that unless they are in a couple of key industries (i.e. writing embedded systems for medical devices), no one is going to die if they are a couple of days late with a project.....work to meet the deadlines, but don't stress over them; it's only money.

Re:Because it was written in Seastar or C++

[SQLGuru]

I started college in 1990 and the college I went to (Louisiana Tech University) was teaching C in all of their beginning CS classes [I already had BASIC and Pascal under my belt by this point, so it was just another language for me, but some people struggled].

Re:Because it was written in Seastar or C++

[Anonymous Coward]

I would say that 95% of all people I know in person, who learned C first and not: Assembler, Pascal, SmallTalk, Lisp are extremely bad on advanced language concepts like functional or oo programming.

And of course by this logic, it's bad to learn English when you really want to learn English. Wow. Man, the lengths people will go to justify their 'religion.'

Most of them shifted to scripting and operating servers and don't "code". A minority is doing embedded programming in C++ which mainly looks like C.

The idea that learning C first has any advantage is completely bollocks, a /. myth.

I started with C in 1987 ... on Sun Solaris (after 6 years Assembler, Pascal and BASIC) ... 1989 I switched to C++. I never looked back.

Yeah, people who live in a fantasy world never look back.

Only masochists would look back at C of that period.

ANSI C is much better ... but still: when I see a self proclaimed C genius with 30 years experience program Java or C++ ... shudder.

And a nice bit of Ageist Bigotry to boot. Nice. It fits the profile perfectly though.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

You're focusing on the wrong part. There's a difference between learning to write code in a language and learning to program with the language.

Learning C and all its quirks can be incredibly helpful in understanding other languages like C++ and Java. Simply learning "use printf for output" isn't any more useful than "cout" or any other print variant. Learning about the i/o channels and how they can be manipulated is.

Someone that has only ever known OO concepts by particularly named C functions will continue to do that nonsense in every other language... That's 'coding in a language'. While if they have learned how and why those things work, they can adapt that knowledge easily to other languages.

It's much easier to start from C and move to other languages than it is to start with Java and move to C.

Re:Because it was written in Seastar or C++

[Xyrus]

...C isn't a bad language to do *anything* in. It's just a language that requires you to be competent, or better, and to address it through the lens of that competence in order to get enough out of it to make the result and the effort expended worth the candle.

This statement says nothing. You can replace C with anything. Programmer competency far outweighs language choice, and a competent programmer will choose the appropriate tools to get the job done well.

C's key inherent characteristics are portability,

Hardly. Yeah, hypothetically if you stick 100% to ANSI standards then the code should hypothetically be portable, but pretty much every C/C++ code I've ever worked with/built/etc. is not 100% ANSI compliant. Macros galore permeate cross-platform C/C++ code. It is an exceptionally rare occurrence when I can take a pure C code written on Linux, bring it over to Windows, and compile and run it successfully without modifications. Meanwhile, I can take a python script I wrote on OS X and run it on Windows, Linux, etc. without issue.

There's a big difference between something that can be MADE portable and something that IS portable.

leanness and close-to-the-metal speed.

Good qualities to be sure. But most applications don't require "close to the metal" speeds for anything but key components. Use the appropriate tools for the job. Yes, hypothetically you can write entire web applications in C/C++, but it certainly isn't the smartest way to go about it.

It doesn't hold your hand.

No language "holds your hand". Some languages attempt to reduce some common types of programming errors (built-in garbage collection, exceptions, etc.). But no language is going to make an incompetent programmer competent. You can just as easily shoot yourself in the foot with Python or Java, but in some cases it might be a little harder to pull the trigger.

It's a language for experienced, skilled programmers when we're talking about creating actual products that are expected to perform in the wild.

Just because you CAN do something doesn't mean it's practical. If I'm staffing up a major web development effort, I'm not going to hire someone who claims they're going to do the whole thing in C. Similarly, if I need to develop a fluid dynamic model to run on super computers I'm not going to hire someone who says they're going to do it all in Python.

Re:Because it was written in Seastar or C++

[DuckDodgers]

OOP is intuitive at the micro-level. I have an animal class, and mammal extends animal, and dog extends mammal, very simple and straightforward.

But OOP code in a complex project is, in my experience, always a nightmare to understand. I want my animal reference to a dog object to move. I look in dog and I see that it uses legged-animal-move, which might be from a trait or mixin (Scala or Ruby) or another parent class through multiple inheritance (C++) and it turns out that legged-animal-move needs a reference to the current position of the animal so I need to go back to dog and back up the inheritance chain to animal and grab the position reference, and it turns out the dog is on grass. Now I have to apply the visitor pattern on the grass object visited by the legged-animal-move mover class. As part of that visitor pattern function on grass, I need a reference to any other animals that might be in the same spot to detect collision. So I go up the grass class hierarchy to its great grandparent class generic-position and retrieve its instance list of animals at that position.... and before you know it, to figure out if the dog can move two steps forward I have sixteen files open in my IDE and the debugger is running and I'm looking at things like AbstractSingletonProxyFactoryBeanFactoryManager wondering what I did to piss off god.

To me, the real value of functional programming is that the data you want to understand and the code that's currently manipulating that data is right in front of you. My function takes as an input an attribute map (or associative array, or dict) named 'animal' with things like type->dog name->fido position_x->22, etc... and a second input map with a direction and a distance and as a third input a list of maps in sorted order by position_x. I get the position_x of the first input, use the second input to figure out the path of desired travel, and then use a binary search on the third input to find all possible collisions. There might be a few helper functions involved, but it all takes place right in front of me. One file.

Re:Because it was written in Seastar or C++

[DuckDodgers]

You're assuming that code spends most of its time computing. It spends an awful lot of time on I/O, and Python is every bit as fast at doing nothing as C is while either language waits for a file copy or data on a socket or the next user keystroke.

I wouldn't write Call of Duty 9 or video editing software or Bitcoin mining software in Python. But a blog? Software to tag mp3s? A media server? They're fine for slow languages. We developers spend a lot of time arguing about speed, but often we're working on projects where the differences are irrelevant.

Re:Because it was written in Seastar or C++

[Dutch Gun]

Reflection and automatic memory management have almost no runtime cost. In fact, C++ pretty much offers both.

In both C# and Java, using reflection is extremely expensive. And C++ most certainly does not have reflection (or "introspection"). Reflection is the ability to query an unknown class, interface, or method at runtime for it's structure and data elements. This requires language-standardized runtime metadata that can be queried and inspected. C++ has no such metadata built-in, and as such, no reflection.

And comparing C#/Java vs C++ automatic memory management schemes are pretty much apples vs oranges (garbage collection vs smart pointers/RAII).

Re:Because it was written in Seastar or C++

[T.E.D.]

The idea that learning C first has any advantage is completely bollocks, a /. myth.

Its even crappy for "knowing why your code is slow". One important thing for optimizers is knowing the scope of the data the program is working with. Pointers destroy scoping, and it is next to impossible to do anything in C without using pointers. You can't even pass data out of routine's parameter without them.

It also encourages microoptimizations that vary between superfluous and actively harmful. My personal favorite is the "register" keyword, which is merrily ignored by every compiler I know of. It's not a human's job to know where variables go, and at the language source level you have no way of knowing the best way to allocate registers. Then there's the "for" loop, which is basically a "while" loop with extra syntactic sugar, and can't be optimized nearly as well as just about any other language's "for" construct because the loop control variable is actually mutable from within the loop (which could be dang near any line of code in the program, thanks to the magic of C pointers).

Even worse, people who learn this language first have a nasty tendency to overuse pointers and do pointless microoptimizations in other languages once they move on.

Re:Because it was written in Seastar or C++

[T.E.D.]

It's just a language that requires you to be competent, or better, and to address it through ...

I have some Assembler programmers from 1975 on the phone here who'd like to speak to you. They say they want their language superiority argument back.

Re:Because it was written in Seastar or C++

[F.Ultra]

C does not have platform specific pieces either. There are of course shared libraries (what you call frameworks) that might be platform specific but that has nothing to do with the language just like you can do with for example com.sun.jna.win32 in Java.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

Sorry that you're so bad at C.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

That's kind of silly, I wrote a pretty nice OO Sudoku solver. The base class simply has methods form creating and solving a Sudoku. then I created sub-classes: Binary Sudoku https://xkcd.com/74/, classic Sudoku (which scaled from 2 on up, normally we play a 3, ie. 9x9), and X Sudoku which is just like classic, but adds that the diagonals are also to be considered a set.

This made the sub-classes largely 10 lines to define, if you don't count documentation strings. At no single time did I need more than one class, but being able to switch quickly between them sure was nice.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

fyngyrz didn't say it wasn't an issue, fyngyrz said it's not nearly the issue it used to be, and it isn't. While your points about worrying about virtual machine size, it's still a lot less big of a deal than in the 16 bit days and we had to make hard choices about memory models.

Re:Because it was written in Seastar or C++

[NostalgiaForInfinity]

Really, are you such a beginner in C++ that you feel the need to state that C++ doesn't have garbage collection and reflection standardized? Are you such a beginner to feel the need to point out that using reflection is expensive? What I said was that "C++ pretty much offers both". That is, garbage collection and reflection are available if C++ programmers want them, as a combination of built-in facilities, template metaprogramming, and some simple conventions or tools. That allows us to estimate the overhead for offering these features in C++, and there is basically none. The runtime cost of offering reflection is no higher than offering RTTI, and the runtime cost of offering full garbage collection is no more than that of smart pointers. Both reflection and garbage collection are likely going to be standardized in upcoming C++ releases

So, contrary to what you said, the fact that Java "has a bunch of neat features" does not "inherently come at the cost of runtime efficiency". The reasons Java programs tend to be slow are different.

Re:Because it was written in Seastar or C++

[TsuruchiBrian]

Humans + compilers will make more efficient code than just compilers. I am comparing humans and compilers. There are areas where humans can write better ASM code than modern compilers but the vast majority is written better by compilers.

Re:Because it was written in Seastar or C++

[angel'o'sphere]

My personal favorite is the "register" keyword, which is merrily ignored by every compiler I know of.
I once tried "register" on two parameters to a function on an Mac with 68k processor.
The resulting machine code put the parameters in registers first, pulled them out again, then did what the code should do, and then put them back into the registers.

So, something that was manipulating two double words on the stack using two adress registers, just kept doing that, and bufferd the before and after values in addition in two data registers.

The code with the register keywords was roughly 1/4 as fast as the "normal" code.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

> They even conflate the generic notion of an object--an object isn't always something that has methods.

Huh? An object is an instance of a class, and all class behavior is defined by methods... unless I missed a day in college?

Re:Because it was written in Seastar or C++

[Anonymous Coward]

It's bad in the sense that it defies a lot of automation and tooling practices. Most of my github repo is C code, and I love it for small programs. But being realistic, it's decades behind what the Rust compiler can do in terms of automating correctness checks and specifying in a machine checkable way what you want to happen under maintenance later on. C is far behind everything (Go, Java, Python) in terms of productivity, even given good C programmers doing the work. Code gets produced within budgets, and everybody is competing for the small number of super-programmers.

Somebody told me that Python programmers actually make the most money. My friends were boggling about that assertion. It's because people get paid to get stuff done; not to be an office magician that can do amazing things with primitive tools.

Re:Because it was written in Seastar or C++

[phantomfive]

Eh, that just means you haven't written much assembly, and haven't looked at much output from compilers. Again:

The average programmer can't do better than a compiler, but
with a little practice, a good programmer can easily do better than a compiler. Compilers aren't magical.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

> C is not portable, it's tied to the architectures/OSs/APIs the programmer chose to target at write time.

Then you're doing it wrong.

Re:Because it was written in Seastar or C++

[TsuruchiBrian]

No it means I have seen the assembly that humans have written. Keeping in mind that code doesn't count as "efficient" if it's wrong.

Re:Because it was written in Seastar or C++

[phantomfive]

I'll give you a simple example. Consider this code:

for(i=0; i<strlen(s);i++) {
s[i] = tolower[i];
}

In this example, the strlen() can be hoisted out of the loop, only called once. This is a simple improvement. And yet even with full optimization turned on, LLVM doesn't hoist it.

If you can't write better assembly code than a typical compiler, you're not even trying.

Re:Because it was written in Seastar or C++

[TsuruchiBrian]

That's not a problem with the compiler. That source code, as written, is supposed to check the length of s before each loop iteration. If you want the length of s to be checked only once, then you need to change the C code.

Imagine replacing strlen() with foo(). You don't even know if foo is deterministic or not. It might return a different output for the same input each time it is called.

Re:Because it was written in Seastar or C++

[phantomfive]

OK, so now even you are listing reasons compilers are inefficient. Good job, soon you'll wake up and realize you agree with me.

Re:Because it was written in Seastar or C++

[TsuruchiBrian]

No I am listing a reason why if the compiler did what you say it should do, it would result in different behavior than what the source code indicates.

Re:Because it was written in Seastar or C++

[phantomfive]

Your main problem is you've never really looked at compiler output, and you've never really tried to do better than a compiler. If you did, you would change your mind and have no trouble beating the compiler.

Re:Because it was written in Seastar or C++

[TsuruchiBrian]

I have not only looked at compiler output, but actually write assembly for things like atomic reference counting.

I value correctness more than speed. I know can probably beat the compiler at *some* tasks. I'm saying that on average the compiler generates way better assembly. It's usually faster, and it's almost without exception more likely to be correct.

There are indeed lots of areas where compiler optimization can be improved, but the single example you gave isn't one of them. That's just an example of a programming error.

Re:Because it was written in Seastar or C++

[phantomfive]

I have not only looked at compiler output, but actually write assembly for things like atomic reference counting.

OK, what do you want me to say? That you suck? I'm sorry you're such a lousy programmer that you can't go faster than a compiler?

There are indeed lots of areas where compiler optimization can be improved, but the single example you gave isn't one of them.

Your knowledge of compiler design is bad too lol. The compiler can often check to see if the function is pure or not, and it certainly can be given the correct information for built-in functions.

Re:Because it was written in Seastar or C++

[TsuruchiBrian]

I can see you're getting all defensive, and are not really interested in doing anything but desperately trying to save face. Good luck with that.

Re:Because it was written in Seastar or C++

[phantomfive]

I've given you examples, which you [fail to] try to explain away.
I've given you techniques you can use to improve yourself, but you don't want them.

Read a book or something, what else can I do to help you?

Re:Because it was written in Seastar or C++

[TsuruchiBrian]

Here's what you've given me:

1. One terrible example.

2. Evidence that you have a reading comprehension deficit or some kind of inferiority complex or both.

Re:Because it was written in Seastar or C++

[UnknownSoldier]

OT, but thanks for that discount code! $12 off the initial $25 is a nice deal !

Re:Because it was written in Seastar or C++

[Alomex]

total = 0; for (val in args): total += val; return total.

But this is only the case because imperative languages have refused to evolve with the times. There is nothing stopping you from adding a function called:

listify::(argument);

listify::'+'(argument);

Re:Because it was written in Seastar or C++

[narcc]

An object is only an instance of a class in some languages. Though it's not a terribly useful definition, even in those languages in which that statement is true. Depending on the language, you're either stating the obvious, or spouting nonsense.

Re:Because it was written in Seastar or C++

[dgatwood]

Inheritance for re-use is quite possibly the worst reason ever to use subclasses. Inheritance should be used when you need polymorphism and the two objects behave *alike* - AKA the Liskov Substitution Principle [stackoverflow.com]. (Public) Inheritance that violates some of the assumptions of the parent class is really painful.

By "behaves very differently", I don't mean that the interface is different; I mean that the way they support that interface is different for some important reason, and in a nontrivial way that makes it necessary to have a separate class. That's a subtle point that I probably could have explained better.

Consider two apps that control VPNs on iOS. One app controls both an IPsec VPN and a custom packet tunnel. A second app controls two IPsec tunnels, one of which uses IKEv1 authentication and the other of which uses IKEv2 authentication. A class to control any of those three will likely have roughly the same outward interface—start the VPN, stop the VPN, set the on-demand rules, etc.:

• In the first app, subclasses are appropriate. Although the interface that an IPsec VPN and a custom packet tunnel must present to the app is likely to be almost the same, if not identical, the actual code that those two classes use to set up the VPN tunnel are completely different. It makes sense to make them both be subclasses of some common root class, both to allow them to share code and to make it harder for their outward interfaces to diverge unintentionally in ways that would violate the abstraction.
• By contrast, in the second case, subclasses would be serious overkill. The differences between IKEv1 and IKEv2 can be encapsulated in a small "if" statement in maybe two places in your code. So a simple property is a better choice (IMO).

Alternatively, subclassing makes sense if you need two classes that share some common functionality, but provide other functionality that is different. In this case, however, callers that care about that added functionality must know which kind of class they're dealing with. This doesn't violate Liskov because they still support the functionality of the superclass without changing the behavior of the superclass's methods. With that said, if it is possible to comfortably combine those classes into a single class that does what both classes do, then the class abstraction will be more of hindrance than a help. It is important to recognize such anti-patterns when you see them.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

Dude it's just a language - a goddamn tool. Get over yourself and your my language is better than your language bollox.

I program in C and Java mostly but I'll use whatever language is best.

Re:Because it was written in Seastar or C++

[dgatwood]

You could have done a lot of that by adding size properties to the superclass. What made the use of subclasses important is the additional checking behavior needed for treating diagonals as a set, which requires significantly different behavior in your checking code, which is probably called from multiple places in the class implementation. So ignoring the length issue, that pretty much qualifies as a very minimal example of the principles I'm advocating.

Pedantically, what you did probably violates Liskov, at least in principle, because the actual behavior is different even from the perspective of the interface, but in practice, what you have are a couple of tightly coupled classes, one of which is a solver, the other of which is the UI for the solver, and the solver isn't intended to be used broadly outside that context. So the violation of consistent interface behavior from one subclass to the next isn't necessarily a problem, at least in practice.

Alternatively, the solver could be part of the UI class, and then there would be no violation at all, because you'd load different UI subclasses that have different numbers of rows and columns, and that treat diagonals differently, and they would all have the same programmatic interface, because view is a view is a view.

Re:Because it was written in Seastar or C++

[phantomfive]

Here you go man, this guy says it much better than I do.

Re:Because it was written in Seastar or C++

[ZeroConcept]

My kitchen sink can also be ported to another house, it has no house-specific bits.

Think.

Re:Because it was written in Seastar or C++

[F.Ultra]

What should I think about? C does not have any platform specific parts as part of the spec just like Java. C can use platform specific parts, which is also true about Java. Regarding your sink you wrote yourself that it has no house-specific parts so what is your point with that example? Do you somehow believe that your sink needs porting?

Re:Because it was written in Seastar or C++

[ZeroConcept]

Porting C code is like moving a kitchen sink from a house to another.
Java portability is like plugging a laptop into another house.

Why (to name a few)?
- Fixed size of primitive types
- Big-endian/Little-endian,
- String encoding.
- Text encoding.
- Compiled code portability.

C is a wrapper for ASM with a promise for portability
Java is a VM platform designed for portability, actually working after compile time.

You are new, its ok.

Re:Because it was written in Seastar or C++

[F.Ultra]

How is not the primitive types in Java fixed? To me as a C coder writing portable code it's actually a good thing that uint64_t is an unsigned 64 bit integer regardless of platform, how in the world can that be seen as a portability problem?

- I grant you that big- and little-endian is a problem for code that moves data between systems, but that is why there is the ntohl() and htonl() functions and why you always define what endian the communications protocol has (if you move binary data)
- String and Text encoding is similar to how it works in Java, if you have to read an external file in Java you have to convert it to the internal unicode format. Having worked with both languages in this respect I cannot see any difference to be honest
- Compiled binary is of course a given, I thought that we talked about code and not binaries.

Of couse I'm new, I have only been coding for 33 years now ;) Don't confuse me with someone who hates Java, I wrote the first JVM for the Amiga in 680x0 assembler back when SUN first presented the language.

Re:Because it was written in Seastar or C++

[ZeroConcept]

The issue is that you can't see the artificial complexity of C.

The number of types in C is crazy:
http://www.nongnu.org/avr-libc...

How many types of strings can I have in C? How many types of integers? Fractionals? Booleans?
Signed, unsigned? Why?

Compare with:
https://docs.oracle.com/javase...

For neophyte programmers, writing portable code in C is not feasible.

At this point, you are too far invested with what you do to try a different way.

The kitchen sink is portable, by the way, you need a plumber each time you move it, and a mason, and a wood cutter, and a contractor to manage it.

But it's portable.

Re:Because it was written in Seastar or C++

[F.Ultra]

It's ok for you no like C the language but nothing that you brought up has anything to do with portability. All those integer types and all those string types can be used on all platforms. Where you see complexity I see freedom and where you see simplicity I see constraints, but that is just subjective opinions which we are both entitled to have without the other being either right or wrong. What matters is that it has nothing to do with portability what so ever.

Re:Because it was written in Seastar or C++

[Anonymous Coward]

C doesn't really have that many types, they're mostly variants of ints and floats, and pointers to same.

char is really an int.
ints vary in size and sign.
floats vary in size.
structs are just combinations of primitives.

The "complexity" here is really part of every language, it's just that some languages paper over the minutiae with abstractions.

Re:Because it was written in Seastar or C++

[Xest]

"Simply learning C or C++ won't point out exactly why those languages are so much faster than managed languages. You can write nearly the same code in C++, Java, and C#, and you'll see C++ win performance benchmarks - at least in all but the most contrived examples."

And that's really part of the problem. Too many people who vehemently defend C/C++ against managed language performance are doing so having just written or run a brief managed language application and said "See!".

But it's not a fair comparison, talented C++ developers can write good, performant C++ applications because they understand the language, they understand the compiler, and they understand how it all interact so that they can write that performant code in the first place.

Managed languages aren't magic, if you want an optimised application you still have to understand the platform - in something like .NET that means understanding GC generations, the impact they have, what should reach gen 2, what shouldn't pass gen 0, and how to make sure it doesn't pass gen 0. Unless you understand your runtime, be it the CLR, or the JVM as well as you understand your C++ compiler, you can't rationally compare the two and claim one is better than the other.

That's where you're going wrong - you're suggesting that code written to be optimal in C++ should be inherently optimal in Java, or C#, and that's a completely false assumption. It's also why you're right about something - that the GP is completely wrong. Learning C wont make anyone a better programmer in a managed (or even interpreted language), it's a different platform, and the rules are different. Probably what someone means when they say they should learn C first is actually that people should understand their platform first - they should understand the intricacies of the JVM, or the CLR, or their C++ compiler, or even the underlying OS and hardware. I disagree though, I think you learn those things best through programming, though some people certainly never really learn them, and that's a problem.

"Among the more significant differences are that C++ compilers are extremely good at optimizing, and C++ code generally compiles down to better cache-coherent structures than other languages. The difference is in the language itself, which adheres to a zero-cost principle, in that you don't pay for features you don't use. A lot of C++ abstractions are eliminated *entirely* at runtime, and are only used to protect the code's integrity during the compilation phase."

But even then they're not as good at optimising as JIT compilers, simply because additional compile time information always inherently means better optimisations can be performed - this is an inescapable fact, the more information a compiler has, the better it can optimise, and a JIT compiler on the specific execution machine will always have more information than a C++ compiler compiling for a target architecture (rather than a specific machine) - the JIT compiler has full hardware and OS information (and not merely rough architectural information - something pretty broad like x86, or x64), and it can also gather runtime information to optimise around runtime patterns. Yes, C++ compilers have gotten very good over the years, but unfortunately it's an inescapable fact that JIT compilers will always inherently be able to do better - it's just the nature of the beast, and there's no getting away from that bar C++ applications being able to self-optimise at installation or runtime.

"We were told for years that native-equivalent performance was just around the corner or even already here, and it just never really happened outside of small, contrived benchmarks."

It's been here for quite some time, but if developers don't know how to achieve it then it might as well not be. Great developers are doing great things in managed languages - many of the big boys have those staff on board, companies like eBay, Amazon, Google, and just about all the banks et. al. but similarly they also have great

1/10 time to write it?

[Anonymous Coward]

Or is this another shitty Slashdot headline?

LMDB

[lkcl]

yaaaa... but are they using Lightning Memory Database (LMDB) as the back-end? http://developers.slashdot.org... https://en.wikipedia.org/wiki/...

Yes, but is it web scale?

[bad_fx]

Sure, but is it Web scale?

Re:Yes, but is it web scale?

[CastrTroy]

Reference for the unfamiliar.

Out of points or would mod up

[Wrexs0ul]

Sans sarcasm I would've also accepted: "duh"

Re:10x faster only? I did better w/ online speed

[Anonymous Coward]

I miss the Golden Girls cosmonaut troll personally. And that one guy who went on about host files.

We need a new merged copypasta supertroll. Can somebody get on that?

Now returns null pointers in half the time!

[jlowery]

They also boosted performance by never freeing memory, too!

Re:Now returns null pointers in half the time!

[The Evil Atheist]

The 90s called. They want their joke back.

Re:Now returns null pointers in half the time!

[Anonymous Coward]

Beeeeeeee Booooooo Beeeeeeeeeeeeeeeee Beeee Beeee Booooooooooooooooooooooooooooooooooo

The 90 is still trying to call.

Modern hardware

[sanf780]

I suppose that modern hardware means a desktop, workstation or computational server CPU, aka x86_64 based. I wonder if modern hardware also includes low power or portable CPUs, aka ARM ones. It looks like portability has given way to almost to the metal optimization.

Re:Modern hardware

[tepples]

What optimizations are valid on AMD/Intel x86-64 but not on ARM AArch64?

Re:Modern hardware

[Anonymous Coward]

When it comes to concurrency, a lot actually. They use different memory models: x86_64 has stronger memory ordering, which if exploited runs incorrectly on arm, or dirt slow with atomic everywhere. That said, modern C++ compilers suck as exploiting that particular thing, so I expect the optimizations are mostly portable. A factor of 10 can easily be hidden off in the memory fences somewhere though... optimization is hard.

Re:Modern hardware

[Anonymous Coward]

Strong memory ordering _hinders_ optimization. It doesn't help it because it's always there in the 99% of cases you don't want it there.

The fact that Intel chips scale as well as they do is a testament to their engineers, not the x86 architecture.

Some ARM chips have a pretty strong LL/SC primitive, which is the holy grail of primitives for implementing lockless algorithms. Alas, high-end ARM chips don't have this. The specification allows vendors to limit the size and number of LL/SC blocks to such small numbers that it becomes effectively useless.

If the x86 had an LL/SC primitive which supported outstanding locks over a substantial portion of the address space (that is, enough addresses that it could be used to implement a completely lockless hash table or tree with an arbitrary number of elements, limited only by available memory, as shown by Hoare), _and_ Intel engineers spent their considerable intellectual capital optimizing the silicon like way they currently do for multiprocessor cache coherency, the sky would be the limit in terms of multiprocessor scalability. In that world strong memory ordering is a huge liability.

Instead, Intel has double-downed on their current strategy. Their "transactional memory" extensions are just the same old, boring CAS hacks, but implemented in the firmware. They don't substantially improve scalability, but do save some cycles compared to compilers emitting code to implement the same algorithm. Real hardware transactional algorithms are both lock-free and wait-free; they don't need to resort to retry loops or mutexes in the contending case

In other News

[s.petry]

Oracle has just launched a new series of patent infringement lawsuits. Oracle allegations include reverse engineering Java to improve the speed of applications like Cassandra, benchmarking Java without permission. They are seeking an immediate cease and desist order, in addition to immediate financial relief for sustaining PPS (More commonly known as Poopy Pants Syndrome.).

Re:10x faster only? I did better w/ online speed

[s.petry]

Merged with Goatse links! The trifecta!

It's a miracle! C++ makes disks spin 10x faster!

[iamacat]

Databases are usually I/O bound and improvement of storage structure/network protocol is more important than spot optimization of code. A more likely statement is that scylladb performed ten times faster than Cassandra in one particular benchmark for which Cassandra has not been specifically optimized for yet and is ten percent faster in an average case.

In either case, good luck maintaining speed and stability after 5 releases when you implement every corner case of every feature and have to deal with legacy support.

I find it depressing...

[Anonymous Coward]

I find it depressing that so little attention is paid to efficient computing. People now just throw memory and cycles at problems because they can with passable results. But I wonder how much more we could get out of our machines if software was carefully crafted from bottom to top.

Re:I find it depressing...

[Anonymous Coward]

Lots more. We'd also still be running simplistic text-based applications on monochrome 80x25 green screens if we took the time to "carefully craft from bottom to top."

Re:I find it depressing...

[Anonymous Coward]

No you wouldn't. You'd have a small handful of well written libraries that performed these types of tasks for you instead of the thousands and thousands of shitty, poorly written ones that are bloated and filled with bugs and security holes.

Re:I find it depressing...

[serviscope_minor]

You're looking in the wrong place. Try prying open your smoke alarm or CO detector. It's probably got a PIC12F or 10F, or an ATTiny or something. Those things have 1k words of program memory and a few tens of bytes of ram (typically). People pay a lot of attention to efficient computing. Too big a program means the model up, or an extra 5c per unit which clobbers profit margin. Too inefficient and the non replacable battery lasts 3 years not 5.

Or look at the compute bound stuff. FFMPeg gets faster year on year on the same hardware. I remember in the early 2000s it went from being able to fairly reliably decode MPEG2 in real time on a CPU to being able to do faster than real-time encoding on the same CPU. Compute bound stuff like FFMPEG, LAPACK, FFTW, and so on that form the guts of other things do get better, not worse.

Re:I find it depressing...

[Anonymous Coward]

No you wouldn't. You'd have a small handful of well written libraries that performed these types of tasks for you instead of the thousands and thousands of shitty, poorly written ones that are bloated and filled with bugs and security holes.

QFT. The 'new age' script-kiddie's motto: "Any unknown 17 year-old with a github account can write better code than me! Grab that lib and go baby! What is another lib when we already have 40 we are 'using.' Also never admit we have absolutely no understanding or idea how they work. We just need moar!"

Re:It's a miracle! C++ makes disks spin 10x faster

[lambsonic]

Read a summary of how Cassandra works, and you will see why it can be so much faster, given what you already know (that thing about databases usually having an I/O problem).

Re:It's a miracle! C++ makes disks spin 10x faster

[garethjrowlands]

Databases used to be disk bound, sure. But these days we have huge RAM caches and SSDs - no spinning disks. It's very common for the vast majority of requests to be served entirely from cache. Read the guys' site - it looks like they know what they're doing.

Imagine if Redis was ten times slower or ten times faster. It would matter.

assembly?

[Anonymous Coward]

i was like seastore star whats it, had to read the post ic spanNpluss+, thought it was timmy

Re:10x faster only? I did better w/ online speed

[GigaplexNZ]

I still don't see why some sort of filter hasn't been implemented. These troll posts are usually just direct copy/pastes, which would be really easy to filter once identified.

Re:It's a miracle! C++ makes disks spin 10x faster

[Anonymous Coward]

herpa derp, IT drone doesn't know how Cassandra works.

Rewrites are easier than the first strike

[angel'o'sphere]

Wow, two years ago everyone here told us that NoSQL is evil and tried to convince us that we should stick to MySQL.

Now everyone tells us Java is evil, because a rewrite in C++ is faster.

What a surprise.

If I would rewrite Cassandra from scratch, in Java, it also would be faster than the actual code.

Why? Because all the learning the original team did over a course of a decade I can reuse and improve on.

Keep in mind, the rewrite uses a new framework and new concepts for concurrency. Concurrency is one of the core areas where computing in future will certainly make lots of progress.

I for my part I'm waiting for a Lucene rewrite, regardless in what language. Probably the worst OSS code I have ever see ... actually the worst code regardless of OSS or closed source.

Re:Rewrites are easier than the first strike

[Zero__Kelvin]

"If I would rewrite Cassandra from scratch, in Java, it also would be faster than the actual code."

Great (In the unlikely event you could actually single-handedly rewrite it at all.) Now make it 10 times faster. Nice Red Herring post though!

Re:Rewrites are easier than the first strike

[KermodeBear]

Wow, two years ago everyone here told us that NoSQL is evil and tried to convince us that we should stick to MySQL.

I will admit that I don't quite understand the fuss about "NoSQL".

It's just a two column table with a primary key and a data blob. Congratulations, I guess. Yes, a specialized piece of software for this might be fast, but it's not anything new or innovative. It's just a two column table with a bow on top.

Re:Rewrites are easier than the first strike

[Anonymous Coward]

Mod parent up

Re:Rewrites are easier than the first strike

[Anonymous Coward]

Sounds like bdb, ndbm, gdbm --- all of which have been around at least 25 - perhaps 35-45 yrs.

Nothing against nosql, but people have been using key/value DBs for many decades.

As to Java, I recall a group from Sun coming to our Government lab around 1995 showing this new compile-once, run anywhere language. We were writing cross-platform C++ with GUIs for 12 different platforms, so we paid close attention. They promised that Java would be faster and use less RAM in a few years.

I'm still waiting for that. Glad I didn't hold my breath while waiting. The only things that seem to have made Java faster was the availability of more RAM and faster CPUs. That has worked for perl, C/C++ and every other language too - even Ruby.

Re:Rewrites are easier than the first strike

[Anonymous Coward]

Forget your aspergers meds? His main point was that every project that's been around for a decent amount of time can benefit (often dramatically) from a serious rewrite.

Also, your post was much more of a red herring. So 100% fail, there.

Re:Rewrites are easier than the first strike

[pestilence669]

I do agree that a language-to-language rewrite would yield impressive gains... but that's not the whole of it. Cassandra is an edge case ... and yes, the Lucene code could use some love (contribute some patches??)

C++ isn't necessarily the best choice for everything, just like a Mclaren F1 isn't the optimum choice to pick up groceries. But if your requirements dictate that performance is a chief priority, it most certainly is.

I've written many Java and C++ systems at scale. Java simply does not excel at maximizing the use of system resources, predictable real-time performance nor high uptime. Stomp your feet all you want and pretend it's not true if you like. Java trades off performance to provide features to developers that they cannot override. Fact.

Java is fine for 99% of most everything ever written. Honest. Cookbook blog: great! That 1% though where every bit matters, that's when you take off the training wheels and code as low as you can tolerate or afford.

What Java zealots in the Cassandra and Hadoop communities kept boasting was the idea that vertical performance doesn't matter anymore. Solve all of the problems with JVM unreliability and poor performance under the umbrella of big data and more hardware. This makes sense at a few dozen servers. It's insane when you start considering scale at 100s or 1000s.

I hope DataStax considers making Cassandra more cost effective. The simplest way is to get rid of the JVM and give me a machine code binary. I'd really like to throw 128GB of RAM to my nodes, but Java won't let me.

Re:Rewrites are easier than the first strike

[Anonymous Coward]

I suspect the speed up is mostly due to the Seastar framework rather than the C++ language itself. Seastar uses "kernel bypass" for network i/o, polling, "share nothing" between cores which is great for scalability and NUMA, etc. Does the original Java code use such concepts?
 

Re:Rewrites are easier than the first strike

[Anonymous Coward]

and HIS point was put your money where your mouth his. ScyllaDB proved c++ IS faster than Java, if you want to prove otherwise YOU must PROVE that.

Re:Rewrites are easier than the first strike

[Anonymous Coward]

No, angel's post is correct. Despite the summary, ScyllaDB is not a rewrite of Cassandra. It's a new DB that has an interface compatible with Cassandra. Those are two completely different things.

Now to get petty, Cassandra runs on more platforms than ScyllaDB. The Cassandra website works without Javascript, its website uses technical terms to describe itself and what it does, and has a lot of info. The ScyllaDB site needs Javascript, is designed for mobile yet has inconsistent section heights, uses a fucking auto-scrolling carousel, has some buzz words and a lot of useless marketing speech, and makes fun of another project. Going with first impressions, ScyllaDB is an immature startup that's trying to scam me and will be gone in a couple years while Cassandra is something I can trust, know will be around, and provides better resources for me to learn how to use it. They care about their product, not about how to shove it down my throat. Maybe the ScyllaDB devs can make great databases, but they suck at quality websites.

Re:Rewrites are easier than the first strike

[Ace17]

The sole action of rewriting a piece of code doesn't magically make it faster. Nor does it make cleaner, or more stable. You have to put something more into the equation. Like a new programming language, or a new team. You might want to have a look at Joel Spolsky's post named "Things You Should Never Do", explaining why a big rewrite is almost always a bad idea.

Re:Rewrites are easier than the first strike

[Anonymous Coward]

In this case, the language for sure was not the reason for 10x performance increase (if the increase is really true and not just a result of incorrect benchmarking), because Cassandra is I/O bound, even on SSDs. Also, the main rule of benchmarking says: never trust a benchmark done by the author of the product. Benchmarks must be performed by independent third-parties.

Re:Rewrites are easier than the first strike

[narcc]

Fads are fads. Today's 'best practices' are tomorrow's 'horrible mistakes'.

You're right that rewrites often result in a significantly better product. I suspect that, in addition to your reason, the two are correlated.

Re:Rewrites are easier than the first strike

[Anonymous Coward]

The fastest trading platform ever was written in Java. See LMAX.

All depends on how you code and the language matters much less.
There are really very few things that you can do in C++ that you can't in Java. Things that average Java devs incorrectly think can't be done in Java:
- manual memory management with no GC cost
- cache friendly object layout
- compile time metaprogramming
- low-level native operating system API access
- sub-millisecond latency asynchronous message passing

Some of these things may be harder to do in Java than in C++, but on the other hand plenty of things are harder to do in C++ than in Java and C++ tooling is just horrible. And 90% of time is spent in 10% of code, so there is no point in wasting programmers time on writing everything in C++.

Re:Rewrites are easier than the first strike

[Anonymous Coward]

> Wow, two years ago everyone here told us that NoSQL is evil and tried to convince us that we should stick to MySQL.

If MySQL is the only SQL you know, you're in desperate need of NoSQL.

Re:Rewrites are easier than the first strike

[angel'o'sphere]

There are plenty of different variations of NoSQL Databases. Column Stores like Cassandra (with unlimited ampoounts of columns, *cough* *cough* how useful would a storage with only two columns be?), document based like Mongo DB, XML based or simply graph based ones (e.g. OrientDB and Neo4J).

Re:Rewrites are easier than the first strike

[angel'o'sphere]

I did not say I make it 10 times faster, I said: I make it faster.

It is a no brainer that the speed increase has nothing to do with the language used but with better architecture and better approaches. That can be easy repeated with a Java rewrite.

Why should it not be possible to single handed rewrite it in a reaonable time?

Re:Rewrites are easier than the first strike

[robi5]

> Wow, two years ago everyone here told us that NoSQL is evil and tried to convince us that we should stick to MySQL.

The proper alternative to NoSQL would be an SQL database, rather than the misleadingly named MySQL database.

Re:Rewrites are easier than the first strike

[Anonymous Coward]

Spot on.

The performance increases are more likely due to be using better concurrency techniques (i.e. the ones that the functional programming languages have been encouraging for the last 30 years :-) than the move to C++.

Yes well optimized C++ is a bit quicker than Java (normally by a factor of about 2) (e.g. as per http://benchmarksgame.alioth.debian.org/u32q/which-programs-are-fastest.html).

Re:Rewrites are easier than the first strike

[Anonymous Coward]

On the one hand you're saying you never said 10 times, on the other hand you say all the speed is due to architecture improvements.
Which one is it?

Re:Rewrites are easier than the first strike

[Anonymous Coward]

Actually both points are just fine. This thread is titled "cassandra rewritten in c++, ten times faster". Now, sure, they picked some benchmark and claim everybody should run to their shiny because of this. It does not make this a universal thruth. It is perfectly fine to counter this by saying that it is very likely that the "c++" part of it is not responsible for most of the 10x faster part. Or that it is likely not overall that much better, or better at all if you consider broader viewpoints.

But of course, we can always also claim that those who argue different are just wanting to make sweet love to C++ in their moms basement at some ripe middle age. Not that different from bashing the folks who prefer Java etc for whatever reason. Personally I prefer Java etc over C++, but I am fine admitting that is a personal preference and there are plenty use cases where a different language/platform is a better choice. I wouldn't go with the Cassandra case just because of this post though..

Re:Rewrites are easier than the first strike

[Anonymous Coward]

Would it be sufficient to pick a badly coded C++ application and write a better implementation in Java? That way Java would shine like C++ does in this case.

On a related note, I remember some benchmarks showing that Java is around 2 times slower than C, while C++ is slightly slower than C. So it could be possible to make a Cassandra rewrite in Java that is 5 times faster than the current one.

Re:Rewrites are easier than the first strike

[Zero__Kelvin]

"It is a no brainer that the speed increase has nothing to do with the language used but with better architecture and better approaches. That can be easy repeated with a Java rewrite."

Perhaps that is the conclusion one reaches without a brain, but people with an actual brain and an understanding of the fundamental differences between C++ and Java know that is complete bullshit, and recognize you as the incompetent posturing for recognition with no ability to back your ignorant bullshit up with actual skills that you are.

Re:Rewrites are easier than the first strike

[Anonymous Coward]

ScyllaDB proved *this approach* using c++ IS faster than the current one using Java

I corrected that for you.

Re:Rewrites are easier than the first strike

[abies]

Would it be sufficient to pick a badly coded C++ application and write a better implementation in Java? That way Java would shine like C++ does in this case.

Did it in the past. 6 times faster to be exact and we are talking about java 1.3 back then, which barely got basic symantec(?) jit, no Hotspot yet.
I was trying to explain to my boss that original application was braindead and I just optimized the sqls they were using while rewriting the code but he touted 'that new java technology making everything 5-10 times faster' to client anyway...

Re:Rewrites are easier than the first strike

[angel'o'sphere]

Perhaps you shouzld read the plenty full of Posts here in this thread that explain why the new C++ rewrite is faster. Or simply go to the vendors web page. It is very well explained :D

You Sir, are just an ignorant idiot without a brain. Or you had grasped what I implied with my previous comment :D ... sorry to use your own wording on you, but it seemed fitting.

Re:Rewrites are easier than the first strike

[angel'o'sphere]

A SQL database is only an alternative to a NoSQL database if having chosen the later was an architecture mistake.

I never have seen usage of an NoSQL database where it made sense to switch to a relational one (SQL).

If you have examples, I guess many are eager to hear them.

Re:Rewrites are easier than the first strike

[Zero__Kelvin]

"Perhaps you shouzld read the plenty full of Posts here ..."

Know doubt your grasp of programming languages is similar to your grasp of the English language. Nobody is arguing that re-architecting isn't a major advantage. The point is that one cannot attribute the entire improvement to it, and claiming that you could use Java and acheive similar results represents your blatant blathering to the world that you lack an understanding of language architectures. Put Bjarne Stroustrup and James Gosling together in a room, and they would both tell you how clueless you are to even suggest it. Now off you go ...

Re:Rewrites are easier than the first strike

[robi5]

Are you saying that MySQL is neither SQL nor noSQL?

Re:Rewrites are easier than the first strike

[BobbyWang]

I for my part I'm waiting for a Lucene rewrite, regardless in what language.

Wait no longer. There is a rewrite in C++ called CLucene and another (not as mature) rewrite in pure C called Lucy.

Re:Rewrites are easier than the first strike

[Anonymous Coward]

You are arguing from your experience, but you are actually not using any facts either.

Does Cassandra use block I/O or stream I/O? Perhaps a simple switch with preallocated buffers is all that is needed. Perhaps a different method of server side socket handling is the reason for the speed improvement. Perhaps they didn't free anything in the C++ side, reusing all of their data structures. Whatever the reason the speedup occurred, that reason can be replicated in Java, and the performance benefits can be felt.

Don't forget that a highly used method in Java gets compiled into machine code and inlined into the rest of the program. That means that in both languages, you can get "as good as the machine can run" in terms of language. The performance battle is really going to become "what you ask the machine to do" and "how you ask the machine to do it".

With lots of older languages, how you ask the machine is tied to patterns that aren't as flexible, and therefore asking the machine to do something means you ask it in a way that comes with a lot of overhead. Java's been worked on for nearly two decades, with an eye to reducing that overhead. The "interpreted" byte code is practically a reduced instruction set assembly, so it had a better starting point than most other languages for such optimizations. With JIT it isn't even "interpreted" assembly, it's machine code.

Re:Rewrites are easier than the first strike

[angel'o'sphere]

I did not say "similar result". I said a rewrite wouldl also gain speed in Java. Learn to read and stop twisting other peoples words around.

Unfortunately you seem not to know who am I, but that is easy to google. So calling me clueless is not an insult to me, it only Shows how dumb you are.

Hint: if you 1:1 translate Java to C++ or C++ to Java, the speed of both programs are more or less the same. As both get compiled down to more or less the same assembly code. To improve one version over the other you have to do much more.

Re:Rewrites are easier than the first strike

[angel'o'sphere]

The correct wording is: MySQL is a rational database, using as DDL and DQL SQL. I don't know if MySQL supports NoSQL stuff :D

Why do you ask?

Re:Rewrites are easier than the first strike

[robi5]

In this case you may as well consider a proper SQL database instead of MySQL which was what I alluded to originally. I.e. unlike how you phrased it, I'd pick either SQL or NoSQL but I wouldn't pick MySQL by default.

Re:Rewrites are easier than the first strike

[Tack]

Speaking as someone who's deployed and manages among the largest Cassandra clusters in production (at least on #cassandra nobody had heard of a cluster larger than 1700 nodes), I feel at least partially qualified to say that anything that does away with GC is already a massive improvement in latency, consistency, and likely (as a result) even throughput.

I've lost count of the number of incident bridges caused by GC shitstorms, and the number of hours lost to GC tuning and other GC related insanity.

Forget userland TCP stacks and other cleverness. Give me Cassandra exactly as it today except without GC and I'll be one happy camper. I would gladly pay the cost of reference counting which at least can be predictably amortized over the application's life cycle. And the programmer burden of manually breaking reference cycles (should they exist at all) isn't much to ask for in exchange for predictable latency.

Re:Rewrites are easier than the first strike

[Zero__Kelvin]

"Unfortunately you seem not to know who am I, but that is easy to google. So calling me clueless is not an insult to me, it only Shows how dumb you are."

You could be Linus frigging Torvalds and I'd still call you a moron for making the ridiculous claim you made.

"Hint: if you 1:1 translate Java to C++ or C++ to Java, the speed of both programs are more or less the same. As both get compiled down to more or less the same assembly code. To improve one version over the other you have to do much more."

Holy shit. You are actually so incompetent that you think that is possible. That is frigging hilarious! Write us some Java code that writes a 0x55 to location 0xdeadbeef. Moron.

Re:Rewrites are easier than the first strike

[Anonymous Coward]

"There are plenty of different variations of NoSQL Databases. Column Stores like Cassandra (with unlimited ampoounts of columns, *cough* *cough* how useful would a storage with only two columns be?), document based like Mongo DB, XML based or simply graph based ones (e.g. OrientDB and Neo4J)."

How useful would column store with be only two columns be? A document store is, by definition, a column store with exactly two columns...

The entire point of a document store is to collapse all of the data columns into a single column containing a structured document (e.g. XML) which can represent the equivalent of multiple tables. Querying against a structured document which contains all items of a given type is both easier and faster than querying a database. It also scales a lot better and is easier to manage and modify.

Re:Rewrites are easier than the first strike

[Anonymous Coward]

First of all, if you are switching databases post-implementation, you are doing db selection wrong. Your architecture phase is broken.

Second, your personal experience regarding switching databases is unconvincing to me. It's not a matter of quoting examples, it's a matter that IT is a huge field now and no one can possibly have enough knowledge to make such statements that are applicable in general. Unless you are a statistician or similar, who has performed a statistically valid survey, with known margins of error?

https://www.youtube.com/watch?v=b2F-DItXtZs&feature=player_embedded

Re:Rewrites are easier than the first strike

[angel'o'sphere]

"Hint: if you 1:1 translate Java to C++ or C++ to Java, the speed of both programs are more or less the same. As both get compiled down to more or less the same assembly code. To improve one version over the other you have to do much more."

Care to give an example where my claim is wrong?

I'm waiting, I guess the rest of the community, too.

Re:Rewrites are easier than the first strike

[Zero__Kelvin]

I just gave an example where it isn't even possible. How more wrong do you want to be?

Re:Rewrites are easier than the first strike

[angel'o'sphere]

If you gave an example you forgot to click "submit", in the posts in this thread you gave no example where C++ is by default faster than Java.

Re:Rewrites are easier than the first strike

[Zero__Kelvin]

I hit submit. You just ignored it. The challenge was: Write a 0x55 to location 0xdeadbeef (without writing to any other locations, of course)

Time in C++: About 30 to 100 nanoseconds on a 1Ghz CPU
Time in Java: Infinity (You literally can't do it)

Just accept that you are outclassed (couldn't resist the pun) and move on with the rest of your sub-par competence based life, such as it is.

Re:Rewrites are easier than the first strike

[angel'o'sphere]

That is not a "program" but a single statement.

And yes it can be done in Java, quite easily ... but after your permanent insults I leave it to your google fu how to do that :D

ROFL

However I admit with all set up work to do in Java, C++ would win there. Now write me a C++ compiler in C++ and Java and tell me why a C++ version would be faster, or write a Java compiler ...

Re:Rewrites are easier than the first strike

[Zero__Kelvin]

"That is not a "program" but a single statement."

Imagine my surprise that you don't know that is is a program, and may or may not be a single statement. Furthermore, It can't be done in pure Java, and I'd say you know it, but given your demonstrated level of incompetence you probably think that it can.

"And yes it can be done in Java, quite easily ..."

Calling an API that is bound to C, C++, or Assembly via JNI isn't doing it in Java, idiot. It is still doing it in C, C++ or Assembly. You must think I am as big a moron as you are.

Re:Rewrites are easier than the first strike

[angel'o'sphere]

Calling an API that is bound to C, C++, or Assembly via JNI isn't doing it in Java, idiot.
Idiot yourself again.
I simply call a java method :D which belongs to the API of the vendor, if the vendor uses C/C++ or what ever is up to him. My code is still pure Java :D

As we talked about programs, I obviously meant a program of some complexity that does something meaningful, like sorting a linked list or something. Or any of the typical C examples in C beginners books.

That some stuff *can't* be done in Java is plain obvious, pointing such things out does not contribute to the discussion.

You must think I am as big a moron as you are.
No, I don't think that. A I'm not a moron, so the greater relation does not apply. However you are one ... no idea how you want to express this programmatically ;D

In some programming languages you have beyond classes also categories, I guess you would fit into the moron category quite nicely.

Re:Rewrites are easier than the first strike

[Zero__Kelvin]

"That some stuff *can't* be done in Java is plain obvious, pointing such things out does not contribute to the discussion."

I showed you a program that i much faster in C++ than Java. I say infinity, you say it just takes much longer because you have to call an API. Either way you agree the program I propose takes far longer in Java. You lost. You are just too stupid to realize it.

Re:It's a miracle! C++ makes disks spin 10x faster

[Anonymous Coward]

Really,
a. was it a 1 to 1 port. Obviously using seastar, no.
b.if they rewrote the Java implementation with the latest the language offers and such (like using seastar), would it be 10x faster, likely not... likely on par with performance.

Use the tool for the right reason, C/C++ --> optimized compilers, Java--> Robust VM & framework flexibility. Yes, in 3yrs that DB is going to be a mess to maintain... really. But to those IT/Maintenance coders, they will deny that and boast great justifications why it's still better, mainly better that it's them with the $100K+ O&M jobs/contracts.

But is it web scale? MongoDB is web scale...

[Anonymous Coward]

I will only use MongoDB because it is web scale.

Re:It's a miracle! C++ makes disks spin 10x faster

[Anonymous Coward]

Let me fix that for you: C/C++ --> optimized software, Java --> write once, debug very slowly everywhere.

Re: It's a miracle! C++ makes disks spin 10x faste

[Anonymous Coward]

But but but... That would interfere with his vested interests in java programmer spawn points in India, Pakistan, Vietnam etc....

Re:It's a miracle! C++ makes disks spin 10x faster

[Anonymous Coward]

Think about some databases project that switched to a vectorized engine and claim x10 to x100 improvement? Databases are not necessarily I/O bound.
Check the benchmark that scylladb published. They use some standard cassandra-stress command. I am sure that Cassandra has been heavily optimized to work well with cassandra-stress. In fact, I wouldn't be surprised it is the most optimized benchmark for Cassandra.

Re:It's a miracle! C++ makes disks spin 10x faster

[SQL Error]

Yes. It's now easy to scale to a million or more IOPS on a single server. That makes the CPU the bottleneck again.

Another justification of C

[Ungrounded Lightning]

Generally the justification for straight C or ASM is to remove runtime bloat, and you'd first have to give up using any frameworks to get there.

Another is if you have to security audit the result and protect it from attack, as in OSes. C++ can generate stuff that isn't obvious from the local source code - thanks to definitions, overridings, and the like. (Linus makes this point - it's why the Linux kernel is in C and will stay there for the foreseeable future.)

But that shouldn't be enough of an issue here to drop the helpful things the C++ compiler can do for you. (Especially when you're porting from an original in Java: C++ is a good match for a target language, C is not.)

Framework, not language

[Anonymous Coward]

From TFS: "The performance of the new code is attributed to writing it in Seastar".

I look forward to this being ignored in favour of more shallow, ignorant Java bashing. After all, it's owned by Oracle now and they are baaaad so it must baaaad too! Baaaad! Baaad baaa baaaaa!

Re:Framework, not language

[Anonymous Coward]

Java was bad under sun as well.

I haven't used Java for the last 10 years, but these where my issues with it:
- Unpredictable garbage collection. So what you have to do as a good Java programmer is never allocate/deallocate during the lifetime of your application. This means creating resource stacks/fifos, where after you are done with an object you put in on the resource stack where you retrieve the object for new use instead of allocating one. So now you are still doing memory management.
- Fixed memory size, you have to pass on the command line how much memory the JVM will use. There is even a hard cap on the size of the JVM, if you want to use more memory you have to write a native language plugin that it able to use its own memory (it can't pass this memory to Java). The fixed memory size is also an issue when running many Java applications, like on servers, which run out of memory quicker than needed.
- Every application on the process list is called java, you can look at the command line arguments (unless you want to increase security by disabling command line argument viewing), but it is definitely not pretty.

I always say that: "You need very good programmers to get Java to work well. But very good programmers don't want to program in Java."

Re:Framework, not language

[Ash-Fox]

Unpredictable garbage collection.

System.gc();

Re: 10x faster only? I did better w/ online speed

[Anonymous Coward]

what's the fun in that? Some of us enjoy the interstitial trolls among the more 'serious' posts

Because it is using dpdk

[Anonymous Coward]

this bypass kernel networking stack so it is faster.

Re:Because it is using dpdk

[Anonymous Coward]

Actually, while using DPDK is an option - and should perform better than the kernel's network stack - the benchmarks shown on their site appear *not* to be using DPDK, because they had some problems with DPDK on the benchmark machine. Results with DPDK should be even better.

Who cares 1M transactions in ONE node?

[Anonymous Coward]

No sense...

User mode memory mapped network stack

[pikine]

The real reason is much more nuanced than language differences between C++ and Java. The Seastar network architecture bypasses kernel TCP/IP stack entirely, but instead implements user mode TCP/IP stack using dpdk, which allows user mode to poll network card's packet buffer directly over memory mapped I/O. The user mode stack runs on single core only, but you could run multiple instances on multiple cores. It can scale linearly because there is very little shared state across cores.

C++ with custom network stack vs. Java with traditional network stack is not an apples-to-apples comparison. In theory, you could implement a Java based custom network stack over dpdk as well to make the comparison more fair.

Re:User mode memory mapped network stack

[Anonymous Coward]

It's a shame DPDK is so hot right now. From a software architecture standpoint, it implements the exact opposite abstraction you'd want in order to implement clean, safe, and reuseable code. The bugs from DPDK-using software will haunt us for decades.

Netmap (http://info.iet.unipi.it/~luigi/netmap/) is just as performant but is much easier to compose in software. That is, to encapsulate and abstract so your entire software stack isn't littered with dangeous and complex atomic reads and writes, and coded in a callback, continuation passing style that results in spaghetti code paths--the same kind of spaghetti that gave gotos a bad name. Netmap solves the code flow problem by allowing applications to use the traditional poll model. Intuitively you'd think this would be slow, but in practice it's not. And the zero-copy is still there but much using a much saner and safer model.

It works for both Linux and FreeBSD (merged into FreeBSD, in fact), but it doesn't have much mindshare. Intel has been sucking the air out of the room. Intel's sales department aggressively pushes DPDK to appliance and software vendors by ostensibly giving it away for free along with some free consultations, but of course it only works with Intel hardware. Most programmers drink Intel's Kool-Aid and think DPDK is the greatest thing ever. It's an especially evil version of the Gillette model: they give away the sharp, lethal code and require you to buy their CPUs and NICs (instead of giving away the handles and requiring you to buy the razors). And all the while there's the free Netmap, which is a product from future--safer, easier to use, and just as performant.

Netmap should be pretty easy to integrate into Java, but everybody too is focused on DPDK.

Re:User mode memory mapped network stack

[Anonymous Coward]

++ Yes this.
A lot of the performance improvements (especially the linear scaleability) originate from the fact that they are not using the POSIX network stack and also have per core instancing with messaging. Sounds like classic principles of the actor model to me. Now, if we could only have a language that maps nicely onto that model. Not C++.

Is it possible to have C++ Java mix

[Anonymous Coward]

Related thread - Why was Cassandra written in Java?
https://www.quora.com/Why-was-Cassandra-written-in-Java

Also, how easier or more difficult it would be to have Java C++ mix. That is identify bottlenecks in Java code, and only recode those in C++.

Probably changed algorithms as well

[Anonymous Coward]

I suspect that during rewrite they also changed algorithms as well. Surely when devs do rewrite they don't just blindly copy code row by row so that it just works. It is also possible that during rewrite they fixed some problems that could only be done by rewriting huge junks of code... if they are really saying java is 10x slower, they are just incompetent which would make me rethink twice using their C++ Cassandra. Nothing against C++, just saying screwing up with it is easier.

fast, but...

[Anonymous Coward]

Fast, but is it web-scale?

Just imagine, if we used C instead

[Anonymous Coward]

10x faster in C++? Imagine 100x faster using plain C instead of the overhead of C++

I don't buy it.

[FithisUX]

I have seen terrible C++ code and it takes long to get correct. The arrogance of "C++ code is fast" is well known. With Golang they could have written the whole thing faster with similar speed. But even then, I am also suspicious of the C++ is 10x faster than Java for this kind of task. The frameworks or the quality of java code make a huge difference. I am even tempted to take a look in the Cassandra codebase to see what went wrong. Maybe the problem is that they have not updated to Java 7 or 8 practices which in my opinion is half of performance lost. The other half is that people try to have something working correctly and optimise later. But even in that case, I could still try C or D before delving into C++. I really don't buy the whole argument.

C is great for low latency

[Anonymous Coward]

Aerospike got a strong competitor now! The main advantage of using C++ instead of Java is the latency

Is Goatse Webscale? If Goatse is Webscale

[Anonymous Coward]

I will use it

Re:It's a miracle! C++ makes disks spin 10x faster

[Anonymous Coward]

Even with SSDs there is still a bus between the CPU and the disk. That bus just returns a successful result faster.

In fact, if you could keep your writes small enough, and didn't worry about the write acknowledgements, you could consider your write done when it hit the spinning disks's cache. It is not a suitable way of writing for most databases, but if you are effectively using journaling techniques with small writes, you can get near-bus performance at the cost of three writes per actual write.

The CPU is rarely the bottleneck anymore. It's the bus, which is mostly being asked for RAM access. We've let our programs grow big enough that they cannot be easily cached, and so we have lousy cache performance. That's because everyone's in a rush to write performance code in the first pass, so we get a lot of crap loaded that's completely unnecessary, but takes up enough ram you overflow you cache.

Re:It's a miracle! C++ makes disks spin 10x faster

[gbjbaanb]

a 1-to-1 port does not mean what you think it does,

You think it means mapping every method to the same written in a different language. That's just crazy.

What they have done is create the same functional beast as Cassandra, using whatever programming methods and libraries their chosen language (which just happens to be C++) has. Hence a 1-to-1 reimplementation of the project.

Its pointless to think that a C++ port should implement a Java string class when it would use its own. The methods would be different and various bits of code would therefore be different in how they operate on strings. That's just a simplistic example.

I've not seen the C++ code but there's no reason to think its unmaintainable, in much the same way as saying the Java code was unmaintainable too.

any good documentation on Seastar?

[NostalgiaForInfinity]

Seastar looks like it might be a useful library, but the documentation I can find on the web site seems a little thin. Any suggestions for code samples/documentation besides the distribution?

Holy Fucking Shit!

[Anonymous Coward]

So many excuses and so much snark in this thread.

If you think your superior intellect can speed up the Java version to equal this C++ version, then prove it. Until then, STFU.

Right now, the only proof we have is that the C++ version is ~10 times faster than the Java version. This is unsurprising to many people, but your wishing it wasn't so doesn't change the reality.

Re:Holy Fucking Shit!

[Anonymous Coward]

^ this * 1000. Anyone who's ever run a Java app knows Java's a dog. Maybe if you're comparing it to Ruby it seems fast, but not to anything written in C or C++.

And then add a good async library in instead of Java's threads, and yeah, I can believe at least 10 times as fast.

Seastar or C*?

[RandCraw]

The similarity of the name 'Seastar' to Connection Machines' dataparallel programming language C* can't be an accident. But C* needed to run in shared memory or at least atomic synchrony on low latency distributed memory in order to preserve consistency. And of course, it needed SIMD algorithms (do the same op concurrently on a large pool of data) or it could add no value over using C.

Sounds like a misnomer to me.

Re:Seastar or C*?

[Anonymous Coward]

The similarity of the name 'Seastar' to Connection Machines' dataparallel programming language C* can't be an accident. But C* needed to run in shared memory or at least atomic synchrony on low latency distributed memory in order to preserve consistency. And of course, it needed SIMD algorithms (do the same op concurrently on a large pool of data) or it could add no value over using C.

Sounds like a misnomer to me.

Nobody heard of this "Connection Machines' dataparallel programming language C*" you are referring to. More likely, the pun was on Cassandra's nickname, "C*".

Re:It's a miracle! C++ makes disks spin 10x faster

[iamacat]

The purpose of Cassandra is to optimize durable writes to disk. If you don't care about occasional data loss or your main concern is read performance, it's probably not the right tool. If you want correct results, the node you are talking to has to wait for data hash from at least one other node, and these network hops can not be THAT fast, even if everything is memory.

Why not put a nice, optimized C, memcached instance in front of your cluster for the cases where you don't care about durability or consistency?

I predicted this years ago.

[jpellino]

But no one believed me.

In 2007, Mr Linux was right, C++ was very bad

[lsatenstein]

In 2007, there were no appropriate frameworks or other multitasking facilitites within C++. The optimisation was the pits.

Now, 8 years beyond, one can use C++, along with templates and all the other goodies, provided.....

provided that the latest Bjarne Strousaps's standards for coding clean C++ are followed. Bjarne proposes methods to follow, in lieu of "don't use arguments".

That means I may actually start using C++ again.

Lean vs fast vs resources

[fyngyrz]

Lean code is always an issue. If your code incurs a x2 to x10 overhead associated with the virtual machine,

No. "Lean" does not mean "fast" (nor does it mean "slow.") Lean means low-ish byte count. Fast means fast. Slow means slow. Lean means a smaller executable/dataset. There are many instances where a lean program will be slower than a heavyweight one. For instance, a precalculated table of complex formulat results typically takes much more space than the actual calculation. The precalculating program will be faster, but less lean, than the one that does the calculations every time they are needed. Further, this kind of thing can be an excellent use of resources if higher speed is desirable, which it usually is -- because while memory has become relatively inexpensive, CPU speed remains a scarce and hard-limited resource. Virtual or otherwise.

NASDAQ use Java:

[Anonymous Coward]

The NASDAQ wall street big stock exchange called INET, with sub 100 microsecond latency and extreme throughput, is written entirely in Java. NASDAQ claims INET is fastest in the world. All the world's fastest stock exchanges are written either in Java or C++. High Frequency Traders go to the fastest stock exchange, and there are lot of money involved. If C++ were faster, everybody would ditch Java in favor of C++. The SECRET Nasdaq uses to get fast Java, is not to use real time Java. No, NASDAQ shuts off the Garbage Collector. In effect, NASDAQ INET stock exchange system preallocates lot of objects that are constantly reused all the time. In that way GC is never triggered and Java speed can rival C++.

In addition, adaptive optimizing Java compilers can in theory be faster than C++. When you compile C++, you typically only target a least common cpu with no special assembler instructions. There are not much optimizing going on, as the code needs to run on all cpus, including old ones without support for, say, vector instructions. So, there are not much special optimizing going on in C++ compilers, when you finally release your C++ binary. OTOH, Java can examine the cpu and turn on vector instructions - C++ can not do that. Sure, you can release several C++ binaries targeting different cpus, or provide different code paths in the cpu, so the code path will use vector instructions on a modern cpu.

In addition to this optimization, Java can also optimize like this (which C++ can not do): if your code path handles lot of objects of a sub class for the first hour and another sub class the next hour - Java can adapt and optimize according to subclass X or subclass Y. C++ can not do that run time. C++ has static optimization, Java has dynamic and adapts almost in real time depending on the different types of objects. C++ can not do this optimization. So this is at least one optimization where Java is better. And in theory, adaptive JIT is faster. Compiler theory advances, so it is just a matter of time before JIT is faster than static binaires.

In fact, I know that several High Frequency Trading firms obsessed with speed, are using Java. /Former NASDAQ employee

Re:NASDAQ use Java:

[Movi]

Right. Except that gcc has had -march and -mtune forever.

Idiomatic Java?

[bucky0]

I learned Java way back in the 5 days. Obviously things have changed since then (and I was much less experienced). What examples are there of "the right way" Java applications?

For instance, is there a performant HTTP server/proxy that keeps pace with something like nginx whose source I could browse to see the state of the art?

The right tool for the right job...

[Anonymous Coward]

Looking at the big picture, I am paid to write software for a manufacturing company. Everyone here is talking about execution speed but how about talking about the time to develop software. This cost is what the concerns the people paying you.The language you use should be the best fit for life cycle development for the particular situation. I've started in assembly in 1980 and have progressed to c++ and java OO now. For instance I use C or C++ for low level hardware (micro-controllers and data collection devices) and Java for Enterprise level applications over the Web. Many times C libraries can be used with Java with JNII or JNA and you get the best of both worlds. Although I prefer C++ personally, if I can get the job done in Java or another language quicker I will.