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

Golang's big miss on memory arenas

avittig.medium.com

Post reply on HN
Print view View original

131–140 of 157 posts

Re: Golang's big miss on memory arenas

#131

Post by cafxx »

ncruces wrote: post #125
cafxx wrote: post #87

Earlier quoted context omitted.

> If you really want an arena like behavior you could allocate a byte slice and use unsafe to cast it to literally any type. A word of caution. If you do this and then you store pointers into that slice, the GC will likely not see them (as if you were just storing them as `uintptr`s)

You need to ensure that everything you put in the arena only references stuff in the same arena. No out pointers. If you can do that, you're fine.

I still would be wary, even in that case. Go does not guarantee that the address of an allocation won't change over the lifetime of the allocation (although current implementations do not make use of this).

If you really store just references to the same arena, better to use an offset from the start of the arena. Then it does not matter whether allocations are moved around.

Re: Golang's big miss on memory arenas

#132

Post by sheepscreek »

9rx wrote: post #85
sheepscreek wrote: post #80

Earlier quoted context omitted.

I personally loved using Go 8 years ago. When I built a proof of concept for a new project in both Go and Rust, it became clear that Rust would provide the semantics I’m looking for out of the box. Less fighting with the garbage collector or rolling out my own memory management solution. If I’m doing that with a lot of ugly code - I might as well use idiomatic Zig with arenas. This is exactly the point the author tri…

> Go just isn’t the tool we thought for some jobs Go made it explicitly clear when it was released that it was designed to be a language that felt dynamically-typed, but with performance closer to statically-typed languages, for only the particular niche of developing network servers. Which job that needs to be a network server, where a dynamically-typed language is a appropriate, does Go fall short on? One thing tha…

> Which job that needs to be a network server, where a dynamically-typed language is a appropriate, does Go fall short on?

A job where nanosecond routing decisions need to be made.

Re: Golang's big miss on memory arenas

#133

Post by 9rx »

sheepscreek wrote: post #132
9rx wrote: post #85

Earlier quoted context omitted.

> Go just isn’t the tool we thought for some jobs Go made it explicitly clear when it was released that it was designed to be a language that felt dynamically-typed, but with performance closer to statically-typed languages, for only the particular niche of developing network servers. Which job that needs to be a network server, where a dynamically-typed language is a appropriate, does Go fall short on? One thing tha…

> Which job that needs to be a network server, where a dynamically-typed language is a appropriate, does Go fall short on? A job where nanosecond routing decisions need to be made.

Which dynamically-typed language would you select for that?

Re: Golang's big miss on memory arenas

#134

Post by yxhuvud »

> When your software team needs to pick a language today, you typically weigh two factors: language performance and developer velocity.

There are obviously other factors in play as well, or languages that are really good at both but weak in other areas (like adoption and mind share) would dominate. And I for sure don't see a lot of Crystal around..

Re: Golang's big miss on memory arenas

#135

Post by sheepscreek »

wolvesechoes wrote: post #106
sheepscreek wrote: post #80

Earlier quoted context omitted.

I personally loved using Go 8 years ago. When I built a proof of concept for a new project in both Go and Rust, it became clear that Rust would provide the semantics I’m looking for out of the box. Less fighting with the garbage collector or rolling out my own memory management solution. If I’m doing that with a lot of ugly code - I might as well use idiomatic Zig with arenas. This is exactly the point the author tri…

> Or a third option can be to write your hot loops in one such language; and continue using Go for everything else. Problem solved. Or use Go and write ugly code for those hot loops instead of introducing another language and build system. Then you can still enjoy nicety of GC in other parts of your code.

I can see that being an option in a small team that works closely with one another and wants to keep things simple.

Though it is my personal opinion that forcing a GC-based language to do a task best suited for manual memory management is like swimming against the tide. It’s doable but more challenging than it ought to be. I might even appreciate the challenge but the next person maintaining the code might not.

Re: Golang's big miss on memory arenas

#136

Post by pjmlp »

cafxx wrote: post #130
pjmlp wrote: post #111

Earlier quoted context omitted.

That one is kind of interesting given the past criticism of Java and .NET having too many GCs and knobs. With time Go is also getting knobs, and turns out various GC algorithms are actually useful.

Not sure what you are referring to. There are no knobs involved in the things I mentioned (aside from the one to enable the experiment, but that's just temporary until the experiment completes - one way or the other).

The knobs are the values that can be given to GOGC environment variable.

Also I kind of foresee they will discover there are reasons why multiple GC algorithms are desired, and used in other programming ecosystems, thus the older one might stay anyway.

Re: Golang's big miss on memory arenas

#137

Post by pjmlp »

9rx wrote: post #128
pjmlp wrote: post #127

Earlier quoted context omitted.

Except the Go's implementation is not as capable as Java's one. Phil Walder delivered a design within Go's team goals. Java team has told nothing to Go's team, they have acknowldeged their bias anti-generics. ". They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been wel…

> Except the Go's implementation is not as capable as Java's one. I have no idea what you think is on the other side of that exception. Please clarify.

Have a read https://dev.to/leapcell/why-gos-generics-might-be-worse-than...

Re: Golang's big miss on memory arenas

#138

Post by jshen »

9rx wrote: post #85
sheepscreek wrote: post #80

Earlier quoted context omitted.

I personally loved using Go 8 years ago. When I built a proof of concept for a new project in both Go and Rust, it became clear that Rust would provide the semantics I’m looking for out of the box. Less fighting with the garbage collector or rolling out my own memory management solution. If I’m doing that with a lot of ugly code - I might as well use idiomatic Zig with arenas. This is exactly the point the author tri…

> Go just isn’t the tool we thought for some jobs Go made it explicitly clear when it was released that it was designed to be a language that felt dynamically-typed, but with performance closer to statically-typed languages, for only the particular niche of developing network servers. Which job that needs to be a network server, where a dynamically-typed language is a appropriate, does Go fall short on? One thing tha…

Which dynamically typed languages perform like a statically typed language?

Re: Golang's big miss on memory arenas

#139

Post by bborud »

clappski wrote: post #120
bborud wrote: post #118

If Go refuses to add complexity to gain performance and cannot engineer its way around the GC, it effectively resigns from the pursuit of the high-performance tier. I'm completely okay with that. In fact I much prefer it. Writing high performance code is expensive in any language. Expensive in terms of development time, maintenance cost, and risk. It doesn't really matter what language we are talking about. The langu…

I like the priorities. I think a core thing that's missing is that code that performs well is (IME) also the simplest version of the thing. By that, I mean you'll be; - Avoiding virtual/dynamic dispatch - Moving what you can up to compile time - Setting limits on sizing (e.g. if you know that you only need to handle N requests, you can allocate the right size at start up rather than dynamically sizing) Realistically…

I generally don't worry too much about static vs dynamic dispatch. Not that I use a lot of interfaces all over the place, but there are certain places where I do (for instance persistence layer abstraction - where it doesn't actually matter since any overhead caused by that is many orders of magnitude smaller than the cost of what the call does anyway)

Also, if someone can understand the code, they can optimize it if needed. So in a way, trying to express oneself clearly and simply can be a way to help optimization later.

Re: Golang's big miss on memory arenas

#140

Post by 9rx »

pjmlp wrote: post #137
9rx wrote: post #128

Earlier quoted context omitted.

> Except the Go's implementation is not as capable as Java's one. I have no idea what you think is on the other side of that exception. Please clarify.

Have a read https://dev.to/leapcell/why-gos-generics-might-be-worse-than...

No need to outsource words. If I wanted to converse with Leapcell, I'd go to him directly.

Especially when it doesn't even begin to address the concern. The disconnect is not in where Go generics are limited, but where you find the exception. There is nothing that I can find to "except against". What was "Except" in reference to?

Post reply on HN