5 ms·

"typical worst-case" So... not worst-case. :) Regardless, very impressive achievement, especially given that they've been able to do it without a JIT or exoti

by gok 10y ago

"typical worst-case" So... not worst-case. :) Regardless, very impressive achievement, especially given that they've been able to do it without a JIT or exotic tricks like Azul.

dpark 10y ago
Of course not. You can't put absolute worst case times on code in practice. Worst case might be that someone managed to load 80PB of RAM on a CPU underclocked to 50 MHz. Or that the OS suspended the process in the middle of GC and was promptly frozen for a week while VMs were migrated across the country in the cup holder of someone's Toyota. Worst case in absolute time always requires ignoring pathological cases.
- taeric 10y ago
  This feels very wrong to me. Qualifying it with some sort of analysis is fine. Just saying "typical" is borderline negligent and is why nobody just uses naive quicksort in production systems where runtime can actually matter.
  - klodolph 10y ago
    What's the alternative? We don't care about worst-case latency in practice, and average case is often ignored as well. We look at 99.9% latency numbers or things like that. Worst-case is for people designing pacemakers or rockets, that's not what we are doing here.
    - kuschku 10y ago
      > that's not what we are doing here. Considering this code will likely be used in IoT, yes, this is what we’re doing here.
      - grogenaut 10y ago
        Pretty sure web enabled cameras are NOT pacemakers NOR rockets... heck they can't even put a different password on each device by printing on a sticker. Nor is my sous vide machine or anything else I've seen as an IoT device. I wouldn't call say my oscilliscope an IoT device even if it can connect to wifi. It's a scientific device with cloud upload.
        kuschku 10y ago
        You do realize pacemakers nowadays have WiFi and Bluetooth and run on the same platform as other IoT devices? There was an interesting talk at the Chaos Communications Congress a few years back.
        grogenaut 10y ago
        I'm well aware of this. I'm also aware that people are hacking these devices left and right. But a cow is a mammal and a mammal isn't a cow. Gp post was not talking about security we're talking about Real time computing. If it's running on IoT hardware, eg rpi running linux, it's likely not doing real time os stuff because linux isn't really a real time os. And I still don't classify pacemakers as IoT. Just because you want to slap a vague acyronym on any and every "connected" embedded device doesn't mean I agree.
        kuschku 10y ago
        But that's the thing, there's now a trial for implanted, smart, insulin pumps, running on node.js, connecting to its app via WiFi. That stuff is IoT in every definition of the word.
        kpil 10y ago
        I know a few software developers that have diabetes, and they seem to be reluctant to automatic pumps. Monitoring might be fine, but installing something in the body that can kill you and then running it on node.js doesn't seem like a good idea.
  - deleted 10y ago
    [deleted]
  - dr_zoidberg 10y ago
    It depends on how it's been determined that it's the "typical worst case" ...maybe an anonymous usage program? ...maybe their typical use case? (which is definitely not everyone elses) ...maybe the typical use case of Google employees using Go for their single-computer tasks? (which would be closer to a "typical user" as in people who read HN) ...an average of those three, or perhaps even more, use cases? wighted in some way? But if done correctly, optimizing the 90% typical problem by 20%, gives you a general 18% improvement, far more than even making disappear the least important 10% of the runtime (which some bad optimization efforts tend to focus on...). Making software faster is always about knowing where to work, and then focusing exactly on that. Nothing wrong in attacking the "typical [anything] case".
  - voidlogic 10y ago
    >Just saying "typical" is borderline negligent Pretty harsh for an informal post on a mailing list, its not like this was a formal proposal or an announcement. Talking about why "typical" lacks meaning is fair, but calling the OP negligent is not.
    - taeric 10y ago
      Completely fair point and one I should have acknowledged. I was not intending to call the OP negligent. From what I saw, they did a full analysis and are preparing the full numbers. I was just irked by this idea that "typical" is all one needs.
- nickpsecurity 10y ago
  Sure you can. It's standard in embedded software. Called WCET analysis. There's also real-time GC's. Go team has simply not done either of these in their design. So, they can't give a worst-time estimate.
  - countingteeth 10y ago
    Indeed. If there's no worst case time, that eliminates use in hard-real-time, certifiable embedded, e.g. aerospace, medical, etc. You can't very well tolerate an "atypical" GC pause when you're firing a laser or radiation pulse, doing engine control, or even updating a display in a flight instrument setting.
kodfodrasz 10y ago
This is what amortized analysis is about.
- countingteeth 10y ago
  You can't amortize in real-time. You don't get a mulligan for missing a deadline because you can do twice as much work in the next frame.
  - lomnakkus 10y ago
    Wait, what? In my, admittedly maybe lacking, understanding amortization doesn't really work that way. "Amortized worst case" (for example) means that you can still bound the worst case[1], but it's just not necessarily going to be a very accurate bound. Obviously, amortized complexity doesn't tell you "<X ms" right off the bat since it deals in abstract "operations", but if you have known worst case bounds for all the "operations", then an amortized bound for a given operation will give you something equivalent to "<X ms". [1] I mean, it's a common proof technique to actually have a non-negative cost function (+ invariant) and postulate/derive an upper bound on that, so... what gives? What's your reasoning here?
    - countingteeth 10y ago
      No. The entire premise of amortized analysis is to get a more optimistic "eventually O" number. "Eventually" is not good enough for real time. Yes you can get a real hard worst-case number, but that's a different analysis from amortized analysis. Unless all of your amortized operations are happening between deadlines, it's useless--worse, dangerous--for safety. And amortized analysis is almost never used that way. You don't have language run-times that reinitialize between every deadline.
      - lomnakkus 10y ago
        You're right. I somehow confused myself by thinking of it in terms of one of the proof techniques for amortized worst case where you derive a fixed upper bound for any "n". Of course this is a much stronger property than needed.
eternalban 10y ago
What does JIT have to do with GC?
- gok 10y ago
  A JIT can do better escape analysis, eliminating allocations. A JIT can also be more clever about safe point insertion. And when a JIT detects that code isn't being called concurrently, it can emit much cheaper read/write barriers.

by gok 10y ago

"typical worst-case" So... not worst-case. :) Regardless, very impressive achievement, especially given that they've been able to do it without a JIT or exotic tricks like Azul.

dpark 10y ago

Of course not. You can't put absolute worst case times on code in practice. Worst case might be that someone managed to load 80PB of RAM on a CPU underclocked to 50 MHz. Or that the OS suspended the process in the middle of GC and was promptly frozen for a week while VMs were migrated across the country in the cup holder of someone's Toyota. Worst case in absolute time always requires ignoring pathological cases.

taeric 10y ago
This feels very wrong to me. Qualifying it with some sort of analysis is fine. Just saying "typical" is borderline negligent and is why nobody just uses naive quicksort in production systems where runtime can actually matter.
- klodolph 10y ago
  What's the alternative? We don't care about worst-case latency in practice, and average case is often ignored as well. We look at 99.9% latency numbers or things like that. Worst-case is for people designing pacemakers or rockets, that's not what we are doing here.
  - kuschku 10y ago
    > that's not what we are doing here. Considering this code will likely be used in IoT, yes, this is what we’re doing here.
    - grogenaut 10y ago
      Pretty sure web enabled cameras are NOT pacemakers NOR rockets... heck they can't even put a different password on each device by printing on a sticker. Nor is my sous vide machine or anything else I've seen as an IoT device. I wouldn't call say my oscilliscope an IoT device even if it can connect to wifi. It's a scientific device with cloud upload.
      - kuschku 10y ago
        You do realize pacemakers nowadays have WiFi and Bluetooth and run on the same platform as other IoT devices? There was an interesting talk at the Chaos Communications Congress a few years back.
        grogenaut 10y ago
        I'm well aware of this. I'm also aware that people are hacking these devices left and right. But a cow is a mammal and a mammal isn't a cow. Gp post was not talking about security we're talking about Real time computing. If it's running on IoT hardware, eg rpi running linux, it's likely not doing real time os stuff because linux isn't really a real time os. And I still don't classify pacemakers as IoT. Just because you want to slap a vague acyronym on any and every "connected" embedded device doesn't mean I agree.
        kuschku 10y ago
        But that's the thing, there's now a trial for implanted, smart, insulin pumps, running on node.js, connecting to its app via WiFi. That stuff is IoT in every definition of the word.
        kpil 10y ago
        I know a few software developers that have diabetes, and they seem to be reluctant to automatic pumps. Monitoring might be fine, but installing something in the body that can kill you and then running it on node.js doesn't seem like a good idea.
- deleted 10y ago
  [deleted]
- dr_zoidberg 10y ago
  It depends on how it's been determined that it's the "typical worst case" ...maybe an anonymous usage program? ...maybe their typical use case? (which is definitely not everyone elses) ...maybe the typical use case of Google employees using Go for their single-computer tasks? (which would be closer to a "typical user" as in people who read HN) ...an average of those three, or perhaps even more, use cases? wighted in some way? But if done correctly, optimizing the 90% typical problem by 20%, gives you a general 18% improvement, far more than even making disappear the least important 10% of the runtime (which some bad optimization efforts tend to focus on...). Making software faster is always about knowing where to work, and then focusing exactly on that. Nothing wrong in attacking the "typical [anything] case".
- voidlogic 10y ago
  >Just saying "typical" is borderline negligent Pretty harsh for an informal post on a mailing list, its not like this was a formal proposal or an announcement. Talking about why "typical" lacks meaning is fair, but calling the OP negligent is not.
  - taeric 10y ago
    Completely fair point and one I should have acknowledged. I was not intending to call the OP negligent. From what I saw, they did a full analysis and are preparing the full numbers. I was just irked by this idea that "typical" is all one needs.
nickpsecurity 10y ago
Sure you can. It's standard in embedded software. Called WCET analysis. There's also real-time GC's. Go team has simply not done either of these in their design. So, they can't give a worst-time estimate.
- countingteeth 10y ago
  Indeed. If there's no worst case time, that eliminates use in hard-real-time, certifiable embedded, e.g. aerospace, medical, etc. You can't very well tolerate an "atypical" GC pause when you're firing a laser or radiation pulse, doing engine control, or even updating a display in a flight instrument setting.

kodfodrasz 10y ago

This is what amortized analysis is about.

countingteeth 10y ago
You can't amortize in real-time. You don't get a mulligan for missing a deadline because you can do twice as much work in the next frame.
- lomnakkus 10y ago
  Wait, what? In my, admittedly maybe lacking, understanding amortization doesn't really work that way. "Amortized worst case" (for example) means that you can still bound the worst case[1], but it's just not necessarily going to be a very accurate bound. Obviously, amortized complexity doesn't tell you "<X ms" right off the bat since it deals in abstract "operations", but if you have known worst case bounds for all the "operations", then an amortized bound for a given operation will give you something equivalent to "<X ms". [1] I mean, it's a common proof technique to actually have a non-negative cost function (+ invariant) and postulate/derive an upper bound on that, so... what gives? What's your reasoning here?
  - countingteeth 10y ago
    No. The entire premise of amortized analysis is to get a more optimistic "eventually O" number. "Eventually" is not good enough for real time. Yes you can get a real hard worst-case number, but that's a different analysis from amortized analysis. Unless all of your amortized operations are happening between deadlines, it's useless--worse, dangerous--for safety. And amortized analysis is almost never used that way. You don't have language run-times that reinitialize between every deadline.
    - lomnakkus 10y ago
      You're right. I somehow confused myself by thinking of it in terms of one of the proof techniques for amortized worst case where you derive a fixed upper bound for any "n". Of course this is a much stronger property than needed.

eternalban 10y ago

What does JIT have to do with GC?

gok 10y ago
A JIT can do better escape analysis, eliminating allocations. A JIT can also be more clever about safe point insertion. And when a JIT detects that code isn't being called concurrently, it can emit much cheaper read/write barriers.