I find that results showing that vc2005 generates better code then
the one prepared by the intel compiler extremely usual. Was the test
done on a non-intel (amd) machine by any chance?
On 6-Jan-07, at 9:20 PM, Andi Gutmans wrote:
Hi Edin,
The 2% surprises me a lot. We got very different results but it
might be due
to different hardware, OS (we use Windows Server 2003) and
different tests.
Here's what we got (all non-threadsafe):
vc2005 intel msvc6
bench 9.326 9.378 10.28
hello 10.48 11.6 11.28
xoops 67.82 69.49 81.34
static 16.97 18.4 21.18
qdig 63.52 67.05 69.57
qdig2 14.4 15.61 19.04
Btw, today I never recommend running mod_php on Windows and always
point
people to CGI or existing FastCGI implementations.
That said, I understand that you don't want to break things right
now and
stick to VC 6. Although I know it can work in some cases, I agree
with you
that running two CRTs is probably not a great idea. While the
interfaces of
the CRT functions might be identical, I am not sure all the
structures are
the same and that could cause some ugliness if we get structs like
file
handlers from the Apache executable passed into PHP and vice-versa.
It's something worth looking into but not something one would want
to rush
for a minor version like 5.2.1.
Andi
-----Original Message-----
From: Edin Kadribasic [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 06, 2007 1:28 PM
To: Andi Gutmans
Cc: 'PHP Internals List'
Subject: Re: [PHP-DEV] Windows build
Hi Andi,
Turns out the problem is that Apache is building their binaries using
VC6 so wrong CRT gets loaded. The only solution I found was
to tell Windows to load Apache with msvcr80.dll instead of
msvcr.dll by suppling a manifest file in Apache bin
directory. If you crate Apache.exe.manifest that contains:
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1'
manifestVersion='1.0'>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC80.CRT'
version='8.0.50608.0' processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>
</assembly>
The Apache will load PHP and PHP will be able to load
extensions. It probably isn't good idea to force a different
C Runtime on Apache like this.
Regarding performance, I found that on Zend/bench.php the
improvement was only marginal (2%) compared to huge increase
(25-30%) when disabling thread support.
http://edin.dk/archives/25-Benchmarks.html
Edin
Andi Gutmans wrote:
Hi Edin,
Thanks for trying to get this to work!
I think eventually it'll be the right move to go to VC8 but I agree
that if it risks a successful 5.2.1 release then it might
not be worth
doing that right now. If you can share with us a
reproducing case we
can try and look into it and see if we can get it to work.
So far we
have concentrated on CLI/CGI/FastCGi because that's the
most feasible
way of running, but I agree that you also need to get the
other methods to run.
For those who are curious, there are some significant performance
improvements in VC8. Our tolower() optimization which is
significant
is only for VC8, the compiler creates significantly faster code (on
par with Intel C/C++ compiler), and I believe some of the CRT
functions like time() are also much faster. So I think it's
definitely
worth upgrading but it should be well timed.
Anyway, let us know and we'll try and dig deeper and help get this
puppy ported and update the build. There probably is some work that
needs to be done on the 3rd party libs.
Thanks.
Andi
-----Original Message-----
From: Edin Kadribasic [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 7:48 PM
To: PHP Internals List
Subject: [PHP-DEV] Windows build
Hey,
It seems that VC++ 8.0 (Visual Studio 2005) brings more
trouble that
its worth. Mainly the way it deals with the C runtime.
After spending
hours and hours of trying to figure out the way to make PHP work
under Apache on Windows and be able to load extensions,
I'm throwing
in the towel.
I can get PHP to work fine on the command line, both cgi
and cli. It
also works fine under IIS using fastcgi. But loading sapi
dll into a
webserver (not using php.exe or php-cgi.exe) works for the sapi
itself, but trying to load any extensions via php.ini fails
miserably. Sometimes you will get an error that the C runtime was
attempted to be loaded in an illegal way, sometime PHP will claim
that the extension does not exist, etc.
I looked around at other projects and everyone seems to be
using VC++
6.0 for their builds (Active state, apache, ...) which
eliminates all
the hassle with bundling C runtime, etc.
So I think the best thing for us would be to stick to the
good old C
compiler for making the Windows distro.
Edin
--
PHP Internals - PHP Runtime Development Mailing List To
unsubscribe,
visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
