Live data from Hacker News

Making a Go program faster with a one-character change

hmarr.com

31–40 of 249 posts

Re: Making a Go program faster with a one-character change

#31
post #11
post #6

Went from 4.139s to 2.413s. I fail to see how it is 70%. I think it is explained as 4.139/2.413 = 1.7 which of course doesn't make sense here.

Doh! Thanks for pointing out another silly mistake – I'll fix that.

You had it right the first time, 1.7x speed is 70% faster.

If something previously took 4s now takes 2s then it's 100% faster.

Think of driving 10miles. If you drive at 20mph then it takes 30 minutes. If you drive twice as fast, 40mph, it takes 15 minutes.

40mph is 100% faster than 20mph.

Half the time is twice as fast!

Re: Making a Go program faster with a one-character change

#32
post #8
post #6

Went from 4.139s to 2.413s. I fail to see how it is 70%. I think it is explained as 4.139/2.413 = 1.7 which of course doesn't make sense here.

It would probably be more accurate to say it can do 70% more stuff in the same time. Or that it takes 42% less runtime

But 70% more stuff in the same time is 70% faster.

Re: Making a Go program faster with a one-character change

#33
post #21

As an old C/C++ programmer, I'm always surprised by how often software developers are surprised by the performance costs of inopportune value semantics (C and C++ even more so, punishes you severely for using value semantics when you shouldn't). I increasingly see the wisdom of languages with implicit reference semantics. It's not that value semantics can't be better (they most assuredly can be), or that reference se…

I also have a background in C/C++, etc and I've only ever found myself missing value semantics when I use languages with implicit reference semantics. I guess I always figured the solution was "value semantics with better education / tooling". Education: people should understand value semantics. Tooling: imagine an IDE that highlights allocation points automatically (or perhaps the problem is implicit allocations rat…

> I've only ever found myself missing value semantics when I use languages with implicit reference semantics.

Oh, I miss it every time. ;-)

I will say though that some newer languages seem to have a confused idea about how to offer mixed semantics. A bunch of them tie semantics to types. The ideal interface can vary by usage context. It's hard enough getting the semantics right as the callee (as opposed to caller), let alone when you're defining a type that will be used by who knows how many interfaces.

> I guess I always figured the solution was "value semantics with better education / tooling".

I've always thought much the same, but I have slowly come to appreciate that it's more than just education & tooling. Even with good education & tooling, there's a cognitive load that comes with getting interfaces right that for the general case is just not worth it.

Re: Making a Go program faster with a one-character change

#35
> I did consider two other approaches:

  Changing Ruleset from being []Rule to []*Rule, which would mean we no longer need to explicitly take a reference to the rule.
  Returning a Rule rather than a *Rule. This would still copy the Rule, but it should stay on the stack instead of moving to the heap.
> However, both of these would have resulted in a breaking change as this method is part of the public API.

The problem with heap allocated objects could be due to the incorrect public API.

The change that improves performance also gives out pointers to the actual elements of Ruleset itself permitting the caller to change the contents of Ruleset which wasn't possible before the speed-up. Perhaps you're already aware since change to []*Rule was being considered.

Re: Making a Go program faster with a one-character change

#36

> You can see these decisions being made by passing -gcflags=-m to go build: That's a very nice feature! I wonder if compilers for other languages have something similar.

In Java

    -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining
and

    -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation
The generated logs can be seen with JITWatch [1].

[1] https://github.com/AdoptOpenJDK/jitwatch

Re: Making a Go program faster with a one-character change

#37
post #11
post #6

Went from 4.139s to 2.413s. I fail to see how it is 70%. I think it is explained as 4.139/2.413 = 1.7 which of course doesn't make sense here.

Doh! Thanks for pointing out another silly mistake – I'll fix that.

I disagree, I think the 70% is right, and matches what you still describe as a 1.7x speed increase. If it originally took 4 seconds and now takes 2, I'd call that a 100% speed increase, i.e. twice as fast.

Re: Making a Go program faster with a one-character change

#38
post #11

Earlier quoted context omitted.

Doh! Thanks for pointing out another silly mistake – I'll fix that.

You had it right the first time, 1.7x speed is 70% faster. If something previously took 4s now takes 2s then it's 100% faster. Think of driving 10miles. If you drive at 20mph then it takes 30 minutes. If you drive twice as fast, 40mph, it takes 15 minutes. 40mph is 100% faster than 20mph. Half the time is twice as fast!

[deleted]

Re: Making a Go program faster with a one-character change

#40
post #11

Earlier quoted context omitted.

Doh! Thanks for pointing out another silly mistake – I'll fix that.

You had it right the first time, 1.7x speed is 70% faster. If something previously took 4s now takes 2s then it's 100% faster. Think of driving 10miles. If you drive at 20mph then it takes 30 minutes. If you drive twice as fast, 40mph, it takes 15 minutes. 40mph is 100% faster than 20mph. Half the time is twice as fast!

Glad it wasn't just me thinking this!
Post reply on HN