6 ms·

If you can deliver responses 10x faster than required, you can scale with 10x fewer resources (or at least presumably some factor of fewer resources) and still

If you can deliver responses 10x faster than required, you can scale with 10x fewer resources (or at least presumably some factor of fewer resources) and still stay within the user requirements. I'd say that's a nice advantage.

pjmlp 8y ago
Not everyone is going to be the next Google, Facebook, Crytech, EA, ... There are better ways to waste money than spending it on YAGNI features.
- jstimpfle 8y ago
  Consider Parkinson's law... Compare git to mercurial... Consider how many successful Java command line programs are there?
  - pjmlp 8y ago
    There are plenty of them at the enterprise level. Just a couple of months ago I re-wrote several Korn shell scripts doing ETL related tasks into a couple of saner Java CLI programs at customer request.
    - jstimpfle 8y ago
      And the responsiveness is good? Isn't there always this terrible startup lag? Could we rewrite the C implementation of e.g. git in Java to get a program that is just as fast (e.g., instantaneous response for most operations)?
      - pjmlp 8y ago
        Surely, you know that there are native code compilers for Java, right?
        jstimpfle 8y ago
        Is this practical? What are the limitations? Is this Java spirit? Why doesn't everybody use it? What does this do about startup time? My initial point in the meantime was only that performance does matter. And that for some reason I cannot recall any (open source or free software) CLI programs written in Java from the top of my head. While there are free Java implementations easily available no?
        pjmlp 8y ago
        Many don't use them, because they are commercial tools, and many developers nowadays don't like to pay for software. The only limitation is that for reflection code one needs to white list which classes end up on the binary. All major third party commercial JVMs always had the capability of AOT to native code, it was just tabu at Sun. Oracle has other point of view thus kept the Maxime project alive, rebranded it into Graal, and now those that don't like to pay for developer tools can also enjoy AOT compilation to native code via SubstrateVM, GraalVM and Graal integration into OpenJDK. Just Windows support is not yet fully done for the time being. Their long term roadmap is to rewrite the C++ parts of OpenJDK in Java itself, also known as Project Metropolis. OpenJDK 11 also adopted a feature already common in another commercial JVMs, which allows a JVM to dump a JIT image before existing. Which then allows for AOT like startup on the 2nd execution onwards. Also Java isn't the only safe alternative to C, those that don't mind lack of generics can just pick Go instead of dealing with C. Which then we already have several high profile projects using it, including Google's exploratory microkernel based OS.
slededit 8y ago
These most recent optimizations are nowhere near 10x faster. The only one that can even come close is autovectorization and that can be done without heavy reliance on UB. If your loop is worth autovectorizing the 2 instructions to check for pointer aliasing, and other showstoppers is not material.

pjmlp 8y ago

Not everyone is going to be the next Google, Facebook, Crytech, EA, ... There are better ways to waste money than spending it on YAGNI features.

jstimpfle 8y ago
Consider Parkinson's law... Compare git to mercurial... Consider how many successful Java command line programs are there?
- pjmlp 8y ago
  There are plenty of them at the enterprise level. Just a couple of months ago I re-wrote several Korn shell scripts doing ETL related tasks into a couple of saner Java CLI programs at customer request.
  - jstimpfle 8y ago
    And the responsiveness is good? Isn't there always this terrible startup lag? Could we rewrite the C implementation of e.g. git in Java to get a program that is just as fast (e.g., instantaneous response for most operations)?
    - pjmlp 8y ago
      Surely, you know that there are native code compilers for Java, right?
      - jstimpfle 8y ago
        Is this practical? What are the limitations? Is this Java spirit? Why doesn't everybody use it? What does this do about startup time? My initial point in the meantime was only that performance does matter. And that for some reason I cannot recall any (open source or free software) CLI programs written in Java from the top of my head. While there are free Java implementations easily available no?
        pjmlp 8y ago
        Many don't use them, because they are commercial tools, and many developers nowadays don't like to pay for software. The only limitation is that for reflection code one needs to white list which classes end up on the binary. All major third party commercial JVMs always had the capability of AOT to native code, it was just tabu at Sun. Oracle has other point of view thus kept the Maxime project alive, rebranded it into Graal, and now those that don't like to pay for developer tools can also enjoy AOT compilation to native code via SubstrateVM, GraalVM and Graal integration into OpenJDK. Just Windows support is not yet fully done for the time being. Their long term roadmap is to rewrite the C++ parts of OpenJDK in Java itself, also known as Project Metropolis. OpenJDK 11 also adopted a feature already common in another commercial JVMs, which allows a JVM to dump a JIT image before existing. Which then allows for AOT like startup on the 2nd execution onwards. Also Java isn't the only safe alternative to C, those that don't mind lack of generics can just pick Go instead of dealing with C. Which then we already have several high profile projects using it, including Google's exploratory microkernel based OS.

slededit 8y ago

These most recent optimizations are nowhere near 10x faster. The only one that can even come close is autovectorization and that can be done without heavy reliance on UB. If your loop is worth autovectorizing the 2 instructions to check for pointer aliasing, and other showstoppers is not material.