Announcement

Collapse
No announcement yet.

JIT Is Approved For PHP 8 To Open Up Faster CPU Performance

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

  • JIT Is Approved For PHP 8 To Open Up Faster CPU Performance

    Phoronix: JIT Is Approved For PHP 8 To Open Up Faster CPU Performance

    It was widely expected that PHP 8 would introduce JIT (Just In Time) compiler functionality while now that experimental work has been approved...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    FFS... let the language rest a little bit.

    Comment


    • #3
      As a security researcher this is going to be awesome. Don't get me wrong, I write PHP all the time for my own sites. it's way better than the Perl stuff everything was originally (huge Perl fan BTW). However, PHP is not known for correctness and security and JIT adds a whole new dimension of exploits.

      If you're wondering, on sites I need to be correct, fast, and secure I use C/C++ and sometimes Lua(JIT). Everything else though, general use, I use PHP. I think Go/Rust are OK but they don't offer anything I can't get from traditional very well proven methods.

      Comment


      • #4
        Let me guess: Still no native support for Unicode?
        It's beginning to be a bit too stupid. This is a standard from the early 90's, and this joke of a language hasn't succeeded in including support.

        Comment


        • #5
          Originally posted by AHSauge View Post
          Let me guess: Still no native support for Unicode?
          It's beginning to be a bit too stupid. This is a standard from the early 90's, and this joke of a language hasn't succeeded in including support.
          PHP defaults to UTF-8 and as long as you use the mb_* extension you should be pretty set.

          Comment


          • #6
            People tend to think of PHP as a language for web development, but I use PHP for a lot of scripting work in Linux and it works very well for that. I tend to prefer its syntax over Python, and their website has very good documentation.

            Comment


            • #7
              Originally posted by hreindl View Post

              bla - with a timemachine all would be fine - otherwise LUCKILY the PHP developers are not that stupid to break BC in a way as Phyton did where a lot of code is still not compatible with python3, many of that stuff is likely internal and just does what it is expected to do and the people implemented are no longer there - have fun next year
              ...and what's your point? Introducing native Unicode support doesn't have to break backwards compatibility. That said, PHP do break it too and Python 2 vs 3 is about a lot more than defaulting to Unicode.

              Originally posted by AJenbo View Post

              PHP defaults to UTF-8 and as long as you use the mb_* extension you should be pretty set.
              Huh? PHP doesn't default to UTF-8. PHP know just about nothing about multibyte characters. UTF-8 just happens to work in PHP by default because it's 7 bit ASCII compatible and is meant/designed for old systems that doesn't know what multi byte characters are. Due to the nightmare that is using it in a programming language (variable length encoding is pita), you'll notice that other programming languages usually go for the much more sensible choice of using UTF-16.
              As for "Multibyte string" extension:
              For starters, it's not a native part of PHP.
              Then there is the fact that it was written to support some Asian languages back in the days. Since these don't have a concept for lower case and upper case, it quite quickly suck at that stuff. How do you do something as basic as a case insensitive comparison for instance? Up until December last year, that would be impossible to do currectly. In PHP 7.3, you can do this:
              Code:
              if (mb_convert_encoding($strA, MB_CASE_FOLD) == mb_convert_encoding($strB, MB_CASE_FOLD)) //MB_CASE_FOLD_SIMPLE can also be used
              {
                  //Do stuff
              }
              If you use something older than PHP 7.3, you're out of look. The closest you get is this inaccuracy:
              Code:
              if (mb_strtolower($strA) == mb_strtolower($strB))
              {
                  //Do stuff
              }
              Lower case != case folding. Case folding is a required step in Unicode world in order to perform a valid case insensitive comparison. In full blown case folding mode, "ß" is suppose to be equal to "ss". Please note that case folding can be language depending as well, so I doubt any of my examples are correct for all languages.
              So essentially, Unicode is a lot more complex than the "Multibyte string" extension is capable of handling.

              Comment


              • #8
                I'm not saying that there aren't any issues left regarding unicode, I think that's true for a lot of languages (js still doesn't have good support for unicode in regex), but your example of what is wrong with php 8 unicode support is something that was fixed in 7.3...

                Comment


                • #9
                  Originally posted by AHSauge View Post
                  UTF-8 just happens to work in PHP by default because it's 7 bit ASCII compatible and is meant/designed for old systems that doesn't know what multi byte characters are.
                  That statement makes no sense. Either string functions support the encoding used or not. And PHP's normal string functions do not. The mb_ functions however do.

                  Originally posted by AHSauge View Post
                  Due to the nightmare that is using it in a programming language (variable length encoding is pita)
                  Variable length encoding is not a PITA at all. It's easy to deal with, needs no special BOM, is byte order agnostic.

                  Originally posted by AHSauge View Post
                  you'll notice that other programming languages usually go for the much more sensible choice of using UTF-16.
                  I don't think you know what you're talking about. UTF-16 is the worst possible choice. It's still variable length but also byte order dependent.

                  Luckily in Linux land we didn't make the same mistake as Microsoft did with their Windows APIs, C# or Sun did with Java.

                  Comment


                  • #10
                    Originally posted by hreindl View Post

                    bla - with a timemachine all would be fine - otherwise LUCKILY the PHP developers are not that stupid to break BC in a way as Phyton did where a lot of code is still not compatible with python3, many of that stuff is likely internal and just does what it is expected to do and the people implemented are no longer there - have fun next year
                    Considering that PHP is pretty nasty about backwards compatibility, I think it would be fine for them to announce a major change in how the language works.

                    Comment

                    Working...
                    X