Why so slow in Windows?

[Umberto Salsi]

Hi, I'm testing a PHP program to be relased as open-source (PHPLint) which
performs a detailed analisis of PHP source programs:

* CLI only, no WEB,
* no network connection involved,
* no data base,
* minimal disk activity required to load the source of the program
and the sources of the files to be parsed (less than 500 KB);
* the php.ini is very minimalistic, with no extension modules at all, same
exact php.ini file on Linux and Windows.

Observed:
* CPU 100 % all the time.
* No disk activity.
* No net activity.
* Only php.exe running on Windows (php-cli on Linux).

Now, the performances trying to validate something moderately complex
(itself):

1) Slackware Linux 12.1, Pentium 4, 32 bits, 1,6 GHz,
PHP-CLI 5.3.6-dev (quite old, but still working :-):
26 s * 1.6 GHz = 42 Gcycles.

2) Windows Vista Business, Pentium E5300, 32 bits 2.6 GHz,
PHP-CLI 5.3.10-nts:
132 s * 2.6 GHz = 343 Gcycles

3) Windows Vista Business, Pentium E5300, 32 bits 2.6 GHz,
(same PC of point 2 above)
PHP-CLI 5.5.9-nts (LAST RELEASE!):
111 s * 2.6 GHz = 289 Gcycles


If performances can be measured as number of CPU cycles, PHP-CLI on Windows
is from 6 to 7 times slower than on Linux.

Why is PHP Windows consuming 6 CPU cycle where Linux takes only 1? I'm missing
something? is there anything to tune to get better performances on Windows?

I recall that the PHP source being executed is exactly the same, and the
php.ini is exactly the same, with no extensions enabled as the program only
needs strlen(), fopen() and things like that, nothing more.


Regards,
___
/_|_\ Umberto Salsi
\/_\/ www.icosaedro.it

[Sebastian Krebs]

Post by Umberto Salsi
Hi, I'm testing a PHP program to be relased as open-source (PHPLint) which

No offense, but PHP can do this on it's own: "php -l filename.php"

Post by Umberto Salsi
* CLI only, no WEB,
* no network connection involved,
* no data base,
* minimal disk activity required to load the source of the program
and the sources of the files to be parsed (less than 500 KB);
* the php.ini is very minimalistic, with no extension modules at all, same
exact php.ini file on Linux and Windows.
* CPU 100 % all the time.
* No disk activity.
* No net activity.
* Only php.exe running on Windows (php-cli on Linux).
Now, the performances trying to validate something moderately complex
1) Slackware Linux 12.1, Pentium 4, 32 bits, 1,6 GHz,
26 s * 1.6 GHz = 42 Gcycles.
2) Windows Vista Business, Pentium E5300, 32 bits 2.6 GHz,
132 s * 2.6 GHz = 343 Gcycles
3) Windows Vista Business, Pentium E5300, 32 bits 2.6 GHz,
(same PC of point 2 above)
111 s * 2.6 GHz = 289 Gcycles
If performances can be measured as number of CPU cycles, PHP-CLI on Windows
is from 6 to 7 times slower than on Linux.

I don't think you can measure it this way. What tells you, that nothing
else consume CPU-time?

Post by Umberto Salsi
Why is PHP Windows consuming 6 CPU cycle where Linux takes only 1? I'm missing
something? is there anything to tune to get better performances on Windows?
I recall that the PHP source being executed is exactly the same, and the
php.ini is exactly the same, with no extensions enabled as the program only
needs strlen(), fopen() and things like that, nothing more.
Regards,
___
/_|_\ Umberto Salsi
\/_\/ www.icosaedro.it
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Umberto Salsi]

Post by Sebastian Krebs

Post by Umberto Salsi
Hi, I'm testing a PHP program to be relased as open-source (PHPLint) which

No offense, but PHP can do this on it's own: "php -l filename.php"

PHPLint does a bit more that php -l... Anyway, it's not this the point.

Post by Sebastian Krebs

Post by Umberto Salsi
* CLI only, no WEB,
* no network connection involved,
* no data base,
* minimal disk activity required to load the source of the program
and the sources of the files to be parsed (less than 500 KB);
* the php.ini is very minimalistic, with no extension modules at all, same
exact php.ini file on Linux and Windows.
* CPU 100 % all the time.
* No disk activity.
* No net activity.
* Only php.exe running on Windows (php-cli on Linux).
Now, the performances trying to validate something moderately complex
1) Slackware Linux 12.1, Pentium 4, 32 bits, 1,6 GHz,
26 s * 1.6 GHz = 42 Gcycles.
2) Windows Vista Business, Pentium E5300, 32 bits 2.6 GHz,
132 s * 2.6 GHz = 343 Gcycles
3) Windows Vista Business, Pentium E5300, 32 bits 2.6 GHz,
(same PC of point 2 above)
111 s * 2.6 GHz = 289 Gcycles
If performances can be measured as number of CPU cycles, PHP-CLI on Windows
is from 6 to 7 times slower than on Linux.

I don't think you can measure it this way. What tells you, that nothing
else consume CPU-time?

The fact that "task Manager" tells me that the "php.exe" process is taking all
the CPU.


Regards,
___
/_|_\ Umberto Salsi
\/_\/ www.icosaedro.it

[Aziz Saleh]

Post by Umberto Salsi

Post by Sebastian Krebs

Post by Umberto Salsi
Hi, I'm testing a PHP program to be relased as open-source (PHPLint)

which

Post by Sebastian Krebs
No offense, but PHP can do this on it's own: "php -l filename.php"

PHPLint does a bit more that php -l... Anyway, it's not this the point.

Post by Sebastian Krebs

Post by Umberto Salsi
* CLI only, no WEB,
* no network connection involved,
* no data base,
* minimal disk activity required to load the source of the program
and the sources of the files to be parsed (less than 500 KB);
* the php.ini is very minimalistic, with no extension modules at all,

same

Post by Sebastian Krebs

Post by Umberto Salsi
exact php.ini file on Linux and Windows.
* CPU 100 % all the time.
* No disk activity.
* No net activity.
* Only php.exe running on Windows (php-cli on Linux).
Now, the performances trying to validate something moderately complex
1) Slackware Linux 12.1, Pentium 4, 32 bits, 1,6 GHz,
26 s * 1.6 GHz = 42 Gcycles.
2) Windows Vista Business, Pentium E5300, 32 bits 2.6 GHz,
132 s * 2.6 GHz = 343 Gcycles
3) Windows Vista Business, Pentium E5300, 32 bits 2.6 GHz,
(same PC of point 2 above)
111 s * 2.6 GHz = 289 Gcycles
If performances can be measured as number of CPU cycles, PHP-CLI on

Windows

Post by Sebastian Krebs

Post by Umberto Salsi
is from 6 to 7 times slower than on Linux.

I don't think you can measure it this way. What tells you, that nothing
else consume CPU-time?

The fact that "task Manager" tells me that the "php.exe" process is taking all
the CPU.
Regards,
___
/_|_\ Umberto Salsi
\/_\/ www.icosaedro.it
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

It could be that Windows is just bad (or worst) than Linux at memory
management? I would construct a similar c program (or equivalent) that does
some processing (close to your php script) and see how it handles in both
operating systems. Also if you don't mind sharing the link to the open
source repo (if it is currently public) that would also be great (I might
be able to run the test on my Windows machine, if I have time).

Aziz

[Umberto Salsi]

Post by Aziz Saleh
It could be that Windows is just bad (or worst) than Linux at memory
management? I would construct a similar c program (or equivalent) that
does some processing (close to your php script) and see how it handles
in both operating systems. Also if you don't mind sharing the link to
the open source repo (if it is currently public) that would also be
great (I might be able to run the test on my Windows machine, if I
have time).

All the program is available from CVS:

http://cvs.icosaedro.it:8080/viewvc/public/phplint/
and click "Download this directory as GNU tarball"

or, from Linux:
$ export CVSROOT=:pserver:anonymous:@cvs.icosaedro.it/home/cvs/public
$ cvs checkout phplint

Post by Aziz Saleh
cvs checkout phplint

then set the path to the php executable in php.bat as explained in the
README.txt file.

The test I made is simply to validate one of the sources of the program,
which involves the parsing of several other files, part included by

Post by Aziz Saleh
phpl stdlib\it\icosaedro\lint\Where.php

...(report here)...
Overall test results: 0 errors, 0 warnings.
Total execution time: 1 min 51.821 s

from which the time of 111 s reported in my original message.
The same, exact PHP script under Linux takes only a fraction of the
time, and I cannot figure out why.
--
Regards,
___
/_|_\ Umberto Salsi
\/_\/ www.icosaedro.it

[Robert Williams]

Post by Umberto Salsi
from which the time of 111 s reported in my original message.
The same, exact PHP script under Linux takes only a fraction of the
time, and I cannot figure out why.

Your best first step is to profile the code. I suspect there’s a particular function call that’s responsible for most of the slow-down. For example, maybe your fopen() calls are triggering a network hit by the OS. Once you know the exact source of the slow performance, you can figure out what to do about it.


Regards,
Bob


--
Robert E. Williams, Jr.
Senior Vice President of Software Development
Newtek Businesss Services, Inc. -- The Small Business Authority
https://www.newtekreferrals.com/rewjr
http://www.thesba.com/


Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any).

[Umberto Salsi]

Post by Robert Williams
Your best first step is to profile the code. I suspect there’s a particular function call that’s responsible for most of the slow-down. For example, maybe your fopen() calls are triggering a network hit by the OS. Once you know the exact source of the slow performance, you can figure out what to do about it.

Ok, I'm a sucker. The word "fopen" put me in the right direction: it had
to be a difference related to the file system: Windows is
case-insensitive, and my program takes care of this comparing files and
paths in case-insensitive way. But here it was the bug: wrong hash
calculation of case-insensitive Unicode strings bringing to the same
exact value for each string, in turn bringing to hash table collisions,
in turn forcing a repeated case-insensitive comparison between file names.

The execution time dropped from 111 s to a fantastic, only 3.31 s!!!
Now the comparison Linux/Windows is reversed:

1) Slackware Linux 12.1, Pentium 4, 32 bits, 1,6 GHz,
PHP-CLI 5.3.6-dev:
26 s * 1.6 GHz = 42 Gcycles

2) Windows Vista Business, Pentium E5300, 32 bits 2.6 GHz,
PHP-CLI 5.3.10-nts:
7.54 s * 2.6 GHz = 19.6 Gcycles

3) Windows Vista Business, Pentium E5300, 32 bits 2.6 GHz,
(same PC of point 2 above)
PHP-CLI 5.5.9-nts:
3.31 s * 2.6 GHz = 8.6 Gcycles

Then the question now is: why so slow on Linux?
I already said I'm a sucker?
Thank you very much to everybody and sorry for the disturb.
--
Regards,
___
/_|_\ Umberto Salsi
\/_\/ www.icosaedro.it

[Lester Caine]

Post by Umberto Salsi
Then the question now is: why so slow on Linux?
I already said I'm a sucker?
Thank you very much to everybody and sorry for the disturb.

Fixing performance problems is not a 'disturbance' but rather an important
function of a support list. Certainly on the database lists the differences
between windows and linux can cause fun and often it is the case (in)sensitivity
which causes it. SQL standard is upper case, linux tends to use lower, and
unicode complicates things even more.

My own experience even today is that running the same versions of Apache and PHP
on the same hardware dual booting between linux and windows, using the same php
test suit, gives Linux a three to one advantage over Windows. So I was not to
surprised at your first finding. That you have code included to handle what can
be a problem if the same file name is used with different cases - and I still
hit that occasionally when someone has resaved a file windows has 'tidied case
on' back to linux! - would suggest that your test code is working differently on
the two versions? Use something that does not worry about case and probably
unicode ... is windows using just 'wide characters' which it does use
efficiently but is not unicode. We do need a more easily managed way to work
with Unicode characters on PHP but it is a minefield when you lob in case
insensitivity :)
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

[John Bafford]

Post by Umberto Salsi
The execution time dropped from 111 s to a fantastic, only 3.31 s!!!
1) Slackware Linux 12.1, Pentium 4, 32 bits, 1,6 GHz,
26 s * 1.6 GHz = 42 Gcycles
2) Windows Vista Business, Pentium E5300, 32 bits 2.6 GHz,
7.54 s * 2.6 GHz = 19.6 Gcycles
Then the question now is: why so slow on Linux?

I would point out that gigacycles is actually not that great of a unit of measurement. You’re comparing a Pentium 4 (from 2003, single core, with <= 512k L2 cache, and a 400 MHz FSB), to a E5300 (from 2008, with two cores, 2 MB L2 cache, 800 MHz FSB, and even if PHP is running as 32-bit, the chip itself is 64-bit).

Modern (last ~10 - 15 years) CPUs are measured in instructions per cycle, rather than cycles per instruction, and can very easily execute multiple instructions per cycle (with great variability depending on the particular instruction stream and memory access latency), and the general trend is more instructions per cycle. Also, you may even have instruction set differences: the E5300 is a 64-bit cpu, and it’s possible the Windows build of Linux you’re using is complied to take advantage of the new instructions despite still being a 32-bit process.

The E5300 is probably more than twice as fast per cycle. Being five years newer, it’s gone through three process shrinks, from 130nm to 45nm, and likely that many architecture improvements. And that’s just the CPU. There’s everything else on the motherboard that needs to be considered. At a minimum, the E5300 has twice the bandwidth to RAM (and probably more of it), and that machine probably has both faster disks and a faster interface to disk. There may also be other factors that indirectly increase performance (e.g. faster components on the motherboard or faster graphics that reduce cpu overhead).

Hardware differences may not account for the entire performance difference, and there are other factors (load on the different systems, compilers, the particular kernel being used on Linux) to consider, but the performance equation is a lot more complicated than it seems, and that factor of 3.4 difference between 5.3 on the two machines is probably a lot due to the hardware.

-John

[Tommy Pham]

Post by John Bafford

Post by Umberto Salsi
The execution time dropped from 111 s to a fantastic, only 3.31 s!!!
1) Slackware Linux 12.1, Pentium 4, 32 bits, 1,6 GHz,
26 s * 1.6 GHz = 42 Gcycles
2) Windows Vista Business, Pentium E5300, 32 bits 2.6 GHz,
7.54 s * 2.6 GHz = 19.6 Gcycles
Then the question now is: why so slow on Linux?

I would point out that gigacycles is actually not that great of a unit of
measurement. You’re comparing a Pentium 4 (from 2003, single core, with <=
512k L2 cache, and a 400 MHz FSB), to a E5300 (from 2008, with two cores, 2
MB L2 cache, 800 MHz FSB, and even if PHP is running as 32-bit, the chip
itself is 64-bit).
Modern (last ~10 - 15 years) CPUs are measured in instructions per cycle,
rather than cycles per instruction, and can very easily execute multiple
instructions per cycle (with great variability depending on the particular
instruction stream and memory access latency), and the general trend is
more instructions per cycle. Also, you may even have instruction set
differences: the E5300 is a 64-bit cpu, and it’s possible the Windows build
of Linux you’re using is complied to take advantage of the new instructions
despite still being a 32-bit process.
The E5300 is probably more than twice as fast per cycle. Being five years
newer, it’s gone through three process shrinks, from 130nm to 45nm, and
likely that many architecture improvements. And that’s just the CPU.
There’s everything else on the motherboard that needs to be considered. At
a minimum, the E5300 has twice the bandwidth to RAM (and probably more of
it), and that machine probably has both faster disks and a faster interface
to disk. There may also be other factors that indirectly increase
performance (e.g. faster components on the motherboard or faster graphics
that reduce cpu overhead).
Hardware differences may not account for the entire performance
difference, and there are other factors (load on the different systems,
compilers, the particular kernel being used on Linux) to consider, but the
performance equation is a lot more complicated than it seems, and that
factor of 3.4 difference between 5.3 on the two machines is probably a lot
due to the hardware.
-John
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Not only that, there's a matter of L1 and L2 cache size differences in
addition the FSB. If you want to compare OSes, give both the exact same
specs including HDD model. Because different HDDs can have different
through put and latency which will give you completely different results.

[mrfroasty]

What is the point ? run vista as server os ???

Sent from my iPhone

Post by Umberto Salsi
Hi, I'm testing a PHP program to be relased as open-source (PHPLint) which
* CLI only, no WEB,
* no network connection involved,
* no data base,
* minimal disk activity required to load the source of the program
and the sources of the files to be parsed (less than 500 KB);
* the php.ini is very minimalistic, with no extension modules at all, same
exact php.ini file on Linux and Windows.
* CPU 100 % all the time.
* No disk activity.
* No net activity.
* Only php.exe running on Windows (php-cli on Linux).
Now, the performances trying to validate something moderately complex
1) Slackware Linux 12.1, Pentium 4, 32 bits, 1,6 GHz,
26 s * 1.6 GHz = 42 Gcycles.
2) Windows Vista Business, Pentium E5300, 32 bits 2.6 GHz,
132 s * 2.6 GHz = 343 Gcycles
3) Windows Vista Business, Pentium E5300, 32 bits 2.6 GHz,
(same PC of point 2 above)
111 s * 2.6 GHz = 289 Gcycles
If performances can be measured as number of CPU cycles, PHP-CLI on Windows
is from 6 to 7 times slower than on Linux.
Why is PHP Windows consuming 6 CPU cycle where Linux takes only 1? I'm missing
something? is there anything to tune to get better performances on Windows?
I recall that the PHP source being executed is exactly the same, and the
php.ini is exactly the same, with no extensions enabled as the program only
needs strlen(), fopen() and things like that, nothing more.
Regards,
___
/_|_\ Umberto Salsi
\/_\/ www.icosaedro.it
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php