Except PHP is not Java, and it never can be.
What is PHP's multithreading model again? Hotspot VM? NIO?
I'm sure someone will chime in and cite something similar in PHP, but the comparison will be laughable in reality.
What is PHP's multithreading model again? Hotspot VM? NIO?
I'm sure someone will chime in and cite something similar in PHP, but the comparison will be laughable in reality.
Not saying php is better, there's definitely reasons using rust, elixir, et al would be a better decision for scalability/etc... Just saying it isn't as far off from java, and it's getting JIT I believe in 8.0 (tentatively), whether that improves speed/proficiency is yet to be determined.
That said, I've been a laravel dev since 2013, getting a little bored, so have been branching out and toying w/ other things like clojure, elixir, rust, and node.js for backends to web/mobile apps. Though, laravel is easiest/fastest most of the time to get a project completed by myself.
If PHP does not have JIT, then it's nowhere near the speed of Java. Even if it did, Java would likely beat it significantly. I would encourage you to read about Java's Hotspot VM and its adaptive optimizations.
You're confused. Nowhere did I claim that multithreading always means parrelalism.
Since it's inception, the PHP implementation hasn't been threadsafe and since, the way of doing paralellism has been process forking. Later iterations where released with support for long-lived processes and threads but it's still not officially "stable" since again, historically the model of process forking made the ecosystem take for granted non-memory safety.
On the other hand, at least since the last time I was doing Java, paralellism is done via multithreading. Sure, there must be someone doing some else out there, but relevant frameworks like Spring work by making 1 thread by http request.
IMHO the right way of dealing with concurrency is the Node way. But comparing the PHP vs Java y think the PHP way is better. In small-medium scale the Java way is obviously more performant. The problem is when you scale to more instances. The PHP way of immutable processes really makes vertical scalling easier.
Java web servers are multithreaded. Java has JIT. Java has a Hotspot VM with JIT optimizations at runtime.
This is why companies like Google and Amazon run their stacks on Java. It scales. Facebook had to write their own fork of PHP due to performance issues.
Never said that. What I said was that in the small to medium scale Java was obviously more performant because of the persistent instance & multithreaded model. But beyond that it really is no longer true. The immutable "shared nothing" process forking model of PHP scales horizontally very easily.
>Java web servers are multithreaded
this really is a disadvantage when scalling. The default linux thread stack is 1024k for 64-bit VMs, can't find what's the minium if you tweak it enough. You can see how bad that scalles to thousands of concurrent requests.
And then there's containerization and microservices, where each instance needs a full JVM.
>This is why companies like Google and Amazon run their stacks on Java
You can make anything scale with Google or Amazon budgets.
Again, just listing some pros and cons of both approaches, both of which I think are not even the best.
Are you telling me that you run a process pool of thousands of PHP instances on a single machine? I hope not.
Your notion that forked = better is outdated. Running processes has overhead, even with read only shared mem. Micro processes are the way to go, and are being embraced by newer languages. You get min mem and context switching overhead, along with the parallelization of running on multiple cores.
Even so, threads are still going to be lighter weight than forking new "heavy weight" (non micro) processes.
And this doesn't even get into the more efficient compilation. PHP has no JIT yet. There's overhead for type inference. Etc etc
You're beating a strawman here. Nowhere did I make the claim that it was better. I even said multithreading is more performant. The only claim I make is that immutable and shared nothing model of PHP servers makes horizontal scalling more straightforward.
>You're going to be using a thread pooled server anyway to handle requests
That doesn't take away the fact that n parallel requests will require n threads.
>And this doesn't even get into the more efficient compilation. PHP has no JIT yet. There's overhead for type inference. Etc etc
I don't make any claims here either. Of course Java is faster here. My point was specifically about which model of concurrency and paralellism is better for server IO.
What's your point? In PHP's model, n requests will take n processes. There's no event loop in PHP.
The forked model has nothing to do with making scaling horizontally more straightforward. In either scenario, you'll end up running a different process on another machine once you exhaust your resources.