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...

    http://www.phoronix.com/scan.php?pag...8-JIT-Approved

  • #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 hreindl View Post
                  Well, you can write everything from cli up to Honeypot servers in PHP and it just works

                  people likely don't know anything expect they read 10 years ago and that's it in their stubborn mind
                  From the viewpoint that all common programming languages are alike for solving larger problems, what makes PHP stand out in your viewpoint&experience? I don't believe it can shorten programmer time by a significant factor compared to other languages in the Top 50 list (https://www.tiobe.com/tiobe-index/).

                  It is possible to devise a specialized problem-specific language that unfortunately would have issues solving all other problems. For example, it is easy to make a programming language stand out in the "Hello world program" task by making the hello world source code be a single character, such as 'h'.

                  Is PHP better than other common languages in terms of general efficiency of problem solving?

                  Comment


                  • #10
                    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

                    Working...
                    X