Hacker News Reader

Comment by jaekwon | Hacker News Reader

All I did was take your for-loop code and translated into idiomatic Go code. My point is the for-loop in Go isn't as terrible as the loop example you wrote.

View on HN

Your version infinite loops: http://play.golang.org/p/uglbTETE6d

See why for loops are tricky? :)

Doh! I fell straight in :)

Overflows in general are tricky. How does Rust deal with it?

We have special checked types you can use if you want checked arithmetic. The default is to not check, because CPUs currently make it expensive to check (although I would love it if that could change--we need hardware support though).

Nice. :)

But CPU's have the overflow flag, that is actually set if the operation overflows?

You can't write that check explicitly in C, but you can in assembler. Available now, across the different hardware.

As you say, detecting the overflow is easy, but efficiently handling it is not. It adds a branch to every single arithmetic operation, and it makes it much harder for the compiler to optimise things e.g. it is hard to vectorise a loop summing an array, if every + has a conditional branch on the overflow flag.

(Also, I believe it introduces a lot of data dependencies, getting in the way of the out-of-order execution of modern CPUs.)

To handle the overflow on the places where you want to handle them, modern processor doesn't have any problem with an additional jump instruction. Also, modern compilers could optimize the checks away if they aren't used. In effect, implementing overflow checks definitely won't turn your C speed (1s) code in a Python speed (40s) code. I estimate it wouldn't be even two times slower in most of the use cases. It's certainly not the problem of the CPU's.

It can be the problem of the certain compilers if they don't have the infrastructure to reason about overflow flags though. But it's not a hardware problem.

> I estimate it wouldn't be even two times slower in most of the use cases.

In his "We Need Hardware Traps for Integer Overflow"[0], Regher quotes 5% to 100% overhead for languages such as JS or Racket, and that a "highly tuned" checker would likely be in the 5% range. Playing with arithmetics-heavy programs and Rust's checked_* (which are backed by LLVM's overflow intrinsics[1]) I got anywhere from 5 to 40% performance loss IIRC.

That's not a lot, but at the same time when you're competing with languages specifically not paying those 5%, a 5% hit on all computations is not going to get you much love.

Which is why Rust currently lets you do that (via num::Checked* and num::Saturating) but uses overflowing default semantics.

[0] http://blog.regehr.org/archives/1154

[1] http://llvm.org/docs/LangRef.html#arithmetic-with-overflow-i...

OTOH I must note that Swift, on the other hand, has opted to error on overflow and have a second set of overflowing operators: https://developer.apple.com/library/mac/documentation/swift/...

And that's the best approach I can imagine: programmer should be able to control if he wants 5% penalty or speed. It's a win-win.

> To handle the overflow on the places where you want to handle them, modern processor doesn't have any problem with an additional jump instruction

This isn't just a jump, it is a branch. Especially when the body of the loop is 6 instructions, adding an extra branch is going to be noticable.

> Also, modern compilers could optimize the checks away if they aren't used

This is equivalent to the halting problem, and most code will not be able to optimise them away. Suggesting otherwise is invoking "sufficiently smart compiler", which is invalid.

In any case, you haven't addressed the problem of missed optimisations (especially vectorisation) caused by having to maintain semantics.

> It's certainly not the problem of the CPU's.

Yes, it partly is: the data dependencies and linearisation caused by checking the CPU flags is bad.

I love when arguments are decided by/proven by runnable code examples.

Just use int and it works fine: http://play.golang.org/p/nZcd3M5aL_

To me golang is readable while even small rust examples don't feel quite right right.

> Just use int and it

is a completely different piece of code.

Reply on news.ycombinator.com