Announcement

Collapse
No announcement yet.

Falcon: A New, Faster JIT Compiler For Java/JVM

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by eigenlambda View Post
    Yes, reflection is inherently slow and code using it can be rewritten to be faster. It's also flexible so you can find out faster if your great idea is a good idea. Some day there will be a language that, restricted and decorated, can compile down to templated c++ with stack allocation, but is as easy to write as javascript would be if it came with python containers. I keep expecting this out of Java and other JVM languages.
    I think there are many WTH comments. Many things have costs and yes, developers know how to take this into account, or compiler writters, or JVM/JIT guys.

    It looks to me that you want a C++ template language as the final output of the "ultimate" overly-optimized binary, but to me this is plan dumb.

    So let me point few mistakes I notice in comments:
    - (not a comment of eigenlambda) Reflection can be done with Ahead-Of-Time: In fact AOT can help doing reflection as it can create type hierarchies ahead of time and also it can elide verification. One platform that does this for many many years and they fall back to a JIT just in cases where is needed is Excelsior-JET or there was RoboVM - now BugVM (I am not related with them). Some platform (.Net on Windows Phone 10) can create base on types serializations/deserializations bytecodes based on all types that can be reflected. This is not because AOT cannot be done ahead of time, but because AOT can help specific cases. The single thing that reflection needs it is that if there is a little code generation (which may no be needed) that a JIT/interpreter will run back these codes which are not supported or generated on runtime.
    - Reflection is kind of fast it depends, in fact, it is depending on who you ask, around 15 times slower (if you redo with no optimizations the reflection code and you basically don't know how to write a proper reflection code) or just 50% slower than a virtual call. (I give a source: http://stackoverflow.com/questions/4...on-performance ). So really, if you care to have the ultimate performance, maybe better not use virtual calls, because this is what kills the program performance, or maybe, just maybe, you have a bad design.
    - Language that converts to C++/stack allocation would be silly: There are few problems, with this line of thinking: stacks in any OSes are really small, and we do care about not only using the multithreaded code (which would give a nighmare in performance as there will be very hard to resolve problems like false sharing). At last, and not the least is that Java does convert heap allocations into stack allocation (it is named "escape analysis" optimization) when C++ does not.
    - (not a comment of eigenlambda) The Falcon JIT matters a lot where is used a lot. It is very likely there the Azul team benchmarked it, it is around the financial domain where they compete for every millisecond. I was writing a specialized bytecode compiler that would target things like LLVM and I could achieve around 10-15% speedup, but it is possible that in some cases the advantage could be bigger. Given the price of license of just few thousands (I am not related with Azul - if you see some promotion here) of dollars, the price could be really justified, especially as they sell it as a part of low-latency with very rare "breaks" in the system. This is an extra-edge which they have in their product

    Comment


    • #32
      Originally posted by ciplogic View Post
      Given the price of license of just few thousands (I am not related with Azul - if you see some promotion here) of dollars, the price could be really justified, especially as they sell it as a part of low-latency with very rare "breaks" in the system. This is an extra-edge which they have in their product
      Justifiable prices: Any price of any product or service, including the zero price and including a negative price, contains a component that is completely arbitrary and not justifiable. If this wasn't true then society wouldn't have any structure.

      ----

      Just because Azul is asking specific market players what the price of Zing should be according to them, and the response to the question is "3500 US dollars per year", doesn't mean that such a price is rational from the perspective of other market players.

      Comment


      • #33
        Originally posted by atomsymbol View Post
        (...) Just because Azul is asking specific market players what the price of Zing should be according to them, and the response to the question is "3500 US dollars per year", doesn't mean that such a price is rational from the perspective of other market players.
        Right, but has to be taken the context. I know companies which have developers with full job to tune VM's GCs. And even in countries as Romania a 3500 USD per year are not justifiable if you can remove that developer.

        I - to be clear - see myself as a never buying a such expensive VM. If I have money to spare and latency and responsiveness would be my target, I would better look into Excelsior-JET or I tune my code to be GC-free. Or I would make a mixed system (with various VMs with smaller sizes) that I can scale and again the VM tunning/codegen would not be the key factor...

        Also, I notice some benchmarks done by partners of them, and the Azul seems to do very well, typically in a different league on the same sustained GC generation. Typically one or two orders of magnitude in their pauses (which hurts a lot bot trading and similar financial systems)

        Comment


        • #34
          Originally posted by Delgarde View Post

          You think so? I'd say it's one of the most heavily-used APIs in the Java world... and legitimately so. Dependency-injection frameworks depend on it. Most database persistence frameworks like JPA / Hibernate) depend on it. Proxy-based transaction management depends on it. Many of the UI frameworks like JSF or JSP depend on it. Many of the XML/JSON serialisation frameworks depend on it. You get the idea... for any kind of enterprise code, reflection is *everywhere*.
          "enterprise code"... In the Java world, the word "enterprise" has a bad reputation. JSF was a complete disaster. And yes, I'm stunned to see anyone seriously reference JSF in 2017. JPA is generally considered terrible as well by almost everyone who has used it.

          More seriously, runtime reflection forfeits some of the benefits of a strict compiler with type safety in that less bugs are seen and caught at compile time.

          If you look at Scala, I don't think any of the Scala ecosystem uses this type of runtime reflection.

          Two scenarios where runtime reflection seems beneficial:
          1) Plugins. Where developers accommodate user provided code/libraries.
          2) Debugging + Profiling.


          Comment


          • #35
            Originally posted by Cyberax View Post

            Azul's JVMs are actually widely used in finance (for high-performance trading). They are now trying to expand to other areas like large in-memory database customers.
            Makes a lot of sense since I believe they fixed the achilles heel of Java and large heaps, the extremely slow garbage collection. Although I gotta say that using Java for real time workloads like HFT seems odd.
            Last edited by nils_; 05-22-2017, 02:46 AM.

            Comment

            Working...
            X