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

Tune Code Before Your Garbage Collector

blog.vanillajava.blog

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Tune Code Before Your Garbage Collector

#31

Post by kazinator »

einpoklum wrote: post #29
scj wrote: post #20

Earlier quoted context omitted.

I'd phrase it differently, C++ was a set of power-to-performance trade-offs that were optimal in the 1990s. Time has moved on. More importantly, a typical 1990s C++ dev was likely someone who learned assembly, then C or C++. Meaning they already knew how to control hardware / memory allocation, and C++ was just a new set of abstraction tools. It was a step forward for them. To modern devs, C++ is a step backwards. An…

Actually, C++ was rather poor in the 1990s if you ask me (albeit still very usable). Time has moved on - but so has the language. Its implementation tradeoffs were much better IMNSHO after 2011; but it wasn't there yet. And it still isn't! It has a lot of warts that have to stay for backwards compatibility (which is a design goal); and then, it has annoyances I can't believe are not yet addressed (like - where is my…

C++ has staying power because there was a surge in its use in the 1990s and early 2000s. Some of those people are now senior managers, who approve C++.

Re: Tune Code Before Your Garbage Collector

#32

Post by actionfromafar »

cogman10 wrote: post #21
actionfromafar wrote: post #19

Earlier quoted context omitted.

If I squint, is this a special kind of heap compression?

Not really heap compression or special, it's just reusing a reference to an object already allocated on the heap. Right now, if I do this LocalDate a = LocalDate.of(2020, 1, 1); LocalDate b = LocalDate.of(2020, 1, 1); A and B reference 2 different object allocations on the heap even though they are the same date. a != b. In Java, that can be pretty expensive even for an object as light as a LocalDate. By running the…

Now I understand what Valhalla is (new JVM vesion!), I thought it was some kind of dark joke at first. Thanks for the explanation!

Re: Tune Code Before Your Garbage Collector

#33

Post by throawayonthe »

hinkley wrote: post #26
cogman10 wrote: post #9

Earlier quoted context omitted.

The most surprising allocation pressure I constantly run into is primitive boxing. The JVM does heroics to try and avoid it as much as possible, but when you end up with some primitive boxing in a hotspot the amount of GC pressure that creates can be unreal.

The especially nasty thing about that boxing pressure is that when I still paid attention to the JVM, they had some sort of cache for boxing of numbers under about 128, which meant that if you did tests with toy inputs, identity checks would pass in code that needed an equality check instead, and benchmarks built the same way would see no GC pressure in those call trees but see quite a lot of pressure in production.…

isn't that kinda how python preallocates integers -5 to 256? https://docs.python.org/3/c-api/long.html#c.PyLong_FromLong

Re: Tune Code Before Your Garbage Collector

#34

Post by bigfishrunning »

usrnm wrote: post #23
bigfishrunning wrote: post #7

Earlier quoted context omitted.

[flagged]

You're wrote those words using technology built in C++. Just saying

I'm using words using technology that would be much better built on C or lisp or smalltalk or any number of other languages. C++ is very popular because it was promoted in the right places, but is too abstract for low level tasks and too fiddly and fragile for high level tasks. It's like using a swiss army knife for construction when there's a whole box of better tools for every task.

Re: Tune Code Before Your Garbage Collector

#35

Post by bigfishrunning »

kazinator wrote: post #31
einpoklum wrote: post #29

Earlier quoted context omitted.

Actually, C++ was rather poor in the 1990s if you ask me (albeit still very usable). Time has moved on - but so has the language. Its implementation tradeoffs were much better IMNSHO after 2011; but it wasn't there yet. And it still isn't! It has a lot of warts that have to stay for backwards compatibility (which is a design goal); and then, it has annoyances I can't believe are not yet addressed (like - where is my…

C++ has staying power because there was a surge in its use in the 1990s and early 2000s. Some of those people are now senior managers, who approve C++.

> Some of those people are now senior managers, who never bothered to wonder if better tools exist

Ftfy

Re: Tune Code Before Your Garbage Collector

#36

Post by scj »

einpoklum wrote: post #29
scj wrote: post #20

Earlier quoted context omitted.

I'd phrase it differently, C++ was a set of power-to-performance trade-offs that were optimal in the 1990s. Time has moved on. More importantly, a typical 1990s C++ dev was likely someone who learned assembly, then C or C++. Meaning they already knew how to control hardware / memory allocation, and C++ was just a new set of abstraction tools. It was a step forward for them. To modern devs, C++ is a step backwards. An…

Actually, C++ was rather poor in the 1990s if you ask me (albeit still very usable). Time has moved on - but so has the language. Its implementation tradeoffs were much better IMNSHO after 2011; but it wasn't there yet. And it still isn't! It has a lot of warts that have to stay for backwards compatibility (which is a design goal); and then, it has annoyances I can't believe are not yet addressed (like - where is my…

> "because C is such a small and simple language (and one which, as you suggested, often feels like a bunch of syntactic sugar over PDP-7 assembly)."

I didn't describe such qualities of C in my previous post. At all.

And to be clear, I didn't mean "devs who learned how to program in the 1990s". I meant "devs who were active in the 1990s", which would have mostly been devs who came up in the 1970s and 1980s (where learning BASIC, then assembly was common).

I also made no claim about first languages in my previous statement. I only said there was a likely progression from assembly to C or C++ (for a C++ dev).

My point was, the talent pool in the 1990s would be able to handle the downsides of C++, and the upsides would have been a bonus. Whereas modern devs aren't used to the downsides, thus C++ is a step back for them.

What I should have added is that for devs in the 1990s, there would have been very few large legacy C++ codebases.

Re: Tune Code Before Your Garbage Collector

#37

Post by usrnm »

bigfishrunning wrote: post #34
usrnm wrote: post #23

Earlier quoted context omitted.

You're wrote those words using technology built in C++. Just saying

I'm using words using technology that would be much better built on C or lisp or smalltalk or any number of other languages. C++ is very popular because it was promoted in the right places, but is too abstract for low level tasks and too fiddly and fragile for high level tasks. It's like using a swiss army knife for construction when there's a whole box of better tools for every task.

Are you calling an entire generation of programmers idiots? Do you think they didn't know about C, Smalltalk or Lisp? C++ was the most popular language in the 90s because it was the best tool for a lot of jobs back then, people chose to use it willingly. Arguing that it only got popular because of PR is delusional, it had already gotten popular long before it got any corporation money behind it

Re: Tune Code Before Your Garbage Collector

#38

Post by zaphirplane »

senderista wrote: post #4
hinkley wrote: post #3

It's like caching, in kind but not in type. Once you add it, people will stop trying to be parsimonious with resources and just reach for the cache every time. They'll just lean into it. In a hot minute you will discover you can't turn it off because people have lost their brains and the data flow of the app is through the cache and not through the call tree. If you tune for allocation patterns that are in the code,…

I worked on Java code at AWS for a few years and nobody tried to optimize allocations. Then I changed jobs and started working on a Java MPP database and my first code review was brutal. You were expected to avoid allocations as much as possible (mostly by using the SoA pattern everywhere). At that scale no GC could save you from excessive allocations.

How does SoA help ?

Re: Tune Code Before Your Garbage Collector

#39

Post by bigfishrunning »

usrnm wrote: post #37
bigfishrunning wrote: post #34

Earlier quoted context omitted.

I'm using words using technology that would be much better built on C or lisp or smalltalk or any number of other languages. C++ is very popular because it was promoted in the right places, but is too abstract for low level tasks and too fiddly and fragile for high level tasks. It's like using a swiss army knife for construction when there's a whole box of better tools for every task.

Are you calling an entire generation of programmers idiots? Do you think they didn't know about C, Smalltalk or Lisp? C++ was the most popular language in the 90s because it was the best tool for a lot of jobs back then, people chose to use it willingly. Arguing that it only got popular because of PR is delusional, it had already gotten popular long before it got any corporation money behind it

I was part of that generation. C++ was the language that was taught in schools, and many many people were trying to get programming jobs that paid well, but they didn't really care about programming. They treated a programming language like a spoken language, and it never occurred to them how easy it was to learn another one. Many many corporate shops were C++ (or java) shops that wrote gang-of-four design pattern programs with no room for any creativity or experimentation, and a lot of that software is just designed to the moon and unnecessarily complicated. contrast that with the open source software of the time (which was more likely to be written in C then C++) and you'll see a clear quality difference.

Re: Tune Code Before Your Garbage Collector

#40

Post by drob518 »

cogman10 wrote: post #21
actionfromafar wrote: post #19

Earlier quoted context omitted.

If I squint, is this a special kind of heap compression?

Not really heap compression or special, it's just reusing a reference to an object already allocated on the heap. Right now, if I do this LocalDate a = LocalDate.of(2020, 1, 1); LocalDate b = LocalDate.of(2020, 1, 1); A and B reference 2 different object allocations on the heap even though they are the same date. a != b. In Java, that can be pretty expensive even for an object as light as a LocalDate. By running the…

Right. And this is safe now since Java Time classes are immutable. That’s key. Before, you had to worry about someone modifying the object.
Post reply on HN