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

[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?

[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?

[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?

[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!

[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]

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!

[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!

[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!

[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!

[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!

[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!

[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!

[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]

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!

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

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]

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

[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++

[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++

[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++

[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++

[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++

[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++

[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++

[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++

[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++

[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++

[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++

[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++

[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++

[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++

[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++

[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++

[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++

[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++

[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++

[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++

[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

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"

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.

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.

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

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

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

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.

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]

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

[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]

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

[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

[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

[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

[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

[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

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

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

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

Because it is using dpdk

[Anonymous Coward]

this bypass kernel networking stack so it is faster.

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:Framework, not language

[Ash-Fox]

Unpredictable garbage collection.

System.gc();

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.

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?

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

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?