Hello all,
I've noticed that on windows.php.net that all the builds are x86. I
was wondering if there is any reason (technical or not) not to
distribute x64 builds as well there. It's quite annoying having to
constantly drop to a VM every time I need to test something that's 64
bit dependent...
Just a thought.
Thanks,
Anthony
hi,
Yes, there is a reason.
We do not support x64 binaries yet, for php itself and many libs used
by PHP. Some argues that it is safe. Btw, it is not faster to run on
x64 either.
php-next will have x64 support tho'.
Cheers,
Hello all,
I've noticed that on windows.php.net that all the builds are x86. I
was wondering if there is any reason (technical or not) not to
distribute x64 builds as well there. It's quite annoying having to
constantly drop to a VM every time I need to test something that's 64
bit dependent...Just a thought.
Thanks,
Anthony
--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre Joye wrote:
Yes, there is a reason.
We do not support x64 binaries yet, for php itself and many libs used
by PHP. Some argues that it is safe. Btw, it is not faster to run on
x64 either.
Pierre ... please do not continue that statement without any evidence. ALL of
the benchmarks I've run on an identical hardware base with 64 bit Windows7 show
at least a 10% faster performance using a 64bit build of PHP. Speed improvements
are even more when all of the elements of the stack are 64bit, but even just
running 64bit PHP has an improvement. It would probably be useful to benchmark
32bit windows on the same hardware, but I don't have time to do that and the
machine was supplied with a 64bit W7, so I dn't hame a 32bit version of W7.
Of cause running 64bit Linux on the same hardware is at least 3 times faster
than the windows setup, and the machine is now just running Linux.
--
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//
Firebird - http://www.firebirdsql.org/index.php
Lester,
Pierre Joye wrote:
Yes, there is a reason.
We do not support x64 binaries yet, for php itself and many libs used
by PHP. Some argues that it is safe. Btw, it is not faster to run on
x64 either.Pierre ... please do not continue that statement without any evidence. ALL
of the benchmarks I've run on an identical hardware base with 64 bit
Windows7 show at least a 10% faster performance using a 64bit build of PHP.
Speed improvements are even more when all of the elements of the stack are
64bit, but even just running 64bit PHP has an improvement. It would probably
be useful to benchmark 32bit windows on the same hardware, but I don't have
time to do that and the machine was supplied with a 64bit W7, so I dn't hame
a 32bit version of W7.Of cause running 64bit Linux on the same hardware is at least 3 times faster
than the windows setup, and the machine is now just running Linux.
This answer (totally uninformed and ignoring the main reason why we do
not support 64bit yet) is exactly what I warned about. Performance, if
it was faster (and it is not), is only the 3rd or 4th reason why we
cannot support x64 builds yet. Understand it.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre Joye wrote:
Lester,
Pierre Joye wrote:
Yes, there is a reason.
We do not support x64 binaries yet, for php itself and many libs used
by PHP. Some argues that it is safe. Btw, it is not faster to run on
x64 either.Pierre ... please do not continue that statement without any evidence. ALL
of the benchmarks I've run on an identical hardware base with 64 bit
Windows7 show at least a 10% faster performance using a 64bit build of PHP.
Speed improvements are even more when all of the elements of the stack are
64bit, but even just running 64bit PHP has an improvement. It would probably
be useful to benchmark 32bit windows on the same hardware, but I don't have
time to do that and the machine was supplied with a 64bit W7, so I dn't hame
a 32bit version of W7.Of cause running 64bit Linux on the same hardware is at least 3 times faster
than the windows setup, and the machine is now just running Linux.This answer (totally uninformed and ignoring the main reason why we do
not support 64bit yet) is exactly what I warned about. Performance, if
it was faster (and it is not), is only the 3rd or 4th reason why we
cannot support x64 builds yet. Understand it.
Why not explain that better then? Rather than throwing in what is an incorrect
claim. I've PUBLISHED the performance figures (using the php benchmark
programs!)... and we have documented what 64bit stack works fine and passes all
the production tests. YES the 64bit build has a number of problems, and throws
lots of warnings when compiling, but using performance as a reason for why they
are not supported is not valid. There has been nothing posted to show why the
figures I am getting are wrong?
A much better reason for not supporting the build is probably that the 64bit
compiler is not available in the free development stack? We have to buy a
development stack to get the 64bit compiler which blocks rather than working
with the publicly available process :( But actually that is a better reason for
supplying a 64 bit build, and why others are providing that service.
--
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//
Firebird - http://www.firebirdsql.org/index.php
A much better reason for not supporting the build is probably that the 64bit compiler is
not available in the free development stack? We have to buy a development stack to get the
64bit compiler which blocks rather than working with the publicly available process :(
But actually that is a better reason for supplying a 64 bit build, and why others are
providing that service.
Actually, no. There are any number of free mechanisms to build 64 bit code.
The root problem is that Windows "WIN64" is a 64P architecture. Linux and
*nix variants, on the other hand, are 64ILP or 64LP. Meaning Windows has
longs/ints which are undersized compared to the *nix brethren. The old and
stale abuse such as unsigned long X = (unsigned long)pY; will not do what
the author intended.
This means all packages ported to *nix 64 bits may have very serious flaws
which have not been fixed for Windows 64 bit architecture. I'd anticipate
CoApp identifying and resolving most of these applicable to PHP over the
coming months, but it is a non-trivial problem requiring a number of pairs
of eyeballs to get right.
William A. Rowe Jr. wrote:
A much better reason for not supporting the build is probably that the 64bit compiler is
not available in the free development stack? We have to buy a development stack to get the
64bit compiler which blocks rather than working with the publicly available process:(
But actually that is a better reason for supplying a 64 bit build, and why others are
providing that service.
Actually, no. There are any number of free mechanisms to build 64 bit code.
Could you elaborate on that?
Building 64bit windows applications which are VC9 compliant would seem to need
the 'official' compiler, and while I have not done a lot of looking, there was
nothing being offered when I tried to set up the windows build environment form
Pierre's original notes although that was some time ago. I ended up buying an M$
development pack to plug the hole.
The root problem is that Windows "WIN64" is a 64P architecture. Linux and
*nix variants, on the other hand, are 64ILP or 64LP. Meaning Windows has
longs/ints which are undersized compared to the *nix brethren. The old and
stale abuse such as unsigned long X = (unsigned long)pY; will not do what
the author intended.This means all packages ported to nix 64 bits may have very serious flaws
which have not been fixed forWindows 64 bit* architecture. I'd anticipate
CoApp identifying and resolving most of these applicable to PHP over the
coming months, but it is a non-trivial problem requiring a number of pairs
of eyeballs to get right.
I do accept that there are inherent problems with the current unsupported
builds, my own sites have not had any errors in serving PHP pages via a 64bit
Apache/PHP/Firebird stack on 64 bit windows XP. But I am more than happy to help
if a serious effort is made to tidy this up, and I still have two sites that I
can soak test on, although one of them is scheduled to switch to Linux in the
next six months.
--
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//
Firebird - http://www.firebirdsql.org/index.php
William A. Rowe Jr. wrote:
A much better reason for not supporting the build is probably that the 64bit
compiler is
not available in the free development stack? We have to buy a development stack to
get the
64bit compiler which blocks rather than working with the publicly available process:(
But actually that is a better reason for supplying a 64 bit build, and why others are
providing that service.
Actually, no. There are any number of free mechanisms to build 64 bit code.
Could you elaborate on that?
Building 64bit windows applications which are VC9 compliant would seem to need the
'official' compiler, and while I have not done a lot of looking, there was nothing being
offered when I tried to set up the windows build environment form Pierre's original notes
although that was some time ago. I ended up buying an M$ development pack to plug the hole.
The SDK and DDK remain free with a minimal toolchain, including 64 bit
compilers. Of course they aren't called that anymore, because things
are only fun in the Windows world when they overhaul the glossary of
terms every 3 years.
You probably started with Express edition of Visual Studio, and I note
that it claims not to support 64 bit. But the compilers in the SDK or WDK
(Windows Drivers Kit formerly DDK) should solve your issue. I don't know
offhand whether these contain visual studio 15 or 16.
On Wed, Jan 18, 2012 at 8:25 PM, William A. Rowe Jr.
wrowe@rowe-clan.net wrote:
The SDK and DDK remain free with a minimal toolchain, including 64 bit
compilers. Of course they aren't called that anymore, because things
are only fun in the Windows world when they overhaul the glossary of
terms every 3 years.
The SDK only supports 64bit now too? I remember it was not the case,
but if yes that's pretty good :). VS Express editions do not, but
that's not really a problem :)
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi,
On Wed, Jan 18, 2012 at 6:37 PM, William A. Rowe Jr.
wrowe@rowe-clan.net wrote:
A much better reason for not supporting the build is probably that the 64bit compiler is
not available in the free development stack? We have to buy a development stack to get the
64bit compiler which blocks rather than working with the publicly available process :(
But actually that is a better reason for supplying a 64 bit build, and why others are
providing that service.Actually, no. There are any number of free mechanisms to build 64 bit code.
None of them are part of what we support tho' (we do not support mingw
for example, and won't support it).
The root problem is that Windows "WIN64" is a 64P architecture. Linux and
*nix variants, on the other hand, are 64ILP or 64LP. Meaning Windows has
longs/ints which are undersized compared to the *nix brethren. The old and
stale abuse such as unsigned long X = (unsigned long)pY; will not do what
the author intended.This means all packages ported to *nix 64 bits may have very serious flaws
which have not been fixed for Windows 64 bit architecture.
That's a perfect good example of the numerous issues, and not only in
PHP itself but in all dependencies.
I'd anticipate
CoApp identifying and resolving most of these applicable to PHP over the
coming months, but it is a non-trivial problem requiring a number of pairs
of eyeballs to get right.
Not going to be supported by PHP any time soon, so I won't hold my
breath or put one cent on that tool at this stage (for php, as it is
what I can talk about right now).
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Actually, no. There are any number of free mechanisms to build 64 bit code.
None of them are part of what we support tho' (we do not support mingw
for example, and won't support it).
Actually, why couldn't mingw be supported one day?
(supposing someone did the work to change half the PHP_WIN defines to
PHP_MSVC)
Such binaries wouldn't be compatible with IIS, but mingw seems
preferible to the
legacy VC6 for use with the oficial Apache binaries.
2012/1/19 Ángel González keisial@gmail.com:
Actually, why couldn't mingw be supported one day?
(supposing someone did the work to change half the PHP_WIN defines to
PHP_MSVC)
Too painful, somehow buggy (while it is way better lately) but the
main reason is total lack of binary compatibility with supported VC
versions. And we do not have the resources to provide support for more
than one compiler version at a time.
Such binaries wouldn't be compatible with IIS, but mingw seems preferible to
the
legacy VC6 for use with the oficial Apache binaries.
There is no such thing like "official apache binaries", they provide
some as conveniences.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
2012/1/19 Ángel González keisial@gmail.com:
Such binaries wouldn't be compatible with IIS, but mingw seems preferible
to the legacy VC6 for use with the oficial Apache binaries.
A couple of things to remember; msvcrt.dll is quite actively maintained,
even when it's maintained against the interests of php or the c language
standards bodies. This would not be true of msvcr70.dll, for example.
Actively supported is msvcr100.dll, of VisualStudio 2010, and that is what
the httpd project expects to ship some httpd 2.4.0 binaries with. But the
msvcrt.dll itself is neither less or more maintained so far than the
per-studio-release flavor. It's a shame that the NT/kernel team and the
VisualStudio team simply can't get along.
Any mingw/gcc build is going to bind right back to msvcrt.dll, nullifying
whatever train of thought you were pursuing. There are php-specific
defects that MS has chosen to err on the side of incompatibility to spec.
There is no such thing like "official apache binaries", they provide
some as conveniences.
Just as with php; these are open source, we give you the source. What
you the user proceed to do with it is with our blessings :) This is one
of the advantages of keeping build systems and dependencies as accessible
as possible, something I consider a flaw in php's win (and aix, solaris
and hpux support), and a laudable goal of the coapp effort (all the way
through pushing upstream their own shallow fork fixes).
hi Bill,
2012/1/20 William A. Rowe Jr. wrowe@rowe-clan.net:
2012/1/19 Ángel González keisial@gmail.com:
Such binaries wouldn't be compatible with IIS, but mingw seems preferible
to the legacy VC6 for use with the oficial Apache binaries.A couple of things to remember; msvcrt.dll is quite actively maintained,
even when it's maintained against the interests of php or the c language
standards bodies. This would not be true of msvcr70.dll, for example.
Actively supported is msvcr100.dll, of VisualStudio 2010, and that is what
the httpd project expects to ship some httpd 2.4.0 binaries with. But the
msvcrt.dll itself is neither less or more maintained so far than the
per-studio-release flavor. It's a shame that the NT/kernel team and the
VisualStudio team simply can't get along.
Build tools suite and the crt available by default with windows are
totally different stories. Support VC compilers today (and for the
next couple of years) are VC9 and later (don't remember the state of
VC8 right now). And VC6 is dead. Mingw is barely a solution, sorry,
not only because of its VC6 binaries but its set of tools as well.
Any mingw/gcc build is going to bind right back to msvcrt.dll, nullifying
whatever train of thought you were pursuing. There are php-specific
defects that MS has chosen to err on the side of incompatibility to spec.
Not sure to understand what you try to say here. I suppose it is about
the incompatibilities between the various CRTs.
There is no such thing like "official apache binaries", they provide
some as conveniences.Just as with php; these are open source, we give you the source.
Wrong, we do provide official binaries that we support. This is
totally different than what is done in Apache.
What
you the user proceed to do with it is with our blessings :) This is one
of the advantages of keeping build systems and dependencies as accessible
as possible, something I consider a flaw in php's win (and aix, solaris
and hpux support).
What you call a flaw, we call it reliability and easiness, for windows.
For Solaris, hpux or other aix, I never understood why they do not
provide native out of the box gcc+posix support in the same way *BSDs
do, but that's another story.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Perfect, thanks.
And to be fair, I don't care about performance. I would like 64 bit integers...
Anthony
hi,
Yes, there is a reason.
We do not support x64 binaries yet, for php itself and many libs used
by PHP. Some argues that it is safe. Btw, it is not faster to run on
x64 either.php-next will have x64 support tho'.
Cheers,
Hello all,
I've noticed that on windows.php.net that all the builds are x86. I
was wondering if there is any reason (technical or not) not to
distribute x64 builds as well there. It's quite annoying having to
constantly drop to a VM every time I need to test something that's 64
bit dependent...Just a thought.
Thanks,
Anthony
--
--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org