3 ms·
> Something about it kinda smells though: it doesn't match my experiences with PHP at all. Did you look at what the programs do before announcing that "it kind
by igouy 17y ago
> Something about it kinda smells though: it doesn't match my experiences with PHP at all.
Did you look at what the programs do before announcing that "it kinda smells"?
Did you look at the "really interesting link" enough to realize the benchmarks game website is written in PHP?
Did you look at that particular web page enough to see "PHP is rarely the bottleneck (HTML slides)" ?
- thaumaturgy 17y agoYes, I saw all of those before making my comment. None of them were a substantive response to the results of the graph. When being presented with data, you should answer with more data, not conjecture.
- igouy 17y ago> Yes, I saw all of those before making my comment. So when you say "it doesn't match my experiences with PHP at all" are you talking about your experience writing planetary simulations in PHP? > When being presented with data... You presented opinion not data. > all the tests that I looked at were massively recursive Name them.
- thaumaturgy 17y agoThis kind of nonsense is precisely why engaging in language debates is a pointless waste of time. Why, sure, I would love to take time out of my day to deal with you. > So when you say "it doesn't match my experiences with PHP at all" are you talking about your experience writing planetary simulations in PHP? No. I was being somewhat unclear earlier so that I wouldn't have to come right out and say that at first glance the "benchmark" site looked like complete bunk. The real game would be to figure out in exactly which way it was bunk, and initially I wasn't interested in that. The test results posted there -- based on the actual numbers, not on the horribly-formatted and nearly useless graph -- were showing a nearly 100-fold disadvantage to using PHP or Java. That's where my experience comes in. Now, I happen to know that AT&T is playing around with an internal presence application for the iPhone and they're hosting everything on Java servers with Tomcat and they're pushing millions of messages per day through them with no trouble. So, I know Java is a reasonable server-side environment. But, there's no way that PHP is nearly 100 times slower, not when the total request time for complex text operations is averaging 800 milliseconds. Those are the experiences I was talking about, and they were the reason that I said simply that the results smelled funny. > You presented opinion not data. Yes, I did, and you missed the point entirely. I said simply, "the conclusions don't seem right". You responded, argumentatively, with a couple of pointers to what is presumably your site (based on your comment history). None of those had anything to do with the data. You were presenting a completely unrelated slide from a PHP presentation, plus the fact that the site apparently runs on PHP, and you wanted to know if I'd even bothered to look at the test programs. And, you know what? None of those has anything to do with anything. They're pointless. Useless. Less than useless, they're a waste of time. That is what I was referring to when I said that data needs to be answered with data. You and I could sit here and waste a lot of perfectly otherwise productive hours arguing back and forth with whose website runs PHP and whose website runs Java, or we could just present some data. And, that's exactly what I did. I went looking for data, because I wanted to know if in fact my experiences with PHP over the last however-many years had been atypical, or if Java had really become that incredibly fast, or for any other explanation. It took some digging before I could find anything else even remotely resembling a comparative analysis, and I did: IEEE. Well, they usually know what they're doing. (Kind of.) And, their results much more closely matched my experiences. There, see? Data versus data. Now if you want to try to argue that there's something wrong with my conclusions, you'll have to look at the data and answer with more data -- because your opinion isn't a good enough response to data. > Name them. Ah! And here, you did indeed catch me. The very first test I looked at was binary_trees, in part because the memory usage for it was enormous. While I did give a cursory glance to fasta, n-body, and mandelbrot, I stopped paying close attention pretty quickly. That said, now that you've forced me to pay closer attention to this, I think I can support my main point even better than before. The current user-submitted PHP test for pidigits is particularly stupid; it re-calculates the same digits of pi over and over and over again as it displays them in groups of ten. Of course it's going to be slow. Moreover, the test results clearly show PHP running on a single processor, while the Java version is running in parallel across 4 processors. I haven't worked in Java, so in the thirty seconds I'm allowing for it I can't say for certain that the test program for pidigits there is re-calculating the same ratio over and over again, but it doesn't look like it is. In fact, it looks like it's been pretty sweetly optimized for this specific test environment. binary-trees at least is recursive in both implementations. And for the Fannkuck test, Java is able to take advantage of its built-in threads library, while PHP is forced to fork() and implement IPC via network pipes. And so on. I really can't be moved to analyze the results or the test any further, because I already found other data that does a better job of answering to these tests. Finally, the "benchmark game" itself is completely misleading, and almost useless as a benchmark of any kind. There are all kinds of arguments out there on the value of benchmarks, but when you're not even attempting to create a level playing field between different test cases, then the benchmark becomes useless. It's much more a game than a benchmark. After looking at all of it much more closely, I now think that using that site as any kind of evidence that one language is slower than any other (or vice-versa) is about as silly as writing a blog post on just how bad C is at being object-oriented. (C, not C++.)
- jrockway 17y agoBut, there's no way that PHP is nearly 100 times slower I too am confused that it's only 100x slower. Consider the operation "2 + 2". In Java with JIT on, this eventually becomes a single instruction, "add". (Ideally 2 and 2 are already in registers from previous manipulation in the function, and you don't even need a "load".) In PHP, this operation is hundreds of instructions. You start with the AST node. Then you look up the variable names. Then you look up their bindings (fast because PHP has no scope, in Real Languages this is at least a linked-list traversal). Then you finally get the object representing the value. Now it needs to be coerced into the right type for +. Once that is done, we can finally run the add operation. Then the result needs to be boxed. You are surprised that that is 100x slower than a native CPU instruction?
- jrockway 17y agoDid you look at the "really interesting link" enough to realize the benchmarks game website is written in PHP? What difference does this make? Did you look at that particular web page enough to see "PHP is rarely the bottleneck (HTML slides)" ? This is just random user-generated content; every language on the site gets to link to whatever they want. (As an aside, I am tried of the "my app can be slow because the database is slow". If you are not Doing It Wrong, your database is not slow, and your app can do other things while waiting for IO.)