Hacker News Reader

Comment by jjmanton | Hacker News Reader

One interesting benefit I see is the ability to easily parallelize the work. Take a look at the render implementation here - https://github.com/fogleman/pt/blob/master/pt/render.go#L28

View on HN

It was SO easy! The only tricks were GOMAXPROCS and not using the shared rand functions because they are synchronized.

I'm interested in more information about why you decided to alter GOMAXPROCS and what your results were from testing.

I've had a play with this myself and found that it cause sporadic and unpredictable crashing (very different style of application though - I was building a webserver). However this was an earlier iteration of Go (possibly Go 1.1 but likely 1.2) so things may have improved since then, or you might have found a saner way of tweaking it.

When GOMAXPROCS > 1, your program goes from "everything is executed sequentially" to "everything is maybe executed in parallel." This can expose data race bugs in your code that aren't present when GOMAXPROCS = 1.

(I'd suggest using Go's race detector.)

You know, that's entirely possible. I was playing around with different methods of passing data between goroutines for increasing performance and I knew one of the methods I was testing wasn't idiomatic Go. However since I wasn't getting race conditions normally i assumed that the GOMAXPROCS fault wasn't down to my shonky code.

The weird thing is I thought I'd read somewhere that said Go defaulted to a process per CPU core (like the OP has hardcoded ib this project). I'm guessing that isn't the case then? It sadly wouldn't be the first time I've misread something! :(

GOMAXPROCS defaults to 1, meaning unless you change that value, your code will not run in parallel by default.

I have zero experience with rendering but I have never had an issue adjusting GOMAXPROCS for web apps.

Reply on news.ycombinator.com