Live data from Hacker News

The RAM shortage could last years

theverge.com

521–530 of 536 posts

Re: The RAM shortage could last years

#521
post #520
post #519

Earlier quoted context omitted.

> I'm not familiar with this paper… It presents "DaCapo Chopin, a major release of the DaCapo benchmark suite for Java". It's a benchmark suite. It says so. > I'm not talking about what they say they are but about what they actually are “When I use a word,” Humpty Dumpty said in rather a scornful tone, “it means just what I choose it to mean—neither more nor less.” “The question is,” said Alice, “whether you can make…

I don't understand what you're trying to say. I said that the Benchmark Game is not a good benchmark suite in the sense that it does not measure language speed differences since 1. it compares different algorithms, and 2. it doesn't cover some of the most important use-cases that languages/runtimes optimise for [1]. That's all. I'm not saying it's deceitful, I'm saying it's just not good comparison of language speeds…

> it's just not good comparison of language speeds

It's not that the benchmarks game is not a good benchmark suite, it isn't a benchmark suite.

It's not that the benchmarks game is not a good comparison of language speeds, it's that comparison of "language speeds" is so under-specified as-to-be wishful thinking.

> Java was designed to…

"… build software for the next generation of consumer electronics – think smart toasters, interactive TVs, and other futuristic gadgets." Things change.

>… the very things that low-level languages have always been good at…

Which is why there are people who find those kind-of Java programs being in-any-way comparable, somewhat surprising.

Re: The RAM shortage could last years

#522
post #521
post #520

Earlier quoted context omitted.

I don't understand what you're trying to say. I said that the Benchmark Game is not a good benchmark suite in the sense that it does not measure language speed differences since 1. it compares different algorithms, and 2. it doesn't cover some of the most important use-cases that languages/runtimes optimise for [1]. That's all. I'm not saying it's deceitful, I'm saying it's just not good comparison of language speeds…

> it's just not good comparison of language speeds It's not that the benchmarks game is not a good benchmark suite, it isn't a benchmark suite. It's not that the benchmarks game is not a good comparison of language speeds, it's that comparison of "language speeds" is so under-specified as-to-be wishful thinking. > Java was designed to… "… build software for the next generation of consumer electronics – think smart to…

> It's not that the benchmarks game is not a good benchmark suite, it isn't a benchmark suite.

OK, but I was responding to someone who did consider it to be a benchmark suite. As long as we agree it's not a good benchmark suite whatever it considers itself to be, we're in agreement.

> It's not that the benchmarks game is not a good comparison of language speeds, it's that comparison of "language speeds" is so under-specified as-to-be wishful thinking.

With that I completely agree. But if you group results by language, that's exactly what you're inviting, and if your suite of benchmarks or whatever you want to call it covered a wider range of problems, that point could be more easily seen. Let's say that the combination of grouping results by language and covering only a very narrow (and niche) set of problems that also happens to be the sweet spot of some languages that have other significant performance failings in other use cases doesn't exactly help people get the right impression.

Re: The RAM shortage could last years

#523
post #522
post #521

Earlier quoted context omitted.

> it's just not good comparison of language speeds It's not that the benchmarks game is not a good benchmark suite, it isn't a benchmark suite. It's not that the benchmarks game is not a good comparison of language speeds, it's that comparison of "language speeds" is so under-specified as-to-be wishful thinking. > Java was designed to… "… build software for the next generation of consumer electronics – think smart to…

> It's not that the benchmarks game is not a good benchmark suite, it isn't a benchmark suite. OK, but I was responding to someone who did consider it to be a benchmark suite. As long as we agree it's not a good benchmark suite whatever it considers itself to be, we're in agreement. > It's not that the benchmarks game is not a good comparison of language speeds, it's that comparison of "language speeds" is so under-s…

> As long as we agree…

Close enough.

> … help people get the right impression.

The target audience wonder "Which programming language is fastest?"

A table or chart sorted by elapsed time is the answer they expect.

The target audience have various (perhaps un-examined) ideas about the question.

The sources and measurements can be a way to examine and discuss some of those ideas.

Re: The RAM shortage could last years

#524
post #523
post #522

Earlier quoted context omitted.

> It's not that the benchmarks game is not a good benchmark suite, it isn't a benchmark suite. OK, but I was responding to someone who did consider it to be a benchmark suite. As long as we agree it's not a good benchmark suite whatever it considers itself to be, we're in agreement. > It's not that the benchmarks game is not a good comparison of language speeds, it's that comparison of "language speeds" is so under-s…

> As long as we agree… Close enough. > … help people get the right impression. The target audience wonder "Which programming language is fastest?" A table or chart sorted by elapsed time is the answer they expect. The target audience have various (perhaps un-examined) ideas about the question. The sources and measurements can be a way to examine and discuss some of those ideas.

Ok, but if the measurements were wider in scope they could at least offer a more interesting, well-rounded, and perhaps even relevant basis for discussion (even if the other flaws, which are harder to fix, remained).

Re: The RAM shortage could last years

#525
post #524
post #523

Earlier quoted context omitted.

> As long as we agree… Close enough. > … help people get the right impression. The target audience wonder "Which programming language is fastest?" A table or chart sorted by elapsed time is the answer they expect. The target audience have various (perhaps un-examined) ideas about the question. The sources and measurements can be a way to examine and discuss some of those ideas.

Ok, but if the measurements were wider in scope they could at least offer a more interesting, well-rounded, and perhaps even relevant basis for discussion (even if the other flaws, which are harder to fix, remained).

Once upon a time, I might have imagined that would be so. Now it seems more like squeezing a lemon, there's hardly any more after the first squeeze.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: The RAM shortage could last years

#526
post #525
post #524

Earlier quoted context omitted.

Ok, but if the measurements were wider in scope they could at least offer a more interesting, well-rounded, and perhaps even relevant basis for discussion (even if the other flaws, which are harder to fix, remained).

Once upon a time, I might have imagined that would be so. Now it seems more like squeezing a lemon, there's hardly any more after the first squeeze. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

I think you're referring to the less important point I made. Correcting for apples-to-apples is harder and less valuable. Having more domain coverage is easier and more valuable (especially since the current coverage is so narrow and largely irrelevant to most software).

BTW, what we do is compare our suite of micro-benchmarks to our (much smaller) suite of macro-benchmarks. This way we get at least some sense of how relevant the microbenchmarks are (i.e. we're looking at the correlation of the deltas). Some microbenchmarks are more correlated with the macrobenchmarks than others. If an optimisation helps some microbenchmarks that we think are not representative of many programs and doesn't help with any macrobenchmark - we take it out.

Just to give an example, we may want to measure some optimisation that helps some allocation pattern. Sometimes it turns out that if that pattern is diluted by other allocation patterns the program does for other tasks, the advantage is completely erased. Some optimisations in free-list allocators are particularly susceptible to this: if your program allocates only in this specific way, it will be super fast. If, in addition, there are some sporadic allocations that follow a different pattern, then after an hour you'll see performance start to drop.

Re: The RAM shortage could last years

#527
post #508

Earlier quoted context omitted.

> To put it simply, if a program uses a lot of CPU it doesn't make sense for it to use little RAM The fallacy in that reasoning is that a program that's using a lot of CPU (especially if it's a huge MLOC-sized app) is most likely using up its CPU on memory throughput, not pure number-crunching compute! So at least for the enterprise app case (not pure number crunching), you'd actually need a tunable tradeoff between…

> The fallacy in that reasoning is that a program that's using a lot of CPU (especially if it's a huge MLOC-sized app) is most likely using up its CPU on memory throughput, not pure number-crunching compute! No, there's no such fallacy here because that assumption is not needed for the conclusion. The point is that CPU is needed to use RAM, and so if you use CPU for whatever reason - even to loop for an hour over som…

> The whole point of moving collectors is that the can make the cost of memory management arbitrarily low

If it was really true that "we can make the cost arbitrarily low" by simply delaying collection, that would be equivalent in the limit to not using GC at all and resorting to pure bump arena allocation. However as I mentioned, you can't really achieve this for long running programs. The chickens will always come home to roost: eventually the memory limit will be reached and you'll have to pay that collection cost in full. All that speeding up the mutation phase does is make you reach the limit even faster, compared to using heap allocation. Heap allocation may pay a small cost over time in CPU overhead (searching metadata for free memory ranges or taking locks, not doing huge memory copies - very limited impact on the memory subsystem!), but most such programs simply aren't CPU compute limited. That cost is almost free to them. The tradeoff in adding a memory copying/moving workload due to GC, even one that's invoked "rarely", is simply not worthwhile. Properly understood, they are well into the "pay more CPU compute cost in order to save on memory footprint and memory traffic" side of the tradeoff.

I'm not dismissing the theoretical possibility that such cases may exist, but there's an argument that (1) they're surprisingly rare, and (2) even when they do apply, it's inherently unlikely that adopting tracing and moving GC would be a relevant knob, compared to increased use of plain old arenas or domain-specific ways of using more memory (such as caching).

> Except it doesn't given the actual economics of RAM and CPU

These economics have been heavily impacted by the RAMpocalypse. Tradeoffs that may have been valid to some extent back when that YouTube talk was given are no more applicable today.

Re: The RAM shortage could last years

#528
post #526
post #525

Earlier quoted context omitted.

Once upon a time, I might have imagined that would be so. Now it seems more like squeezing a lemon, there's hardly any more after the first squeeze. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

I think you're referring to the less important point I made. Correcting for apples-to-apples is harder and less valuable. Having more domain coverage is easier and more valuable (especially since the current coverage is so narrow and largely irrelevant to most software). BTW, what we do is compare our suite of micro-benchmarks to our (much smaller) suite of macro-benchmarks. This way we get at least some sense of how…

> apples-to-apples

Hopefully, some of the target audience might try to confirm that programs are what they think of as "comparable".

> Having more domain coverage is easier and more valuable…

So where are the examples of that being done? (It's been decades.)

Re: The RAM shortage could last years

#529
post #528
post #526

Earlier quoted context omitted.

I think you're referring to the less important point I made. Correcting for apples-to-apples is harder and less valuable. Having more domain coverage is easier and more valuable (especially since the current coverage is so narrow and largely irrelevant to most software). BTW, what we do is compare our suite of micro-benchmarks to our (much smaller) suite of macro-benchmarks. This way we get at least some sense of how…

> apples-to-apples Hopefully, some of the target audience might try to confirm that programs are what they think of as "comparable". > Having more domain coverage is easier and more valuable… So where are the examples of that being done? (It's been decades.)

> So where are the examples of that being done?

Whenever people want to get valuable information. As I said, we in OpenJDK have a couple hundred benchmarks, some macro, many micro, which are meant to give a decent coverage of the things that affect performance.

If a website wants to group results by languages, it should think about performance from the perspective of how languages work (which include compilers, linkers, and runtimes).

For example, what compiler/linker optimisations are done can depend a lot on whether the program is in a single compilation unit or multiple (and in the case of C and C++ - it does).

On the runtime front, think about memory management. These mechanisms often have different behaviour depending on whether the objects are of similar size or not, whether they're allocated and freed by multiple threads or a single one, and whether the heap is "young" and unfragmented or old and fragmented.

Another area in runtimes is data structures. Are they single-threaded or concurrent, and if concurrent, how do they behave under low and high contention?

Some mechanisms, in all of these levels, have great performance under some conditions and not so great performance in others, and sometimes where they perform great is actually a condition that is encountered less often in real programs.

If you're asking what multi-lingual benchmark suites offer good coverage - I don't know. But that we don't have good information doesn't mean that it's good to offer bad information. Imagine that in American presidential elections there were no national polls and no polls in most states. Would having a poll only in Alabama or only in California offer good insight into who's likely to win? Probably not, because such a poll offers a very partial view of the situation. Is it better than nothing? Maybe, but not by much, because the outcome in Alabama and California is easy to predict without any polls, so it's only helpful in the most extreme cases.

My point is that bad information is bad information, and if people don't understand how different languages behave under different conditions (e.g. that the optimisations the compiler does can differ depending on whether the program is in a single file or not) then they can get the wrong impression. Imagine that someone has no idea about the regional polarisation in the US, and you tell them, well, there are 50 states, but since we don't have polls for all of them, here's the poll for Alabama. Is that information helpful at all?

In any event, any increase in the coverage makes the information a little better, and because the audience may not know whether multiple benchmarks exercise the same or different behaviour in the language, it's the role of the website to pick problems that trigger the different codepaths in the languages' infrastructure. Otherwise, there's the wrong impression of variety, like saying we don't poll only in Alabama but also in Mississippi. Or it's like testing the structure of a bridge by driving a car across it, and then doing it with ten different car models. Testing a bridge does require variety, but the different car models are not what triggers different conditions for the bridge.

Re: The RAM shortage could last years

#530
post #508

Earlier quoted context omitted.

> The fallacy in that reasoning is that a program that's using a lot of CPU (especially if it's a huge MLOC-sized app) is most likely using up its CPU on memory throughput, not pure number-crunching compute! No, there's no such fallacy here because that assumption is not needed for the conclusion. The point is that CPU is needed to use RAM, and so if you use CPU for whatever reason - even to loop for an hour over som…

> The whole point of moving collectors is that the can make the cost of memory management arbitrarily low If it was really true that "we can make the cost arbitrarily low" by simply delaying collection, that would be equivalent in the limit to not using GC at all and resorting to pure bump arena allocation. However as I mentioned, you can't really achieve this for long running programs. The chickens will always come…

> The chickens will always come home to roost: eventually the memory limit will be reached and you'll have to pay that collection cost in full.

This sounds like you don't understand how GCs work. I can't cover all the basics, but the point is that they do constant work at a frequency that is arbitrarily low.

> The tradeoff in adding a memory copying/moving workload due to GC, even one that's invoked "rarely", is simply not worthwhile.

Again, I don't think you know the basics, so this conversation is a bit pointless. No one, and I mean no one, debates that moving collectors offer the best throughput of all general-purpose memory management solutions. There are tradeoffs, but not the ones you mention. You are debating the fundamentals of Memory Management 101.

> These economics have been heavily impacted by the RAMpocalypse.

No, they haven't. You're saying that not because that's something you've looked into, but just because it's something you imagine might be true. It could affect the economics, but for that RAM prices would have to be many, many times higher than they are now.

Post reply on HN