Long blog/rant about programming languages and more, written by a Julia user looking for philosophically sound arguments to why you should try #julialang out.
This is a very nicely written article. I especially like the way the author builds up by describing the evolution of dynamic and static languages and how julia does a great job at solving the problems facing most static and dynamic languages in scientific computing.
std::unordered_set<T> values, newvalues;
values.insert(target);
auto k = 0;
while (values.size() > 0) {
k += 1;
for (auto v : values) {
for (auto d : denominations) {
if (v == d)
return k;
else if (v > d)
newvalues.insert(v - d);
else
continue;
}
}
swap(values, newvalues);
newvalues.clear();
}
return {};
One because memory allocations can be pretty expensive performance wise, two because you never want to manually allocate memory if you have the standard library accessible to you (you want to use smart pointers instead), three because the allocation is completely pointless here in the first place because std::unordered_map allocates everything it needs internally, you can just create the object on the stack, so you just introduce an additional indirection and an additional allocation for no reason.
All together whoever wrote the code has no idea how to write C++ and was probably just happy that the code didn't crash. (Also this essentially just benchmarks the unordered_map implementation that happens to come with whatever standard library they're using instead of anything intrinsic to the language. How fast unordered_map does certain operations can vary wildly between different implementations, and if you really needed a similar data structure that delivers absolute maximum performance for your use case you would write it yourself.)
Also these "language x is this fast" comparisons are generally useless anyway, if you care about a 5x compute speedup or less you're going to use a native language and fiddle with it until the compiler gives you the binary code you want essentially (which in return means they're all equally fast if you do things correctly), and if you don't care about a 5x speedup you can use whatever language you want, they're all fast enough.
The only "language benchmarks" that are actually useful are ones that compare different coding paradigms, for example using exceptions vs not using exceptions, or inheritance vs function pointers, etc. - but these kinds of things require a fairly good understanding of the language and compiler options, and their conclusion is very often "it depends".
7 comments
[ 4.8 ms ] story [ 25.9 ms ] threadtemplate<typename T> optional<int> minimum_coins2(T target, std::vector<T> denominations) {
}c++ 180ms, julia 270ms (using a value of 9070)
All together whoever wrote the code has no idea how to write C++ and was probably just happy that the code didn't crash. (Also this essentially just benchmarks the unordered_map implementation that happens to come with whatever standard library they're using instead of anything intrinsic to the language. How fast unordered_map does certain operations can vary wildly between different implementations, and if you really needed a similar data structure that delivers absolute maximum performance for your use case you would write it yourself.)
Also these "language x is this fast" comparisons are generally useless anyway, if you care about a 5x compute speedup or less you're going to use a native language and fiddle with it until the compiler gives you the binary code you want essentially (which in return means they're all equally fast if you do things correctly), and if you don't care about a 5x speedup you can use whatever language you want, they're all fast enough.
The only "language benchmarks" that are actually useful are ones that compare different coding paradigms, for example using exceptions vs not using exceptions, or inheritance vs function pointers, etc. - but these kinds of things require a fairly good understanding of the language and compiler options, and their conclusion is very often "it depends".