Announcement

Collapse
No announcement yet.

Tumblr Is The Latest Company Boasting About PHP7 Performance

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

  • #21
    Originally posted by cynic View Post

    beside the fact that you don't even realize that C and C++ are completely different languages (and that benchmarks are about C) those are microbenchmarks that are completely useless for real world performance measurement.
    I don't think your cute JVM JIT overheads, forced dynamic allocation and GC attacks will ever make Java better for "real world performance measurements". Every big software developed in Java I've been testing turned out to be incredibly sluggish.

    C and C++ are fairly different, nut the performance level is very comparable. C++ compilers often also support C (MVSC, gcc, clang, obviously), and C++ is meant to keep a similar performance level as C, with a good level of abstraction.

    Not talking about how wonderful Java is. Not being able to do an "a + b" arithmetic operation over generics, wrappers taking 3x the memory space a primitive would use and being immutables (which is very nice when doing math operations over a whole array! a couple megabytes releasing every single time you change an array of them...), forced virtuals, forced dynamic allocation...

    Comment


    • #22
      Citation needed, please.

      Comment


      • #23
        From the Gcc developers (https://gcc.gnu.org/wiki/cxx-conversion):

        Migrating GCC to C++ as implementation language:

        - C++ is a standardized, well known, popular language.
        - C++ is nearly a superset of C90 used in GCC.
        - The C subset of C++ is just as efficient as C.
        - C++ supports cleaner code in several significant cases.
        - C++ makes it easier to write and enforce cleaner interfaces.
        - C++ never requires uglier code.
        - C++ is not a panacea but it is an improvement.

        Comment


        • #24
          Originally posted by uid313 View Post

          Sure, but it makes the language feel ancient and less expressive. You get limited in the things you can do, or have to solve things in weird backward ways and using hacks or more boilerplate code.
          One of the early languages I learnt was really expressive. It was called Perl. Let's not make that mistake again!

          Having a language be more verbose means it can be learnt in less time, old code that is written in it is easier to maintain and the cost is a few keystrokes here and there. with muscle memory what it is - I have not yearned for keywords like "function" to be "fn" or for syntactic sugar to replace my for loops.

          quite often less is more.

          Comment


          • #25
            Originally posted by AsuMagic View Post

            I don't think your cute JVM JIT overheads, forced dynamic allocation and GC attacks will ever make Java better for "real world performance measurements". Every big software developed in Java I've been testing turned out to be incredibly sluggish.
            your cute C++ compiler, on the other side, will never be able to perform those nice runtime optimization that JIT does.
            JIT account as overhead only if you're running microbenchmarks. In real life application it does an amazing work.

            Comment


            • #26
              Originally posted by cynic View Post

              your cute C++ compiler, on the other side, will never be able to perform those nice runtime optimization that JIT does.
              JIT account as overhead only if you're running microbenchmarks. In real life application it does an amazing work.
              You mean almost everything I can get by passing -O3 -march=native -flto?
              Many, many of those cute little jit optimizations can be done statically with the right compiler flags.

              Comment


              • #27
                Originally posted by Vladimir1 View Post

                You mean almost everything I can get by passing -O3 -march=native -flto?
                Many, many of those cute little jit optimizations can be done statically with the right compiler flags.
                nope. There are optimization that you can only do at runtime, because they depend on every particular execution of your code.
                just google about what modern Java JIT does.

                Comment


                • #28
                  Originally posted by cynic View Post

                  nope. There are optimization that you can only do at runtime, because they depend on every particular execution of your code.
                  Give a few examples (that shows you understand them). And why do you think it can only be done at runtime?

                  Comment


                  • #29
                    Java is a slow piece of trash, but GC/JIT languages in general are. The way it is designed will cause latency in certain circumstances. The problem with statically compiled languages is that you cant do optimizations without code paths which will get troublesome to maintain. Unless you compile everything for your own computer natively like i do which will blow any GC/JIT langauge out of the water. If you distribute your binary you cant statically compile your binary with native optimizations. Which GC/JIT code could probably perform better than statically compiled code in some scenarios but will always lose in general performance due to GC/JIT complexity code running in the background. The best thing would be to compile IR natively and load it into the engine and you will get the best performance out of your code with native optimizations(AOT).

                    Comment


                    • #30
                      Originally posted by Vladimir1 View Post
                      Give a few examples (that shows you understand them). And why do you think it can only be done at runtime?
                      I just write you some very basic example.

                      case A)

                      you have a class method that takes a parameter of a class implementing the interface Foo and calling the method Bar.

                      at compile time you cannot make any assumption about what the method Bar is, so you cannot make any optimization.
                      if JIT sees that you often call that method passing a class Baz (which implements interface Foo) it optimize the code for that specific class.

                      case B)

                      you have a class method that takes an array and loops through it doing something.
                      at compile time you cannot make any assumption about that array (ie. you cannot unroll the loop).

                      if JIT notices that you pass a final static array often to that method, for example, he can unroll the loop.

                      and those are only the basic cases. I've read some very interesting docs about JIT optimization at runtime: if I'll find them again I'll link them here.



                      Comment

                      Working...
                      X