While I don't have enough experience in really low-level tuning, I know that sometimes people get so focused on optimizing their current implementation that they fail to see that their overall design has trapped them in a local maxima. Problems like inappropriate algorithms are usually more obvious in higher level languages, because there's less detail obscuring them. That stuff needs to be right before getting to fine tuning. (Prototyping in another language first helps.)
C and C++ are quite fast locally, but sometimes that works against being fast overall.
DSP is one domain where performance of a tiny part of the code (say 1%) is far, far more important than everything else. If you need to apply a filter to remove high frequencies, or if you need a Fourier transform, no high-level tuning or special algorithm will cut it: you need the filter or the transform, even if it's very costly. The bottleneck is real and unavoidable.
I work in data acquisition and in this domain C/C++ is king. The raw number-crunching is essential (for our applications anyway), and any bonus that can be had from SSE operations, cache locality, loop unrolling, software pipelining, etc. can have a major impact on the overall performance. Assembly is still common on DSP processors and the like (they typically provide a special instruction set). Even in C++, we tend to use the bit-twiddling and pig disgusting optimization hacks that low-level access provides :)
Some people use higher level tools such as LabView but the performance is a huge step down. It's OK for prototyping and learning.
No. Objective C isn't performance oriented, and while it's fine for most desktop apps (!) it's not in the same league as C++. C++ can actually let you use higher level structures that are faster than in C or Objective C because of template meta programming, as shown in the Blitz template library for numerical computation.
http://www.oonumerics.org/blitz/
This is what Templates are made for. And this is what you can't do in something like Java or Objective C. Java Generics boiling down to type cast at run time to and from Object, it doesn't help performance a bit.
Maybe, but on the flip side, you could argue that a lot of high-level languages are trapped in hash tables, and are missing a lot of opportunities for fast tree-walking implementations.
It's tricky to really push on high-level languages because for every argument against one, there are 3 other languages that don't exhibit that problem. If there was a platonic ideal of a high-level language to argue from/with, this would be a more useful debate to have.
Indeed. OCaml is an interesting exception, though: it's very high-level, yet still quite fast. (The trade-off, if you can call it that, is that you have to work within its type system.) It's not necessarily as fast as (or faster than) C, but even relatively naive OCaml code is often only about 50% slower.
There's often a point of diminishing returns in spending time and effort optimizing C, and OCaml can get surprisingly close with much less work.
The standard approach I heard was to code in a very high level language (like python) to get the algorithms right, then rewrite in C for performance. Python then becomes a sort drawing board as part of the design stage, instead of "coding".
Rewrite only those pieces that are consuming a lot of time or memory, leave the rest in Python, which is particularly good at integration with C/C++. Many programs are a lot of setup, error handling, and edge cases where performance is not an issue. but LOC is.
I thought about including the idea of only rewriting the hotspots, but left it out as detracting from the main point and it seemed tedious to iterate the details. But then there are 3 replies pointing this out, and which seem to be more valued than mine by the community (according to their votes.)
Ask HN: Does this mean that HN would prefer I wrote comments that do cover all the cases, instead of just sticking to the key point? Or is it just that there seemed to be a gap in my comment, which people naturally wanted to cover?
Note: the replies add more than just "rewrite only hotspots" (like the above one detailing setup, errors, edge cases), and I certainly appreciate extra details being filled in. Is the valuable extra detail the reason for the extra votes? I just feel kind of annoyed that the replies seem to suggest I was stupid in not mentioning the hotspot idea. This has happened to me a few times now. Am I taking it too personally? Is it just a question of different opinions on what is important? Or is it just that I failed to communicate my decision, and then get annoyed when people point out the other branch of the decision?
There is a issue of preference here: I prefer to keep all the code in one language. One factor in this is that my projects are small, and for these, the overhead of switching languages and managing the different source isn't worth it. I'm not running up against efficiency problems either. I'm sure it's different for larger projects, especially multi-person ones, and particularly if the project covers different kinds of activities (for which different languages are suitable), and even more so if there's need to integrate with or reuse existing assets in different languages.
> I just feel kind of annoyed that the replies seem to suggest I was stupid in not mentioning the hotspot idea.
I didn't mean anything personal, and I don't read any of the other comments that way.
The other comments may have just been voted up by people who also like Lua or Mercurial, or something. I thought it was worth noting that Lua was explicitly designed for that style of development. (Lua's also my favorite language.)
Thanks. Yes, that's true. I appreciate the information about Lua and an example of Mercurial - it was just the hotspot part. I guess the fairest guess is that a comment is voted up as a whole, based on all the things they add, not just the part that I happen to be concerned about. It seems a bit silly of me now, but I much appreciate your reply.
Lua's great for this, too (and rewriting just the few hotspots is usually enough, Lua's pretty fast). They designed it to be embedded in C from day one, so it's quite easy.
Mercurial is a great example of this approach. Overall, Mercurial is comparable to Git. (Git does maintain an edge in speed, but they are still competitive.) Most of it is written in Python, though.
C and C++ are quite fast locally, but sometimes that works against being fast overall.