3 ms·

True in a way. C++ programmers like to think that they're writing efficient code because of the language they're using. The same applies to some C programmers (

by tsahyt 14y ago

True in a way. C++ programmers like to think that they're writing efficient code because of the language they're using. The same applies to some C programmers (although at a lesser extent I think). In fact, the biggest gains are made on an algorithmic level. That's something a lot of people like to forget. Then again, the reverse isn't true. There are languages (or more precisely their implementations) that just are slow.

dllthomas 14y ago
The biggest gains are often at the algorithmic level, but once you are using a reasonable algorithm there are often large gains to be had in your bottlenecks. Furthermore, good asymptotic complexity doesn't always correlate with faster code for values of n you actually encounter. Linear search is much faster than binary search, because of cache behavior, up to a surprisingly large n on many architectures.
rubashov 14y ago
> the biggest gains are made on an algorithmic level I have had a few experiences of simply porting something rather directly to C++ and seeing 10X speed and memory improvements. The 'hidden costs' in other languages are loads of unavoidable heap allocations and pointer indirection that really don't happen with C++. And C++ compilers do a ton of very smart optimization these days. With the generic programming constructs and static polymorphism approaches in C++ you can often get really big performance increases over what's practical in C or Java. std::sort in C++, for example, has often been found a few times faster than stdlib.h qsort. It's because of compile time optimizations that languages like C and Java can't do.
- comex 14y ago
  Just a nitpick: sorting is a bad example because qsort could be made just as fast if it were defined in the header and marked inline. C++ provides more flexibility (you don't have to make everything inline, you can have a family of "real" functions indexed by type), but it isn't really necessary for sorting.
heretohelp 14y ago
Eh, you're right in theory, but in practice not really. There's on the order of a 1,000-1,000,000x difference or more between a Numpy version of what OkCupid does, and what their C++ does, even if you use the same algorithm. Similarly, when we recently farmed out a string similarity algorithm from Python to Java, with a more expensive and sophisticated approach in the latter, it ended up being conservatively ~10,000x faster. I love Python and use it for...just about everything really, but until you've actually optimized software at a systems level you really have no idea what you're talking about. Proper algorithms and data structures are necessary but not sufficient. It's a pity higher-level languages don't offer better escape hatches when you need them.

by tsahyt 14y ago

dllthomas 14y ago

The biggest gains are often at the algorithmic level, but once you are using a reasonable algorithm there are often large gains to be had in your bottlenecks. Furthermore, good asymptotic complexity doesn't always correlate with faster code for values of n you actually encounter. Linear search is much faster than binary search, because of cache behavior, up to a surprisingly large n on many architectures.

rubashov 14y ago

> the biggest gains are made on an algorithmic level I have had a few experiences of simply porting something rather directly to C++ and seeing 10X speed and memory improvements. The 'hidden costs' in other languages are loads of unavoidable heap allocations and pointer indirection that really don't happen with C++. And C++ compilers do a ton of very smart optimization these days. With the generic programming constructs and static polymorphism approaches in C++ you can often get really big performance increases over what's practical in C or Java. std::sort in C++, for example, has often been found a few times faster than stdlib.h qsort. It's because of compile time optimizations that languages like C and Java can't do.

comex 14y ago
Just a nitpick: sorting is a bad example because qsort could be made just as fast if it were defined in the header and marked inline. C++ provides more flexibility (you don't have to make everything inline, you can have a family of "real" functions indexed by type), but it isn't really necessary for sorting.

heretohelp 14y ago

Eh, you're right in theory, but in practice not really. There's on the order of a 1,000-1,000,000x difference or more between a Numpy version of what OkCupid does, and what their C++ does, even if you use the same algorithm. Similarly, when we recently farmed out a string similarity algorithm from Python to Java, with a more expensive and sophisticated approach in the latter, it ended up being conservatively ~10,000x faster. I love Python and use it for...just about everything really, but until you've actually optimized software at a systems level you really have no idea what you're talking about. Proper algorithms and data structures are necessary but not sufficient. It's a pity higher-level languages don't offer better escape hatches when you need them.