4 ms·

Just because you haven't been exposed this issue doesn't mean it doesn't exist. "the real situation", "no one", "in real projects", "never pop up"...give me a b

Just because you haven't been exposed this issue doesn't mean it doesn't exist. "the real situation", "no one", "in real projects", "never pop up"...give me a break lol.

kaba0 4y ago
One can reasonably well guess/know the expected input sizes to their programs. You ain’t (hopefully) loading your whole database into memory, and unless you are writing a simulation/game engine or another specialized application, your application is unlikely to have a single scorching hot loop, that’s just not how most programs look like. If it is, then you should design for it, which may even mean changing programming languages for that part (e.g. for video codecs not even C et al. cut it, you have to do assembly), but more likely you just use a bit less ergonomic primitive of your language.
- duskwuff 4y ago
  > e.g. for video codecs not even C et al. cut it, you have to do assembly This is largely inaccurate. Video encoders/decoders are typically written in C, with some use of compiler intrinsics or short inline assembly fragments for particularly "hot" functions.
  - kaba0 4y ago
    I was talking about those hot functions only, not the rest of the program. But yeah a “sometimes” or a “may” would have helped in my original sentence.
  - Cthulhu_ 4y ago
    Exactly, and they only decided to write those bits in assembly when they identified it as a hot code path AND the assembly outperformed any C code they could come up with. The times that assembly outperforms a higher level language has reduced as well over time, with compiler and CPU improvements over time.
    - kaba0 4y ago
      Which is not in disagreement with my comment/take.
- bob1029 4y ago
  > unless you are writing a simulation/game engine or another specialized application, your application is unlikely to have a single scorching hot loop If everything was built with constraints like "this must serve user input so quickly that they can't perceive a delay", we would probably be a lot better off across the entire board. We should try to steal more ideas from different domains instead of treating them like entirely isolated universes.
  - tyre 4y ago
    > If everything was built with constraints like "this must serve user input so quickly that they can't perceive a delay", we would probably be a lot better off across the entire board. Sure but it’s a question of tradeoffs. If the wall-clock-optimized version creates a bus count of 1 for that domain or is difficult for a dozen engineers to iterate on, then that could be worse for the business and users. Should we want better software? Yes. Should we learn from other domains? Absolutely. But we should ultimately optimize for the domain we’re in, and writing much product-focused software is ultimately best optimized for engineering team and product velocity. Another example: would most software benefit from formal verification? Yeah, I guess, but the software holistically—as a thing used by humans to solve problems—might benefit considerably more from Ruby.
    - Olreich 4y ago
      Product velocity is not increased by spending a ton of time on complex type hierarchies and premature extensibility. It’s increased by having fewer classes and simpler functions that are faster to write tests for to get good coverage via end-to-end tests. The patterns of OOP increase the amount of time spent not solving the business needs. They also infuse the entire system with unnecessary slowness.
- morelisp 4y ago
  > You ain’t (hopefully) loading your whole database into memory I've basically built my career for the past decade by pointing out "yes, we can load our whole working set into memory" for the vast majority of problems. This is especially true if you have so little data you think you don't have CPU problems either.
  - kaba0 4y ago
    Databases are often not used by a single entity, so while I am very interested in your experiences, I think it is a great specialization for certain problems, but is not a general solution to everything. All in all, I fail to see how it disagrees with my points.
    - l33t233372 4y ago
      > All in all, I fail to see how it disagrees with my points. I didn’t see any part of the comment that implied it did
      - deleted 4y ago
        [deleted]
- _aavaa_ 4y ago
  But the point isn't that just the scorching hot loop is 20x slower, but that this penalty is paid everywhere. And it won't show up in profiling since there isn't a hotspot, it's death by 100 cuts.
mmarq 4y ago
His classes are doing a single multiplication, of course dynamic dispatch would have a significant cost in this scenario.
- Olreich 4y ago
  Never look at the dispatch of a big company’s Java code base then. It’s dynamic dispatch 400 layers deep for a single network call or file op or small amount of math. Sure those are more expensive operations, but the dynamic dispatch has continually out scaled the problem.
  - mmarq 4y ago
    But the company that uses Java quite often is writing the umpteenth line-of-business application, where dynamic dispatch is not going to cause a massive overhead

Just because you haven't been exposed this issue doesn't mean it doesn't exist. "the real situation", "no one", "in real projects", "never pop up"...give me a break lol.

kaba0 4y ago

One can reasonably well guess/know the expected input sizes to their programs. You ain’t (hopefully) loading your whole database into memory, and unless you are writing a simulation/game engine or another specialized application, your application is unlikely to have a single scorching hot loop, that’s just not how most programs look like. If it is, then you should design for it, which may even mean changing programming languages for that part (e.g. for video codecs not even C et al. cut it, you have to do assembly), but more likely you just use a bit less ergonomic primitive of your language.

duskwuff 4y ago
> e.g. for video codecs not even C et al. cut it, you have to do assembly This is largely inaccurate. Video encoders/decoders are typically written in C, with some use of compiler intrinsics or short inline assembly fragments for particularly "hot" functions.
- kaba0 4y ago
  I was talking about those hot functions only, not the rest of the program. But yeah a “sometimes” or a “may” would have helped in my original sentence.
- Cthulhu_ 4y ago
  Exactly, and they only decided to write those bits in assembly when they identified it as a hot code path AND the assembly outperformed any C code they could come up with. The times that assembly outperforms a higher level language has reduced as well over time, with compiler and CPU improvements over time.
  - kaba0 4y ago
    Which is not in disagreement with my comment/take.
bob1029 4y ago
> unless you are writing a simulation/game engine or another specialized application, your application is unlikely to have a single scorching hot loop If everything was built with constraints like "this must serve user input so quickly that they can't perceive a delay", we would probably be a lot better off across the entire board. We should try to steal more ideas from different domains instead of treating them like entirely isolated universes.
- tyre 4y ago
  > If everything was built with constraints like "this must serve user input so quickly that they can't perceive a delay", we would probably be a lot better off across the entire board. Sure but it’s a question of tradeoffs. If the wall-clock-optimized version creates a bus count of 1 for that domain or is difficult for a dozen engineers to iterate on, then that could be worse for the business and users. Should we want better software? Yes. Should we learn from other domains? Absolutely. But we should ultimately optimize for the domain we’re in, and writing much product-focused software is ultimately best optimized for engineering team and product velocity. Another example: would most software benefit from formal verification? Yeah, I guess, but the software holistically—as a thing used by humans to solve problems—might benefit considerably more from Ruby.
  - Olreich 4y ago
    Product velocity is not increased by spending a ton of time on complex type hierarchies and premature extensibility. It’s increased by having fewer classes and simpler functions that are faster to write tests for to get good coverage via end-to-end tests. The patterns of OOP increase the amount of time spent not solving the business needs. They also infuse the entire system with unnecessary slowness.
morelisp 4y ago
> You ain’t (hopefully) loading your whole database into memory I've basically built my career for the past decade by pointing out "yes, we can load our whole working set into memory" for the vast majority of problems. This is especially true if you have so little data you think you don't have CPU problems either.
- kaba0 4y ago
  Databases are often not used by a single entity, so while I am very interested in your experiences, I think it is a great specialization for certain problems, but is not a general solution to everything. All in all, I fail to see how it disagrees with my points.
  - l33t233372 4y ago
    > All in all, I fail to see how it disagrees with my points. I didn’t see any part of the comment that implied it did
    - deleted 4y ago
      [deleted]
_aavaa_ 4y ago
But the point isn't that just the scorching hot loop is 20x slower, but that this penalty is paid everywhere. And it won't show up in profiling since there isn't a hotspot, it's death by 100 cuts.

mmarq 4y ago

His classes are doing a single multiplication, of course dynamic dispatch would have a significant cost in this scenario.

Olreich 4y ago
Never look at the dispatch of a big company’s Java code base then. It’s dynamic dispatch 400 layers deep for a single network call or file op or small amount of math. Sure those are more expensive operations, but the dynamic dispatch has continually out scaled the problem.
- mmarq 4y ago
  But the company that uses Java quite often is writing the umpteenth line-of-business application, where dynamic dispatch is not going to cause a massive overhead