Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go has added Valgrind support

go-review.googlesource.com

Post reply on HN
Print view View original

121–130 of 157 posts

Re: Go has added Valgrind support

#121

Post by pstuart »

fragmede wrote: post #65
pjmlp wrote: post #48

Earlier quoted context omitted.

It would be another scenario to use as ammunition for "see you can't implement a language toolchain without using C" , usually voiced by folks without background in compiler design, and understanding that most of the time that is a decision that spurs out of convenience and nothing else. Assembly isn't that hard, those of us that grown around 8 bit home computers were writing Z80 and 6502 Assembly aged 10 - 12 years…

Z80 on the TI-80 series of calculators for me. The Internet was very young, but there was ticalc.org. Damn, it's still around. I wonder if can log in?

Z80 and 6502 for me, pre internet, which was a luxury of sorts I wish we all could go back to now and then.

Re: Go has added Valgrind support

#122

Post by pstuart »

chrsig wrote: post #91

I'm glad to see rsc still actively involved. And commenting on commit messages. The older I get the more I value commit messages. It's too easy to just leave a message like "adding valgrind support", which isn't very useful to future readers doing archaeology.

rsc is a rock star! I believe his focus now is on using AI to manage issues and PRs and such -- I'm sure it will bear copious fruit.

Re: Go has added Valgrind support

#123

Post by wavemode »

9rx wrote: post #113
wavemode wrote: post #112

Earlier quoted context omitted.

I don't think this is correct. Go is a language with structs, arrays, value semantics and pointers, and an `unsafe` package for performing low-level operations on those pointers and deal directly with the layout of memory. And in practice Go and Rust have found use in a lot of the exact same systems programming and network programming domains, as replacement languages for C. Go is certainly a higher-level language th…

> Go is a language with structs, arrays Just like Ruby. Just like pretty much every language people actually use. > value semantics and pointers Value semantics are one of the tricks it uses to satisfy the "but faster" part. It is decidedly its own language. But it only supports value semantics, so this is more like Ruby, which only supports reference semantics. Rust supports both value and reference semantics, so it…

[flagged]

Re: Go has added Valgrind support

#124

Post by acidx »

1718627440 wrote: post #119
DishyDev wrote: post #70

Very cool. Should flush out a few bugs. I'd be interested to know why Valgrind vs the Clang AddressSanitizer and MemorySaniziter. These normally find more types of errors (like use-after-return) and I find it significantly faster than Valgrind.

Valgrind is way faster and can be attached to a running program.

Programs running under any Valgrind tool will be executed using a CPU emulator, making it quite a bit slower than, say, running the instrumented binaries as required by sanitizers; it's often an order of magnitude slower, but could be very well be close to two orders of magnitude slower in some cases. This also means that it just can't be attached to any running program, because, well, it's emulating a whole CPU to track everything it can.

(Valgrind using a CPU emulator allows for a lot of interesting things, such as also emulating cache behavior and whatnot; it may be slow and have other drawbacks -- it has to be updated every time the instruction set adds a new instruction for instance -- but it's able to do things that aren't usually possible otherwise precisely because it has a CPU emulator!)

Re: Go has added Valgrind support

#125

Post by 9rx »

wavemode wrote: post #123
9rx wrote: post #113

Earlier quoted context omitted.

> Go is a language with structs, arrays Just like Ruby. Just like pretty much every language people actually use. > value semantics and pointers Value semantics are one of the tricks it uses to satisfy the "but faster" part. It is decidedly its own language. But it only supports value semantics, so this is more like Ruby, which only supports reference semantics. Rust supports both value and reference semantics, so it…

[flagged]

[flagged]

Re: Go has added Valgrind support

#126

Post by thwarted »

on_the_beach wrote: post #114
bracewel wrote: post #71

Author of the linked CL here: we added this mostly so that we could abuse the memory initialization tracking to test the constant-time-ness of crypto code (similar to what BoringSSL does, proposed by agl around fifteen years ago: https://www.imperialviolet.org/2010/04/01/ctgrind.html ), which is an annoyingly hard property to test. We're hoping that there are also a bunch of other interesting side-effects of enabling…

This is super cool. Hopefully it will flush out other issues in Go too. But I wonder why its not trivial to throw a bunch of different inputs at your cyphering functions and measure that the execution times are all within an epsilon tolerance? I mean, you want to show constant time of your crypto functions, why not just directly measure the time under lots of inputs? (and maybe background Garbage Collection and OS no…

Because "constant time" here means algorithms that are O(1), rather than O(n). This isn't about wall-clock execution time, it's about avoiding the number of operations performed being based on attributes of the input.

Re: Go has added Valgrind support

#128

Post by hedora »

ben-schaaf wrote: post #72
stingraycharles wrote: post #53

Earlier quoted context omitted.

Somewhat yes, but as soon as you enter the world of multi-threading (which Go does a lot), the abstraction doesn’t work anymore: as I understand it (or rather, understood: last time I really spent a lot of time digging into it with C++ code was a while ago) it uses its own scheduler, and as such, a lot of subtle real world issues that would arise due to concurrency / race conditions / etc do not pop up in valgrind. A…

IME Helgrind does an great job finding concurrency issues.

tsan from LLVM works a bit better in my experience. I still like valgrind in general though!

Re: Go has added Valgrind support

#129

Post by CJefferson »

on_the_beach wrote: post #114
bracewel wrote: post #71

Author of the linked CL here: we added this mostly so that we could abuse the memory initialization tracking to test the constant-time-ness of crypto code (similar to what BoringSSL does, proposed by agl around fifteen years ago: https://www.imperialviolet.org/2010/04/01/ctgrind.html ), which is an annoyingly hard property to test. We're hoping that there are also a bunch of other interesting side-effects of enabling…

This is super cool. Hopefully it will flush out other issues in Go too. But I wonder why its not trivial to throw a bunch of different inputs at your cyphering functions and measure that the execution times are all within an epsilon tolerance? I mean, you want to show constant time of your crypto functions, why not just directly measure the time under lots of inputs? (and maybe background Garbage Collection and OS no…

For the best crypto, you don’t want “within an epsilon”, you want “exactly the same number of CPU cycles”, because any difference can be measured with enough work.

Re: Go has added Valgrind support

#130

Post by hu3 »

JyB wrote: post #83
tasn wrote: post #74

This feels more like a failure than a win. Don't get me wrong, I love Valgrind, and have been using it extensively in my past life as a C developer. Though the fact that Go needs Valgrind feels like a failure of the language or the ecosystem. I've been doing Rust for ~6 years now, and haven't had to reach for Valgrind even once (I think a team member may have use it once). I realize that's probably because of cgo, an…

I never understand why there's always one of the top comment on every Go post being derogatory and mentioning Rust. It never fails. It starts to feel like a weird mix of defensiveness and superiority complex.

Rust is, in my opinion, overrepresented by a vocal minority in HN. A vocal corpus that tend to be passive aggressive more often than other language communities, in my experience.

Which is sad because I like the language and find it useful. But a part of the community does a disservice with comments like your parent comment. It's often on the cusp of calling people who code in Go "stupid". But I digress.

Post reply on HN