Hacker News Reader

I think you're exaggerating performance differences. Reasonably written Python is not 10000 times slower than reasonably written C++, nor reasonably written Java is 3-5x slower. And while I agree that creating a super-optimized tight loop of a program in C++, C or (better) assembly might be much easier to do than in higher level JITted languages, but this does not scale to huge and complex codebases. At some point you'll be struggling with overall project complexity, and architecture / high level design can affect performance more than those low-level bits. A higher level language will be more amenable to refactoring and fixing high-level performance problems than a low-level language like C or mid-level language like C++. So then, you might be much better choosing a high level fast language like Haskell or Scala or even C#/Java than C++.

Not every Python program is slower than C++ by a factor of 10000. Some are. Some Python can be reasonably fast as long as all the heavy lifting is done in native code, e.g. numpy or scipy. Let's say it would typically be more in the x250 range for algorithmic code that uses native Python types. You get to the 10k range when you create your own types and do meta-programming and try to do algorithms over that. YMMV.

The point I was making though was that if you don't care then you don't care. I wrote some Python for a friend who wanted to scrape and process financial information from various web sites. I'd be an idiot to do that in C++. None of us cared how long it took to run (as long as it wasn't weeks). Having access to various Python libraries made this task a breeze and maintainability wasn't much of a concern either.

Andrei wouldn't have made that statement about C++ vs. Java if the difference was in the noise. I think x3-5 is a reasonable rough number to put on it but while I can point to benchmarks I can't point to a comprehensive study that shows "reasonably" written across different domains. You're welcome to take those numbers with a grain of salt and do your own investigation. Another data point there is that C++ is the dominant language in Google Code Jam and TopCoder SRMs where writing fast and correct code quickly is a competitive advantage.

EDIT: I find a lot of people will underestimate the performance advantage of native languages vs. JIT or interpreted environments. The x10000 is something I've seen in a real world system. Another thing to consider is that in a native language you can drop to assembler to optimize performance critical sections. You have 100% absolute control over your hardware. Anyone know how this: https://code.google.com/p/h264j/ compares to the original implementation?

"The point I was making though was that if you don't care then you don't care."

I disagree with this. You always care, to some degree. If I write a one time, 100-LOC script to process a 1GB of data, I don't care if it takes 1 second or 1 hour. But I would care if it took 1 week or 1 month. That's why Java performance is good enough for 99% of programs I write, Python is also good for many, but if I completely didn't care for performance and wrote sloppy code in Python (or Java) I'd get into 10000x performance penalty region and this would be unacceptable in almost all cases.

"I think x3-5 is a reasonable rough number to put on it but while I can point to benchmarks I can't point to a comprehensive study that shows "reasonably" written across different domains" YMMV. The micro-benchmarks in Great Language shootout disagree with this. Most of them are within 2x range and the one outstanding is actually a benchmark of particular regular expression engine. Ok, we should not believe microbenchmarks, so what about real, optimized applications? Compare performance of Netty vs nginx. Or Tomcat vs Apache. This is a tie. Or Hypertable vs HBase (yeah, despite huge expectations and marketing, even in Hypertable own benchmarks, Hbase comes only... 50% - 2x slower). Or Jake vs Quake2 with Jake2 again not even 50% worse (actually better in some cases).

"C++ is the dominant language in Google Code Jam" This only supports what I already wrote - when writing a very small piece of code you have full control over, like for a competition, it is much easier to achieve high performance code in asm/C/C++ than in Java/C#/Scala etc. In a competitiona like that, even a 20% overhead is not acceptable and I'd also use C or C++. But you can't extrapolate that on large-scale programming, where benefits of using a high level language matter much more.

"Another thing to consider is that in a native language you can drop to assembler to optimize performance critical sections" I can do that in Java or C# as well.

Sure, there's some transition region between "don't care" and "care" but I find a lot of people tend to be strongly in one or the other (sometimes wrongly).

Another benchmark: https://days2011.scala-lang.org/sites/days2011/files/ws3-1-H...

Keep in mind though that the JVM is a moving target. It keeps getting better (on one hand) and on some platforms it's worse (e.g. Android, though the upcoming new version looks promising). It's possible the gap is smaller now than what I remember seeing in the past.

At any rate, if x2 is a number that feels right for the stuff you're doing I can't argue with that. You need to choose the language that works for you. Maybe you choose Java because of the libraries. Maybe you have more experience writing in Java and you're a lot more productive. Maybe there is better tooling. Maybe it's just more in line with how you think.

A web server does a lot of file I/O and a lot of network I/O. The performance of a web server is more about how efficiently you can juggle those given highly concurrent loads and what mechanisms are used at the native layer to interface to those systems. It's not so much about the "raw" power of the language. In your game engine example a lot of the heavy lifting is done in OpenGL which is native code. I'm also not intimately familiar with the details there. At some point it's also about how much effort went into optimizing things and whether or not something else was traded off.

To contrast that, Google Code Jam tasks are typically algorithmic and they stress the "raw" power aspect of the language. That said it's certainly not representative of real-world product development.

If you are thinking about the Android runtime, Dalvik and now ART, those aren't JVM (I think they compile to a different bytecode). There probably is a port of JVM but I didn't get the impression you were talking about that.

Dalvik does indeed use a different VM/bytecode. Your Java Android app is compiled JVM bytecode which is translated into Dalvik. The point is/was that the program you write in Java may run faster or slower depending on your target platform and that if your target platform is Android you are taking an additional penalty vs. e.g. using the NDK...

(EDIT: Yeah, you're right, the name JVM should only be used to refer to the specific type of VM that runs specific bytecode and not to other VMs. As Android shows Java does not have to run on the JVM. Thanks for the correction.)

"In 2012, academic benchmarks confirmed the factor of 3 between HotSpot and Dalvik on the same Android board, also noting that Dalvik code was not smaller than Hotspot" (from Wikipedia)

> creating a super-optimized tight loop of a program in C++, C or (better) assembly might be much easier to do than in higher level JITted languages

Sometimes, the situation is exactly opposite, though:

http://pzemtsov.github.io/2014/05/15/how-to-make-C-as-fast-a...

I've never seen 10000x going python to c++, but I've certainly seen 1000x several times.

Do you think maybe that Herb and Andrei might have a (completely understandable and probably unavoidable given human psychology) bias? Besides, appeals to authority tend to be frowned upon.

Now, I don't disagree that C and C++ are probably generally the "fastest languages"[0] at the current time. For most programs that's completely irrelevant -- what's more relevant is that the most dangerous security issues of the age almost exclusively come from these languages[1]. This is why, e.g. Rust matters, but also why languages without undefined behavior in general are a big deal. Undefined behavior is an abomination which has caused untold damage (even more than the billion-dollar mistake of "null").

[0] Somewhat of an absurd term, but let's just say that these languages encourage a style which leads to efficient machine code. [1] Lack of escaping (particularly SQL) is probably a close second.

EDIT: Btw, if I were really performance-bound, I think I'd actually use a higher-level language to create a domain-centric DSL to describe my solution and then use that to generate a lower-level program (in C/C++, assembler or whatever) which solved my problem. People have been doing that kind of thing for a few years now. See e.g. https://hackage.haskell.org/package/atom

It was not meant as an appeal to authority. It was meant as a reference to the experience of a larger software company who writes code in both languages. That said I'll agree they have a bias, everyone has. Full disclosure: I like C++. I also do like Python but it is my preferred language for specific scenarios.

I also agree to some extent that languages themselves aren't fast or slow (though to some extent they are). In theory equivalent code in two languages should result in machine code that is just as efficient and it is sometimes a fluke or some implementation choices that make it not so.

I can talk a little bit to the security question. One thing we need to consider is that we're dealing with systems, not strictly with bits written in some language. Various injection attacks are almost universally carried in platforms that are not C/C++ and their root cause is at the interface between systems (e.g. your web back end's interface to your SQL database). Even in systems that run in various isolated sandboxes there is always the possibility of penetrating that sandbox or to have other holes in the interfaces to the rest of the system. Honestly, the undefined behaviour bits in C/C++ isn't something that I've seen matter in practice. When all system code in the world is written in C you're bound to be able to point to some mistake causing security issues but we have no way of comparing that to anything (at least none that I can think of). There's always some way someone can screw things up. That said there's no harm in trying to do better- if we can get safer languages, where it's harder to make mistakes, and have all the benefits of the less safe language it's a win-win. No downside.

Fair enough. I apologize for the accusation -- it's just that you never know.

For the record, I also like C++. Especially in its modern incarnation C++11. It's a vast improvement over plain C (if you care about generic programming, as I do). I just think we need an even better language to take its place -- hopefully Rust can deliver, in time.

Re: Injection attacks: Most of the "holes" in e.g. VM emulation code also come from C/C++ legacy -- at least that's been my (admittedly anecdotal) experience.

> Honestly, the undefined behaviour bits in C/C++ isn't something that I've seen matter in practice.

This isn't exactly recent, but just for example: http://lwn.net/Articles/342330/

This happens all of the time, especially as optimizers get even better at exploiting the fact that undefined behavior "cannot happen" (per the semantics of the language.)

Ultimately: Yeah, definitely agreed on striving for better and safer languages as long as they deliver what we need even if those are different languages and different needs -- as long as we each get better and safer and faster* code in the end! :)

I hate to ruin if for you, but usually Python is only a few hundred times slower than C++, typical Java is maybe 20% slower, and well-written Java is about as fast.

No. Here's some guys demonstrating 5000x+ speedup by rewriting Python code in C and C++: http://codegolf.stackexchange.com/questions/26323/how-slow-i... and http://codegolf.stackexchange.com/questions/26371/how-slow-i...

Python was sped up 30x, according to the same post, so the difference between best Python and best C++ becomes "mere" ~170 times.

Of course, on numeric problems like this, plain CPython inevitably sucks performance-wise (no JIT, a lot of lookups, no value types).

At least I linked some numbers. Your statement "usually Python is only a few hundred times slower than C++" is so vague it is completely useless. The Python code was sped up by replacing idiomatic Python with non-idiomatic code (not your "usual" Python) and also replacing a large part of it with calls to optimized code written in C. If your claim had been "Python is only a few hundred times slower if you outsource most of your work to C libraries" I would have had no objection. But that's not what you wrote.

It's simply not a fair comparison if you change the algorithms between implementations.

That is somewhat misleading, since the optimized versions use different algorithms. There is also an optimized Python version that runs 30 times faster.

It is a combination of better algorithms and closer-to-the-metal language that gives the 5000x speedup described in the thread.

You can get arbitrary large speedups by just choosing a worse initial algorithm and then improve it.

This is not an argument I can win, that is constructive or necessarily meaningful, but here's what happened when someone tried to translate C++ to an equivalent Java program: http://codegolf.stackexchange.com/a/26536

(x2.5)

Also see: http://benchmarksgame.alioth.debian.org/u64/java.php (median x2 but this is stuff people spent time on optimizing which is not really what we're talking about here)

Java is not 20% slower or just as fast. But if it is please submit your Java solutions to the bench mark game for us to see.

Python is a few hundred time slower as long as you restrict yourself to native types (e.g. strings, integers, dictionaries, lists). Once you start defining your own classes and do more sophisticated things you get a lot slower. At any rate, my point was not to pick some specific number, my point was that sometimes you just don't care at all about how fast it runs. The x10000 was from a real world system but this can vary - a lot.

It's not hard to write single-threaded C/C++ code that's significantly faster than Java (although it will become harder once Java gets value types, that will address Java's biggest performance pitfall, namely cache-misses), and the simpler the code the better the chances for success (as complex code requires architecture employing virtual methods, and virtual method invocation in Java is faster than in C++ due to JIT inlining). But writing multithreaded code in C++ that's faster than Java is a lot harder, so much so that the C++ code will probably be significantly slower. The reason is that general-purpose lock-free data structures are a lot easier to write when you have a good GC (plus, the JDK includes state-of-the-art concurrent data structure implementations).

>>but this is stuff people spent time on optimizing <<

Optimizing both Java and C++ programs.

About optimization: If you really want to, the JVM can be surprisingly unrestrictive. You'd be amazed at the slightly mad things for example HFTs do with it. Advanced techniques include object reuse so you never activate the GC and unsafe calling of native code. Then there's the weird things you can do with the JVM directly. I can't find anything right now, but I recall weird annotations and multiline JVM arguments more wizardlike than anything. Finally there's alternative JVMs for those who want that.

In regards to weird things you can do with the JVM: You can actually allocate memory outside of the garbage collect from inside pure Java code. (Unsafe.allocateMemory, specifically. or you can use ByteBuffers, but I'm not sure which one is faster or if a ByteBuffer still interacts with the GC) This can allow you to deal with "objects" which are entirely outside of the GC, and can actually be a decent chunk faster then using normal objects. I did a microtest recently (which can mean absolutely nothing in practice) where allocating two normal objects and doing something with them was about 30% slower than dealing with memory outside the GC.

As for the other things you mentioned, those are actually pretty routine. At least in some places. If you're working on a game, then you're going to be reusing objects and calling native functions as a normal thing :)

I don't think unsafe calling is standard at all. It's non-standardized as well. Normally the JVM would copy objects between the JVM and the native process. With unsafe, they are operating on the same bits of memory.

Aaah, that's what you meant by unsafe. I thought you meant that using a native code call was technically unsafe. Thanks for the clarification. (and that actually sounds pretty awesome for game development, I'll have to look into it)