6 ms·
Very cool idea - but unless I'm missing something, this seems very slow. I just wrote a simple loop in C++ to sum up 0 to 2^30. With a single thread without an
by ziedaniel1 2y ago
Very cool idea - but unless I'm missing something, this seems very slow.
I just wrote a simple loop in C++ to sum up 0 to 2^30. With a single thread without any optimizations it runs in 1.7s on my laptop -- matching Bend's performance on an RTX 4090! With -O3 it vectorizes the loop to run in less than 80ms.
#include <iostream>
int main() {
int sum = 0;
for (int i = 0; i < 1024*1024*1024; i++) {
sum += i;
}
std::cout << sum << "\n";
return 0;
}
- rroriz 2y agoI think the point is that Bend in a much higher level than C++. But to be fair: I also may be missing the point!
- molenzwiebel 2y agoIf compiled with -O3 on clang, the loop is entirely optimized out: https://godbolt.org/z/M1rMY6qM9 https://godbolt.org/z/M1rMY6qM9. Probably not the fairest comparison.
- LightMachine 2y agoExactly, this kind of thing always happens with these loops, which is why I think programs that allocate are fairer. But then people point out that the C allocator is terrible, so we can't make that point :')
- mst 2y agoMight be worth seeing if e.g. jemalloc is enough less terrible for the sort of examples you're looking at to help with that. (though note that I mention jemalloc because I've had "huh, this C code now magically runs faster" experiences with it, make no claim it's the right one to look at, and am very sure that I don't know what I'm talking about sufficiently wrt allocators to be able to recognise the right one if it bit me on the leg)
- ziedaniel1 2y agoI used GCC and checked that it wasn't optimized out (which actually surprised me!)
- LightMachine 2y agoBend has no tail-call optimization yet. It is allocating a 1-billion long stack, while C is just looping. If you compare against a C program that does actual allocations, Bend will most likely be faster with a few threads. Bend's codegen is still abysmal, but these are all low-hanging fruits. Most of the work went into making the parallel evaluator correct (which is extremely hard!). I know that sounds "trust me", but the single-thread performance will get much better once we start compiling procedures, generating loops, etc. It just hasn't been done. (I wonder if I should have waited a little bit more before actually posting it)
- nneonneo 2y agoIf they’re low-hanging fruit, why not do that before posting about it publicly? All that happens is that you push yourself into a nasty situation: people get a poor first impression of the system and are less likely to trust you the second time around, and in the (possibly unlikely) event that the problems turn out to be harder than you expect, you wind up in the really nasty situation of having to deal with failed expectations and pressure to fix them quickly.
- naasking 2y agoThat's how development under open source works. You can't please everyone.
- nneonneo 2y agoThere’s a big difference between developing something and announcing loudly that you have something cool; the developers have done the latter here.
- Ar-Curunir 2y agoThats completely unfair. They have developed something cool, just with not all the holes plugged.
- vrmiguel 2y ago
- nneonneo 2y agoYou might want to double check with objdump if the loop is actually vectorized, or if the compiler just optimizes it out. Your loop actually performs signed integer overflow, which is UB in C++; the compiler could legally output anything. If you want to avoid the UB, declare sum as unsigned (unsigned integer overflow is well-defined); the optimization will still happen but at least you’ll be guaranteed that it’ll be correct.
- ziedaniel1 2y agoI did make sure to check before posting. Good point about the signed integer overflow, though!