Mojo claim to be 35,000 times faster than Python -> C is 80 times faster than Python -> Mojo 437.5 times faster than C -> Mojo faster than machine code
mojo highjacks the fundamentals of physics by giving electrons monster energy, making them able to speed up how much clock cycles they can do per second without heating up as much. it's complicated you wouldn't get it. Meanwhile C and C++ instead of using hydrolyctic electron excitation, they're still just generating raw instructions... so arcane... sigh
I think it’s based of the fact that mojo is capable of utilizing parallel hardware like GPUs and TPUs for certain tasks. I suppose it’s similar to claiming that CUDA/OpenCl are faster than C
Even if the benchmark might not be accurate when comparing to other languages, you have to admit that making a PHP script go from 630 requests/sec to nearly 30k requests/sec is a massive improvement.
The baseline PHP test was done with the internal server which is meant for quick and dirty testing/dev, not production. PHP-FPM is far faster than that, especially if configured properly for production
@@neptronixSwoole sits at no. 33 on the latest Techempower composite scores. There’s nothing rigged about it. It’s very, very fast. Frameworks like Hyperf that are built around it can handle way more requests/sec than Node.
I'm pretty sure databases are the main bottlenecks and the source of troubles for 99% of backend applications. Juniors who have no experience of tackling serious performance issues in backend systems, tend to like this kind of discussions.
For a lot of companies, poor database design and maintenance is a major issue. I was brought in to one company and I asked if there were any DBAs and was told we used to have DBAs, but not now. The dev database server was running out of disk space so a ticket was put in to double the diskspace. I looked a the database and just ran a script to shrink the logs and recovered 75% of the existing disk space. I am not a DBA, but as a database developer I have had to perform more DBA tasks in the last few years because companies decided they didn't need DBAs they had full stack engineers.
Maybe, but wouldn't HDD be worse still? A lot of fat frameworks and CMSes and PHP projects not optimized/compiled/cached/whatever, have a ton of file reads, which would be much slower than DB.
I've been using PHP since 2002. I've seen the good, the bad and the ugly. In recent years I started seeing PHP going from ugly, to bad, to good, to great.
Still, in the long run I am hoping for Rust/WASM to be able to have full access to the browsers DOM without the need for JavaScript. That would change everything.
True. PHP truly evolves in a way that boosts businesses a lot. Now, you can do anything in PHP except low-level stuff, but for low-level, you choose C or Rust.
Except that 90% of PHP devs are stuck in their ways of writing overly dynamic code without any type declarations. Even when working in something as critical as a billing application
I've been making my own framework with OpenSwoole for a while. I can confirm, it is faster than Bun and while I haven't tested Go, it can't be that much slower. Although you have to take into consideration that Go is compiled, and this speed is only in a vacuum. Once you start building out ALL the rest of the application Go will, of course, be faster. On top of that, the OpenSwoole library is not actually PHP. It's an extension, written in C++.
PHPs integrated server (the first benchmark) is a development server. It doesn't even use multiple workers by default. It's not meant to be used in production. Of course, the second benchmark is also inaccurate because it benchmarks OpenSwole and PHPs JSON implementation which are both written in C, not PHP.
I mean PHP is essentially bindings for C and it's libraries. It's always been capable of being fastafbois. You'd obviously never use a PHP based JSON parser in PHP when you can use the native functions to hand that work to C. I think this is a more realistic benchmark than say, arithmetic in a tight loop.
fare/unfare, lol, who cares ? you can do it faster. period. and that most high level langs use C/C++ under the hood (including JS) everybody has already told you above.
Funny how the base compare is with a PHP development server (which should never be used in prod), would like to see how PHP-FPM or the apache module performs, not a dev server.
@@aragnophy Haha, good one. I think noone should use it anymore, but I definitely saw it being used in prod. Nobody is stopping one from setting it up today with modern PHP, so I think enough ppl will still set it up, even though they should use php-fpm instead.
Hey, that’s my video! Appreciate the dig through it, lot of valid points in those comments. If you’re ever in the mood to dig into PHP sometime, let me know! 😂
Blazingly fast! Laravel Octane just wraps the PHP Laravel up inside of a go routine and keeps it all in memory. Pretty cool advancement, PHP lives to fight another day.
@@enkiimuto1041 Dude, do you understand that power to use powers of other powers? That basically neglects the need for the usage of any other language except if you want to go low-level. You have amazing developer experience, and all stuff is ready in PHP/Laravel & PHP can use extensions like Swoole or Parallel or even use Go capabilities while Go can't use the capabilities of PHP!
@@HT-hj5jp it is wise to think so. Fast developement with PHP, and fast speed with extensions in c/c++/go. Best dev expereince and top performance, why not?
I love OpenSwoole - finally PSR-7 compliant as well now. PHP and Go are similar in that they compile extra fast. PHP, Java, and .Net are similar in that there is a virtual machine running translated bytecode.
Excuse my ignorance but, if I understand correctly, prime is saying that the benchmark is misleading or something like that. Why? Aren't the go and php programs doing the same but one simply handles more RPS thsn the other?
The first php exmaple is using a dev server (not meant to be performant). OpenSwoole is written in C, so it isnt actual php. The NodeJS example uses express, one of the slowest libraries, and the with Golang example I dont have idea, but it seems like a bad implementation or some weird scenario And the most important thing is that he ran the benchmarks locally with an unknown version of php, an unknown version of nodejs, an unknown version of go and an unknown ENVIRONMENT A lot of things could go wild testing locally
Never used PHP, but its absurd that it is faster than GO(I have seen it being faster than rust in some edge cases)... Even the most unoptimzed code should outperform majority of the interpreted languages.
tl;dw; If your PHP application uses an HTTP server written in C/C++ and doing nothing except calling two functions written in C then PHP is faster than GO :D
I’ve tried Swoole but I’m not sure if it’s production ready per se, but it’s an exciting direction for PHP. Definitely requires you to think differently and carefully about how you architect your PHP app since it is contrary to the traditional model of the short lived lifecycle (where everything starts fresh and gets discarded at end of request). It is very interesting, though.
We use Swoole in production and have been for quite awhile now on an API that serves 500 -> 2000 heavy, requests per second. Took a little bit of configuration, and it is important to understand that your app will live in memory, but it’s been wonderful.
The problem is that PHP is synchronous by default. On the contrary JS & Go are asynchronous by default. So all the libraries of JS and Go will natively support asynchronous code, but for each PHP I/O lib you will have to find an up-to-date version of this library supporting asynchronous code which is not necessarily easy (same problem than python async apps).
Swoole/OpenSwoole hooks into all synchronous I/O functions of PHP and makes them asynchronous automatically - This means that the code still looks synchronous (except the fact that the synchronous code is wrapped in coroutines). OpenSwoole/Swoole does the same for most PHP extensions
Most of use bare metal senior guys don't use node as web apps. We only use nodejs for the css and js development. I didn't know about pm2. I would use a top, htop, [-SIG trap], daemon tools, and other unix scripts instead of a process manager. [ pm2 ] reminds me of what J2EE used to do and that experience was horrible. I guess I learn something everyday.
The issue with "async PHP" is that once you use it, you throw out all native PHP functions that do IO. Also i would be interested to see a deeper comparison what is actually done in the async PHP runtime. Does it handle all sorts of issues with encoding and unicode? As a default its most likely just dumping bytes and not doing much else. Every time i did run some stringly benchmarks with PHP perf dropped drastically when you did unicode (what most other languages do as a default)
That's because PHP is usually benchmarked using apache or nginx, in the case what the benchmark is measuring is the overhead of apache or nginx more than it's measuring PHP. When you run node.js out through apache/nginx, it's really, really slow in a similar condition.
PHP is fast enough for most use cases. Just don't use any frameworks (or ORMs). Decade ago I helped to rewrite a video rental service. Original one was done with PHP + some popular framework at the time and managed to handle 20 users/s. We implemented the service as pure PHP without ORM and managed to get 2000-3000 users/s on the same hardware. We did also test node.js implementation and it was twice as fast, but customer didn't want to go with that as PHP devs were so much cheaper and easier to find than node devs. Today they would probably want it to be implemented with Java and Spring Boot, ugh. Still that would make more sense than use node :)
I'm working on a computationally hyperefficient framework for PHP and we notice that laravel and symfony are 5x slower at almost everything. Yeah a chunky framework is a huge tax on PHP, raw PHP is really fast considering it's a dynamic typed language.
It is. But why would you want to use PHP, which is still slower than something else and not necessarily harder to use? Also, PHP consumes a lot of memory per request and actually that's a bigger issue.
@@mdbk2 I use it because: 1) It's extremely fast. 3 times faster than node when used with openswoole ( source: techempower composite benchmarks ). This is amazing considering it's a simplified and dynamic typed language. This is because it's a thinner layer on top of C than most languages are today. 2) It's extremely quick to work in because it simplifies coding... at the same time it doesn't limit you to do crazy shit if needed. Best of both worlds. 3) Other languages are more of a pain in the ass due to lower convenience + longer code, or are a tad easier but dramatically slower ( meaning you will spend more time optimizing and go negative on your productivity gains ), PHP hits a great sweet spot for me of short code and fast code. 4) Much like Rasmus Lerdorf himself, i am simply an impatient programmer. My PHP scripts take less than a megabyte per instantiation on average, i personally don't feel like that is too much.
I am 100% on board with you making click bait misinformation shorts as long as you do it under the name “The Crimagen”. You don’t harm your actual reputation that way and it’s a good name for parody content.
Lol. I commented some things that massively improved php performance the last years , so much that it can be found at the top of (framework) benchmarks _sometimes_, while also agreeing that this benchmark was done wrong and go is surely sister , agreeing with the response of this video . And it got marked as spam and removed ?
I don't get why it was slow without Swoole and way faster with it. What server were they using with php before using it with Swoole? Yes, php is blocking, but I thought that didn't matter because, well it's not like you typically run a server implemented in blocking php. Instead you use Apache or something and it just launches more php instances as needed, or something like that (I'm probably wrong about this part...)
Because without Swoole, PHP executes the entire script from scratch with each request. With Swoole it works more like a Node or Go server, where only the handler is executed, but the rest of the application remains in memory.
The first example didn’t use a real web server, but phps built in dev server, which can’t handle multiple requests at a time. They should have used Apache or nginx+ php-fpm
@@mdbk2 yeah but if the server is then just your php process long running, yes there are some opportunities for optimization there, but I am not convinced these numbers mean anything at all unless you compare with a typical server used with php. There could also be some speed advantage to just giving each request its own blocking php process.
You should release shorts where each short contradicts another using bad benchmarks. "RUST slower than NODE?!" and the inverse, "PYTHON FASTER THAN C?!" etc
What I sure exactly know PHP is much more faster and comfortable in time parsing then GO. Don't believe me? Try to do time.Parse() fast and correct in GO!
You all need to write the following on a blackboard like Bart: Languages are not slow or fast - runtimes are. Languages are not slow or fast - runtimes are. Languages are not slow or fast - runtimes are. Languages are not slow or fast - runtimes are. Languages are not slow or fast - runtimes are. People saying "PHP is not fast, that library is" , LOL WHAT? Can anyone compare C compilers from the 80s with modern ones ? :D
php serve is slow, php-fpm still has some unnecessary overhead, especially when using big frameworks, but php itself does crunching really fast when you let it
According to techempower benchmarks PHP can be faster than Go, but Go does have multiple implementations that are faster than PHP. But it looks like you can get PHP going extremely fast. And, yes, PHP is faster than JS, significantly. Granted, C# is faster than Go, C# is only slower than Rust and C++.
Sending a string of text and asking for it back just seems like an unrealistic test. Again technology if at its pace will make these silly benchmarks unnecessary and the language wars will be ignored. Pick the language which meets the project’s requirements and will have the best chance of success. Highly dependent on the size and scale of the application..
