5 ms·

> The assert() macro in C is roughly just if ... { panic() } in Go The article very clearly says that (unlike normal C behaviour) it's a no-op in release build

> The assert() macro in C is roughly just if ... { panic() } in Go The article very clearly says that (unlike normal C behaviour) it's a no-op in release builds of SQLite, because otherwise they get a ~3x slowdown. Does Go compile away those `if` statements?

Stratoscope 8y ago
> Does Go compile away those `if` statements, or did you not read the article? The HN guidelines specifically request that we not make comments like this. > Please don't insinuate that someone hasn't read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- repsilat 8y ago
  You're right, it was out of line. Edited, and thanks.
  - Stratoscope 8y ago
    Well, thank you for taking criticism so well! We all get a little snippy at times - goodness knows I've done it myself more than I want to admit. I was about to delete my comment since it was no longer relevant, but maybe I will leave it here since your reply and edit are such a great example of how to be constructive and civil. (OTOH, let me know if you'd prefer for me to delete it.) Thanks!
tptacek 8y ago
Help me understand why this matters? Is it really Hipp's argument that Go is unsuitable for serious systems work because invariant signaling in the code is too slow? That seems pretty nitpicky, and also ironic since the "serious" systems language to which he's comparing Go is C.
- RHSeeger 8y ago
  I would take anything Dr Hipp says very seriously. While he may be wrong, I wouldn't discard his thoughts without some facts to back it up. SQLite, both its functionality and amazing test suite, as well as his other achievements, certainly make him worthy of my respect.
  - tptacek 8y ago
    Not to be snarky, but because it's relevant to the discussion: https://www.zdnet.com/article/sqlite-bug-impacts-thousands-of-apps-including-all-chromium-based-browsers/ https://www.zdnet.com/article/sqlite-bug-impacts-thousands-o... This stuff doesn't happen in Go and Rust programs.
    - apta 8y ago
      What does that specifically have to do with golang or Rust?
      - tptacek 8y ago
        Hipp's argument --- which comes kind of out of nowhere in his post --- is that Go is unsuitable as a serious systems language because it lacks compile-time asserts. Which is, I think, ironic, because his language is C, and so produces memory corruption vulnerabilities that languages like Go and Rust preclude. I'd rather have Go's guarantees than C's.
- pcwalton 8y ago
  Not being able to have code that compiles in debug but doesn't in release is a pretty serious issue for CPU-bound performance-critical code. Otherwise, you're going to be commenting things out a lot or using preprocessors, both of which are annoying and slow down development velocity. As an example, checking errors on GPU is enormously slow because you stall the CPU until the hardware FIFO drains every time you do. You can't ship software that checks for errors after issuing each DirectX or OpenGL call. But writing graphics code is also really annoying without a debug mode that checks for errors after each render command, because the failure mode of graphics programs tends to be "black screen" or "screen full of garbage".
helper 8y ago
In go you can use build tags to achieve this. The compiler will drop function calls to empty function implementations (tested on go 1.11.5).
bbatha 8y ago
It’s not the if staments: for an assertion the panic branch should be ice-cold and likely proven by invariants up the stack frame — other assertions or plain old conditionals — so in theory should be optimized away every time. It’s the expression in the condition that’s often expensive. The assert macro eliminates these trivially with the preprocessor , but go cannot as easily because the condition expression may have side effects.
deleted 8y ago
[deleted]
crawshaw 8y ago
I find the fastest way to introduce bugs into programs is to compile programs differently in development than in production. It also warps developer's perspectives of how their program performs. As they say at NASA, "Test what you fly, fly what you test." That said, you can do this easily enough in Go. Define a package: package debug const Debug = true func Assert(cond bool, msg string) { if Debug && cond { panic(msg) } } Have your build system generate the file that contains Debug = true. In optimization mode, make it Debug = false. As it is const, the compiler will propagate it, Assert will be inlined and the dead code removed. If you don't like relying on the compiler, have your code generator generate empty Assert functions. If you are working in a very bad code base that catches all panics, you'll need an extra 5 lines of code in the implementation of Assert, and your stack traces won't be pretty. (Roughly: put the condition check in a goroutine, block the Assert call on a channel signal from that goroutine.) I'd recommend the first project be to remove those panic catch-alls. But really, all of this is only appropriate when you are far out in the weeds. Ship your program with those asserts. If they are too slow for production they are too slow for development.
- kasey_junk 8y ago
  That will still evaluate the cond in all cases. Passing a func will make it lazy but might have performance implications (I’d have to test it).
  - crawshaw 8y ago
    It won't, because of inlining and dead code removal. (At least, it didn't back around Go 1.11 when I last tested this.)
    - kasey_junk 8y ago
      Maybe if the thing that is generating the cond at the call location is inline-able, but not if it's doing an expensive operation. https://play.golang.org/p/Ts6QqRrWwuQ https://play.golang.org/p/Ts6QqRrWwuQ I couldn't get that to not trigger the lock. [later] I could get it to remove it if you pass in a func instead.

Stratoscope 8y ago

> Does Go compile away those `if` statements, or did you not read the article? The HN guidelines specifically request that we not make comments like this. > Please don't insinuate that someone hasn't read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

repsilat 8y ago
You're right, it was out of line. Edited, and thanks.
- Stratoscope 8y ago
  Well, thank you for taking criticism so well! We all get a little snippy at times - goodness knows I've done it myself more than I want to admit. I was about to delete my comment since it was no longer relevant, but maybe I will leave it here since your reply and edit are such a great example of how to be constructive and civil. (OTOH, let me know if you'd prefer for me to delete it.) Thanks!

tptacek 8y ago

Help me understand why this matters? Is it really Hipp's argument that Go is unsuitable for serious systems work because invariant signaling in the code is too slow? That seems pretty nitpicky, and also ironic since the "serious" systems language to which he's comparing Go is C.

RHSeeger 8y ago
I would take anything Dr Hipp says very seriously. While he may be wrong, I wouldn't discard his thoughts without some facts to back it up. SQLite, both its functionality and amazing test suite, as well as his other achievements, certainly make him worthy of my respect.
- tptacek 8y ago
  Not to be snarky, but because it's relevant to the discussion: https://www.zdnet.com/article/sqlite-bug-impacts-thousands-of-apps-including-all-chromium-based-browsers/ https://www.zdnet.com/article/sqlite-bug-impacts-thousands-o... This stuff doesn't happen in Go and Rust programs.
  - apta 8y ago
    What does that specifically have to do with golang or Rust?
    - tptacek 8y ago
      Hipp's argument --- which comes kind of out of nowhere in his post --- is that Go is unsuitable as a serious systems language because it lacks compile-time asserts. Which is, I think, ironic, because his language is C, and so produces memory corruption vulnerabilities that languages like Go and Rust preclude. I'd rather have Go's guarantees than C's.
pcwalton 8y ago
Not being able to have code that compiles in debug but doesn't in release is a pretty serious issue for CPU-bound performance-critical code. Otherwise, you're going to be commenting things out a lot or using preprocessors, both of which are annoying and slow down development velocity. As an example, checking errors on GPU is enormously slow because you stall the CPU until the hardware FIFO drains every time you do. You can't ship software that checks for errors after issuing each DirectX or OpenGL call. But writing graphics code is also really annoying without a debug mode that checks for errors after each render command, because the failure mode of graphics programs tends to be "black screen" or "screen full of garbage".

helper 8y ago

In go you can use build tags to achieve this. The compiler will drop function calls to empty function implementations (tested on go 1.11.5).

bbatha 8y ago

It’s not the if staments: for an assertion the panic branch should be ice-cold and likely proven by invariants up the stack frame — other assertions or plain old conditionals — so in theory should be optimized away every time. It’s the expression in the condition that’s often expensive. The assert macro eliminates these trivially with the preprocessor , but go cannot as easily because the condition expression may have side effects.

deleted 8y ago

[deleted]

crawshaw 8y ago

I find the fastest way to introduce bugs into programs is to compile programs differently in development than in production. It also warps developer's perspectives of how their program performs. As they say at NASA, "Test what you fly, fly what you test." That said, you can do this easily enough in Go. Define a package: package debug const Debug = true func Assert(cond bool, msg string) { if Debug && cond { panic(msg) } } Have your build system generate the file that contains Debug = true. In optimization mode, make it Debug = false. As it is const, the compiler will propagate it, Assert will be inlined and the dead code removed. If you don't like relying on the compiler, have your code generator generate empty Assert functions. If you are working in a very bad code base that catches all panics, you'll need an extra 5 lines of code in the implementation of Assert, and your stack traces won't be pretty. (Roughly: put the condition check in a goroutine, block the Assert call on a channel signal from that goroutine.) I'd recommend the first project be to remove those panic catch-alls. But really, all of this is only appropriate when you are far out in the weeds. Ship your program with those asserts. If they are too slow for production they are too slow for development.

kasey_junk 8y ago
That will still evaluate the cond in all cases. Passing a func will make it lazy but might have performance implications (I’d have to test it).
- crawshaw 8y ago
  It won't, because of inlining and dead code removal. (At least, it didn't back around Go 1.11 when I last tested this.)
  - kasey_junk 8y ago
    Maybe if the thing that is generating the cond at the call location is inline-able, but not if it's doing an expensive operation. https://play.golang.org/p/Ts6QqRrWwuQ https://play.golang.org/p/Ts6QqRrWwuQ I couldn't get that to not trigger the lock. [later] I could get it to remove it if you pass in a func instead.