4 ms·

>> consumes a lot of computational power—up to 10 percent or more of the total time a CPU spends on an application. I stopped reading there. 10% is nothing. Fo

>> consumes a lot of computational power—up to 10 percent or more of the total time a CPU spends on an application. I stopped reading there. 10% is nothing. For such a useful feature as automatic garbage collection, for the vast majority of applications, I'd gladly give away 50% of the CPU. In terms of ensuring code correctness and robustness, if I had to choose static typing or automatic garbage collection, I'd pick garbage collection every time. It adds a lot of value in terms of development efficiency and code simplicity.

ddebernardy 7y ago
There are times when it counts... https://www.youtube.com/watch?v=JEpsKnWZrJ8 https://www.youtube.com/watch?v=JEpsKnWZrJ8
lemagedurage 7y ago
I can agree with that but also you missed the point of the article by not reading along there.
gmueckl 7y ago
10% is a lot. That's at least a few big cloud data center's worth of servers at this point. I'd gladly give the operators a reason to shut these down and save electricity.
jillesvangurp 7y ago
Worse, it's a tradeoff and not a constant overhead. As many Java based server products show, things are fine if you do things such that you avoid garbage collection. GC is only problematic if you are doing bad things like constantly creating lots of objects, or worse, keeping them around for too long. E.g. Elasticsearch uses a lot of memory mapped files these days instead of heap memory (which they used more heavily in the past). That has done wonders for stop the world garbage collect cycles, which used to be a source of cluster inconsistencies because nodes tend to drop out of the cluster when they stop responding due to garbage collection issues. These days that's much less of an issue. On servers, idling CPUs is the norm. We run our java servers on t2s in amazon. CPU throttling is not a problem for us. Our servers run out of IO before they run out of CPU. Garbage collects are not an issue. The little there is seems to have little or no impact on response times. I'd say the innovation in this space comes from new approaches like e.g. Rust with its borrowing mechanisms or functional programming where due to everything being stateless, there's no need to garbage collect that much. It would be interesting to see other languages with borrowing mechanisms; it doesn't sound like something that can easily be retrofitted to existing ones.
- notacoward 7y ago
  > On servers, idling CPUs is the norm. The competition for "least true statement on HN" is always fierce, but you've just submitted a contender. All the people who have lots of servers work really hard to coalesce workloads and drive up utilization. I know because that's what I do, and it's what everyone around me does. It's why the cloud you use is cost-effective. The machines that are mostly idle are clients, not servers.
  - jillesvangurp 7y ago
    When do you start sending alerts? 10%, 50%, or 90% CPU? For us we like our cheap T2s. We have multiple for redundancy; not for performance reasons. All the places I've been tended to over provision servers to be able to deal with spikes in usage. 90% is typically bad news.
    - notacoward 7y ago
      Whatever your alert threshold is, that still defines a fixed amount of work per machine and thus how many machines you need to satisfy a given workload. If you need 100 machines to stay below your alert threshold, and you make a 1% improvement in efficiency, you now need 99 machines to stay below that same threshold. Whatever it is. For just about any load distribution that's not already problematic (e.g. if all of the load gets concentrated on one machine you're screwed no matter what). I work all day every day on dozens of clusters much bigger than that, and so do a lot of other people. For us, spending half a year to get a 1% improvement is an opportunity big enough to get excited about.
notacoward 7y ago
> for the vast majority of applications, I'd gladly give away 50% of the CPU. Don't you think you're over-generalizing a bit much from your own circumstances? If these issues don't matter to you then you basically don't belong in this conversation. They matter a lot to people who write software that runs on large numbers of servers, with both CPU and memory utilization pushed to the limits. That's a lot of us. If you have a million machines, even a 0.1% improvement on either axis is huge. That's racks upon racks worth of equipment that doesn't need to be installed, powered, or maintained. If I could save 10% of 10% ("nothing" according to you) across such a large fleet, I'd be a hero and I'd be rewarded accordingly.
- glenneroo 7y ago
  Don't forget game development, especially users of the Unity game engine, where their "aggressive" GC has often been the bane of projects such as Kerbal Space Program. I have been struggling lately with my own Unity GC issues, where it's running the GC every frame, subsequently dropping my FPS from the 90 I need for VR down to 50 every few frames. Even the new experimental GC they have implemented seems to have no effect.
  - p_l 7y ago
    Would probably help if they had constant-time GC available, where you bind mutator ("application code") and collector (GC) to specific quanta of time to run, thus providing reliable timings. The question is whether it would be fast enough.

ddebernardy 7y ago

There are times when it counts... https://www.youtube.com/watch?v=JEpsKnWZrJ8 https://www.youtube.com/watch?v=JEpsKnWZrJ8

lemagedurage 7y ago

I can agree with that but also you missed the point of the article by not reading along there.

gmueckl 7y ago

10% is a lot. That's at least a few big cloud data center's worth of servers at this point. I'd gladly give the operators a reason to shut these down and save electricity.

jillesvangurp 7y ago

Worse, it's a tradeoff and not a constant overhead. As many Java based server products show, things are fine if you do things such that you avoid garbage collection. GC is only problematic if you are doing bad things like constantly creating lots of objects, or worse, keeping them around for too long. E.g. Elasticsearch uses a lot of memory mapped files these days instead of heap memory (which they used more heavily in the past). That has done wonders for stop the world garbage collect cycles, which used to be a source of cluster inconsistencies because nodes tend to drop out of the cluster when they stop responding due to garbage collection issues. These days that's much less of an issue. On servers, idling CPUs is the norm. We run our java servers on t2s in amazon. CPU throttling is not a problem for us. Our servers run out of IO before they run out of CPU. Garbage collects are not an issue. The little there is seems to have little or no impact on response times. I'd say the innovation in this space comes from new approaches like e.g. Rust with its borrowing mechanisms or functional programming where due to everything being stateless, there's no need to garbage collect that much. It would be interesting to see other languages with borrowing mechanisms; it doesn't sound like something that can easily be retrofitted to existing ones.

notacoward 7y ago
> On servers, idling CPUs is the norm. The competition for "least true statement on HN" is always fierce, but you've just submitted a contender. All the people who have lots of servers work really hard to coalesce workloads and drive up utilization. I know because that's what I do, and it's what everyone around me does. It's why the cloud you use is cost-effective. The machines that are mostly idle are clients, not servers.
- jillesvangurp 7y ago
  When do you start sending alerts? 10%, 50%, or 90% CPU? For us we like our cheap T2s. We have multiple for redundancy; not for performance reasons. All the places I've been tended to over provision servers to be able to deal with spikes in usage. 90% is typically bad news.
  - notacoward 7y ago
    Whatever your alert threshold is, that still defines a fixed amount of work per machine and thus how many machines you need to satisfy a given workload. If you need 100 machines to stay below your alert threshold, and you make a 1% improvement in efficiency, you now need 99 machines to stay below that same threshold. Whatever it is. For just about any load distribution that's not already problematic (e.g. if all of the load gets concentrated on one machine you're screwed no matter what). I work all day every day on dozens of clusters much bigger than that, and so do a lot of other people. For us, spending half a year to get a 1% improvement is an opportunity big enough to get excited about.

notacoward 7y ago

> for the vast majority of applications, I'd gladly give away 50% of the CPU. Don't you think you're over-generalizing a bit much from your own circumstances? If these issues don't matter to you then you basically don't belong in this conversation. They matter a lot to people who write software that runs on large numbers of servers, with both CPU and memory utilization pushed to the limits. That's a lot of us. If you have a million machines, even a 0.1% improvement on either axis is huge. That's racks upon racks worth of equipment that doesn't need to be installed, powered, or maintained. If I could save 10% of 10% ("nothing" according to you) across such a large fleet, I'd be a hero and I'd be rewarded accordingly.

glenneroo 7y ago
Don't forget game development, especially users of the Unity game engine, where their "aggressive" GC has often been the bane of projects such as Kerbal Space Program. I have been struggling lately with my own Unity GC issues, where it's running the GC every frame, subsequently dropping my FPS from the 90 I need for VR down to 50 every few frames. Even the new experimental GC they have implemented seems to have no effect.
- p_l 7y ago
  Would probably help if they had constant-time GC available, where you bind mutator ("application code") and collector (GC) to specific quanta of time to run, thus providing reliable timings. The question is whether it would be fast enough.