Making a Go program faster with a one-character change • Hacker News Board

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

#91

Post by titzer » Mon, Nov 14, 2022, 7:04 PM UTC

thomascgalvin wrote: post #90

cbsmith wrote: 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 increasingly see the wisdom of languages with implicit reference semantics. I spend most of my time in a JVM language of one flavor or another, and when I was learning Go, the first thing that stuck out at me was, "why would I ever want the compiler to invisibly copy a data structure for me?" I suppose the primary reason is to prevent the callee from modifying the caller's data out from under them; unless you pas…

> When I write code, it's common to have references to immutable classes thrown around with wild abandon, heedless of ownership, threads, or good taste, because the data just can't change. But that's a paradigm that Go simply doesn't support.

You might get a kick out of Virgil. It's easy (and terse!) to define immutable classes and you can have immutable ADTs too. (plus tuples, generics with separate typechecking, etc).

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

#92

Post by oconnor663 » Mon, Nov 14, 2022, 7:07 PM UTC

ok123456 wrote: post #76

ithkuil wrote: post #17

Earlier quoted context omitted.

BTW; I'm using both Go and Rust lately. In Rust you can write a function that returns the pointer of one element of a slice. You can also write a function that returns the pointer to a heap-allocated copy of an element of the slice. The two functions would have different signatures. The compiler would also prevent mutation of the slice as long as there are any references to individual elements of the slice being pass…

>In Rust you can write a function that returns the pointer of one element of a slice. Have fun fighting the borrow checker on that one.

It's not always so bad :) https://play.rust-lang.org/?version=stable&mode=debug&editio...

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

#93

Post by jimsmart » Mon, Nov 14, 2022, 7:09 PM UTC

From the headline alone, I guessed this was to do with pointers/references to values vs values themselves.

Yep, with values that take a lot of memory, it's faster to pass pointers/references around than it is to pass the values around, because it is less bytes to copy.

Of course there is more to such a decision than just performance, because if the code makes changes to the value which are not meant to be persisted, then one wants to be working with a copy of the value, not a pointer to the value. So one should take care if simply switching some code from values to pointers-to-values.

All of these things are things that coders with more experience of languages that use such semantics kinda know already, almost as second nature, since the first day they got caught out by them. But everyone is learning, to various degrees, and we all have to start somewhere (i.e. knowing little to nothing).

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

#94

Post by throwaway894345 » Mon, Nov 14, 2022, 7:10 PM UTC

cbsmith wrote: post #60

throwaway894345 wrote: post #52

Earlier quoted context omitted.

> Yes, in C/C++ heap allocations are proportionately pretty expensive, but I've seen Java programs have just ridiculous amounts of implicit allocations but there really isn't much of a problem. Java programs make "ridiculous amounts of implicit allocations" because allocations are cheap in Java. And they need to be cheap because Java doesn't have value semantics so it leans hard on escape analysis + cheap allocations…

> Java programs make "ridiculous amounts of implicit allocations" because allocations are cheap in Java. And they need to be cheap because Java doesn't have value semantics so it leans hard on escape analysis + cheap allocations. Yes, but that's kind of the point, right? Implicit allocation isn't really a problem because a runtime that optimizes the allocations magically for you is a lot easier to build than a runtim…

> Implicit allocation isn't really a problem because a runtime that optimizes the allocations magically for you is a lot easier to build

As far as I know, Java's (default) runtime gives cheap allocations at the cost of long GC pause times.

> than a runtime that optimizes whether you really need to be copying objects as much as you do

It's not "copying", it's "allocating", and avoiding allocations isn't that much work (and frankly I'm surprised it's such a minor problem that no one has bothered to build an IDE plugin that highlights these allocation points automatically--or at least I haven't heard of such a thing). Anyway, "a runtime that minimizes allocations" is just an escape analyzer and Java has one of these too, and IIRC it's a lot more sophisticated than Go's (but it's also a lot harder to reason about as a consequence).

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

#95

Post by lxe » Mon, Nov 14, 2022, 7:10 PM UTC

This is the kind of stuff that the compiler needs to really understand. If all this de-referencing and referencing magic is at the control of the user, it needs to have meaningful effect on what the code does. Otherwise we might as well just write C.

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

#96

Post by cbsmith » Mon, Nov 14, 2022, 7:12 PM UTC

thomascgalvin wrote: post #90

cbsmith wrote: 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 increasingly see the wisdom of languages with implicit reference semantics. I spend most of my time in a JVM language of one flavor or another, and when I was learning Go, the first thing that stuck out at me was, "why would I ever want the compiler to invisibly copy a data structure for me?" I suppose the primary reason is to prevent the callee from modifying the caller's data out from under them; unless you pas…

> When I write code, it's common to have references to immutable classes thrown around with wild abandon, heedless of ownership, threads, or good taste, because the data just can't change.

If there's anything I wish languages with implicit reference semantics would adopt, it's implicit immutability. I wish Java would be so much nicer with keyword that is half way between "final" and "volatile" that means, "yes, you can actually mutate this" and then make final semantics the default for fields & variables.

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

#97

Post by masklinn » Mon, Nov 14, 2022, 7:16 PM UTC

brundolf wrote: post #83

cbsmith wrote: 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…

Having used C++ relatively little, and a long time ago (and never used Go), I don't think I ever realized that value semantics could be used to implicitly clone heap objects Yeesh

Normally they’re not, that’s really specific to C++ nonsense.

In a normal value-semantics system if you have a pointer you just copy the pointer. Obviously if the langage doesn’t have your back it also means you’ve now fucked up your ownership, but you’re in C so that was to be expected.

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

#98

Post by lanstin » Mon, Nov 14, 2022, 7:17 PM UTC

ithkuil wrote: post #14

lanstin wrote: post #3

That seems like a potential for compiler optimization. It should already know that the rule value is only used one time, as the target of a & and this must be somewhat common in managing return values.

The semantics change. You're now returning a pointer to the actual Rule in the Ruleset, while before you'd be returning a pointer to copy of the Rule. The optimization would only work if you had a way to tell the compiler that some values are constant/immutable.

Oh yeah. Too bad. Just ran the escape to heap analysis on my current project, not looking too promising. Mostly it is allocating structure and saving them in a huge in memory hash.

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

#99

Post by cbsmith » Mon, Nov 14, 2022, 7:18 PM UTC

titzer wrote: post #89

cbsmith wrote: 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 think the main issue in C++ isn't value semantics, it's deep copy semantics. E.g. in a functional language ADTs are immutable and don't have identity. They can be freely copied, or not, passed by reference or by value, but they are never deep copied . Comparison may be deep, but not passing them. That is to say, I think I mostly am agreeing with you. In Java, objects are always passed by reference, never by value,…

In a functional language, you don't have to worry about bits of code mutating your data. ;-) On the flip side, there's a lot of cognitive load that comes with functional languages, so while they do address the problem neatly...

I'd have to take a look at Virgil to appreciate your approach, but I'm always leery of implicit value vs. reference semantics tied to types (aside from the whole array fiasco, easily the ugliest part of Java's type system). So often the particular semantics you want are driven by the context of what you're doing, rather than the what you're doing it with.

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

#100

Post by brundolf » Mon, Nov 14, 2022, 7:19 PM UTC

masklinn wrote: post #97

brundolf wrote: post #83

Earlier quoted context omitted.

Having used C++ relatively little, and a long time ago (and never used Go), I don't think I ever realized that value semantics could be used to implicitly clone heap objects Yeesh

Normally they’re not, that’s really specific to C++ nonsense. In a normal value-semantics system if you have a pointer you just copy the pointer. Obviously if the langage doesn’t have your back it also means you’ve now fucked up your ownership, but you’re in C so that was to be expected.

Yeah, this was my assumption when I read the original comment, so I was confused about what it was saying (I thought it was suggesting you should pass references instead of doing a bitwise-copy most of the time, which is just plausible enough that I believed it for a minute) until I read further down in the thread and realized they meant implicit heap-cloning