Windows binaries 64bit for PHP

Hi,

ApacheLounge http://www.apachelounge.com/download/win64/
and MySQL http://www.mysql.com/downloads/mysql/5.5.html
gives us Windows 64 bit binaries for Apache and MySQL.

PHP does not do it!
Why? Could it be that complicated to compile for 32 AND 64 bit?

Dominique Ottello wrote:
> Hi,
>
> ApacheLounge http://www.apachelounge.com/download/win64/
> and MySQL http://www.mysql.com/downloads/mysql/5.5.html
> gives us Windows 64 bit binaries for Apache and MySQL.
>
> PHP does not do it!
> Why? Could it be that complicated to compile for 32 AND 64 bit?

Why don't Microsoft do it? All the Linuxes and Unixes does that.

--

//Aho

Arno Welzel <usenet@arnowelzel.de> écrivait :

> Why do you need 64 bit binaries?
Because 32 bit PHP binaries do not work with Apache 64 bit.

Gregor Kofler <usenet@gregorkofler.com> écrivait :

> <http://www.anindya.com/php-5-4-0-x64-64-bit-for-windows/>
>
> That was easy, wasn't it?
Oh yes ! I know. Anindya is my own source.
But the current PHP versions are 5.4.2 and 5.3.12
It will be a bit easier if PHP make them like Apache and MySQL.

Dominique Ottello, 06.05.2012 19:04:

> Arno Welzel <usenet@arnowelzel.de> écrivait :
>
>> Why do you need 64 bit binaries?
> Because 32 bit PHP binaries do not work with Apache 64 bit.

Ok - why do you need 64 bit at all for a web server?

I run a web server for multiple domains with more than 1 mio hits in
total per month where about 50% are handled by an Apache PHP module. I
also use XCache and so far neither Apache nor XCache are getting to any
limit (XCache runs fine with 128 MB cache and only uses about 60-70 MB
of it and the whole system does not allocate more than about 1,5-1,8 GB
of RAM).



--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

Arno Welzel wrote:
> Dominique Ottello, 06.05.2012 19:04:
>
>> Arno Welzel <usenet@arnowelzel.de> écrivait :
>>
>>> Why do you need 64 bit binaries?
>> Because 32 bit PHP binaries do not work with Apache 64 bit.
>
> Ok - why do you need 64 bit at all for a web server?
>
helps a lot when rescaling images on the fly...


> I run a web server for multiple domains with more than 1 mio hits in
> total per month where about 50% are handled by an Apache PHP module. I
> also use XCache and so far neither Apache nor XCache are getting to any
> limit (XCache runs fine with 128 MB cache and only uses about 60-70 MB
> of it and the whole system does not allocate more than about 1,5-1,8 GB
> of RAM).
>
>
>


--
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.

On 5/7/2012 3:23 PM, The Natural Philosopher wrote:
> Arno Welzel wrote:
>> Dominique Ottello, 06.05.2012 19:04:
>>
>>> Arno Welzel <usenet@arnowelzel.de> écrivait :
>>>
>>>> Why do you need 64 bit binaries?
>>> Because 32 bit PHP binaries do not work with Apache 64 bit.
>>
>> Ok - why do you need 64 bit at all for a web server?
>>
> helps a lot when rescaling images on the fly...
>
>
>> I run a web server for multiple domains with more than 1 mio hits in
>> total per month where about 50% are handled by an Apache PHP module. I
>> also use XCache and so far neither Apache nor XCache are getting to any
>> limit (XCache runs fine with 128 MB cache and only uses about 60-70 MB
>> of it and the whole system does not allocate more than about 1,5-1,8 GB
>> of RAM).
>>
>>
>>
>
>

Why would you repeatedly rescale images on the fly? You should know
what size you need for your pages and resize them once.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Mon, 07 May 2012 20:23:24 +0100, The Natural Philosopher wrote:
> Arno Welzel wrote:
>> Dominique Ottello, 06.05.2012 19:04:
>>
>>> Arno Welzel <usenet@arnowelzel.de> ??crivait :
>>>
>>>> Why do you need 64 bit binaries?
>>> Because 32 bit PHP binaries do not work with Apache 64 bit.
>>
>> Ok - why do you need 64 bit at all for a web server?
>>
> helps a lot when rescaling images on the fly...

Do you really do a lot of that, though? I mean, instead of pre-scaling
to a certain set number of sizes. Which seems more generally useful. If
you do, there's ways to handle that more rapidly and with less load than
the general purpose tools that PHP has wrappers for. EG: VIPS is
something like 4 times the speed at rescale than Gmagick.

--
I got told by a friend's ex-girlfriend that she could tell I was
a Linux geek from the way I *walked*.
-- Skud

On 5/7/12 2:49 PM, Peter H. Coffin wrote:
> On Mon, 07 May 2012 20:23:24 +0100, The Natural Philosopher wrote:
>> Arno Welzel wrote:
>>> Dominique Ottello, 06.05.2012 19:04:
>>>
>>>> Arno Welzel<usenet@arnowelzel.de> ??crivait :
>>>>
>>>>> Why do you need 64 bit binaries?
>>>> Because 32 bit PHP binaries do not work with Apache 64 bit.
>>>
>>> Ok - why do you need 64 bit at all for a web server?
>>>
>> helps a lot when rescaling images on the fly...
>
> Do you really do a lot of that, though? I mean, instead of pre-scaling
> to a certain set number of sizes. Which seems more generally useful. If
> you do, there's ways to handle that more rapidly and with less load than
> the general purpose tools that PHP has wrappers for. EG: VIPS is
> something like 4 times the speed at rescale than Gmagick.
>
I haven't been following this thread, but I'll talk about my personal
experience with image sizes.

My particular company has a huge catalog of images. Right now, we do
prescale the images to all the various sizes that might be needed, which
works alright except that our design department every once in a while
needs a new size. The amount of time required and effort to back-fill
the old data is relatively large, and we don't necessarily need every
size for every image (we just don't know where the images will show up
eventually).

Dynamic image scaling solves that problem nicely. With caching in place
of course.

On 5/7/2012 6:01 PM, Daniel Pitts wrote:
> On 5/7/12 2:49 PM, Peter H. Coffin wrote:
>> On Mon, 07 May 2012 20:23:24 +0100, The Natural Philosopher wrote:
>>> Arno Welzel wrote:
>>>> Dominique Ottello, 06.05.2012 19:04:
>>>>
>>>>> Arno Welzel<usenet@arnowelzel.de> ??crivait :
>>>>>
>>>>>> Why do you need 64 bit binaries?
>>>>> Because 32 bit PHP binaries do not work with Apache 64 bit.
>>>>
>>>> Ok - why do you need 64 bit at all for a web server?
>>>>
>>> helps a lot when rescaling images on the fly...
>>
>> Do you really do a lot of that, though? I mean, instead of pre-scaling
>> to a certain set number of sizes. Which seems more generally useful. If
>> you do, there's ways to handle that more rapidly and with less load than
>> the general purpose tools that PHP has wrappers for. EG: VIPS is
>> something like 4 times the speed at rescale than Gmagick.
>>
> I haven't been following this thread, but I'll talk about my personal
> experience with image sizes.
>
> My particular company has a huge catalog of images. Right now, we do
> prescale the images to all the various sizes that might be needed, which
> works alright except that our design department every once in a while
> needs a new size. The amount of time required and effort to back-fill
> the old data is relatively large, and we don't necessarily need every
> size for every image (we just don't know where the images will show up
> eventually).
>
> Dynamic image scaling solves that problem nicely. With caching in place
> of course.

I've had clients who have the same need. It's pretty simple to scale a
large number of images with a batch file (PHP, BASH, etc.), and proper
naming/cataloging takes care of the rest.

Who cares if you don't use all of the sizes? Disk space is cheap - much
cheaper than processor time.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On 5/7/12 5:15 PM, Jerry Stuckle wrote:
> On 5/7/2012 6:01 PM, Daniel Pitts wrote:
>> On 5/7/12 2:49 PM, Peter H. Coffin wrote:
>>> On Mon, 07 May 2012 20:23:24 +0100, The Natural Philosopher wrote:
>>>> Arno Welzel wrote:
>>>>> Dominique Ottello, 06.05.2012 19:04:
>>>>>
>>>>>> Arno Welzel<usenet@arnowelzel.de> ??crivait :
>>>>>>
>>>>>>> Why do you need 64 bit binaries?
>>>>>> Because 32 bit PHP binaries do not work with Apache 64 bit.
>>>>>
>>>>> Ok - why do you need 64 bit at all for a web server?
>>>>>
>>>> helps a lot when rescaling images on the fly...
>>>
>>> Do you really do a lot of that, though? I mean, instead of pre-scaling
>>> to a certain set number of sizes. Which seems more generally useful. If
>>> you do, there's ways to handle that more rapidly and with less load than
>>> the general purpose tools that PHP has wrappers for. EG: VIPS is
>>> something like 4 times the speed at rescale than Gmagick.
>>>
>> I haven't been following this thread, but I'll talk about my personal
>> experience with image sizes.
>>
>> My particular company has a huge catalog of images. Right now, we do
>> prescale the images to all the various sizes that might be needed, which
>> works alright except that our design department every once in a while
>> needs a new size. The amount of time required and effort to back-fill
>> the old data is relatively large, and we don't necessarily need every
>> size for every image (we just don't know where the images will show up
>> eventually).
>>
>> Dynamic image scaling solves that problem nicely. With caching in place
>> of course.
>
> I've had clients who have the same need. It's pretty simple to scale a
> large number of images with a batch file (PHP, BASH, etc.), and proper
> naming/cataloging takes care of the rest.
Pretty simple if you have a small enough set of images. The processor
time that would be needed to resize every last image in our catalog was
calculated in months. Making this a distributed task would be necessary,
and not entirely easy to do in PHP/BASH.

> Who cares if you don't use all of the sizes? Disk space is cheap - much
> cheaper than processor time.
>
Exactly true, but if you scale to sizes you don't need, you indeed use
more processor time! Our disk space is definitely not the bottleneck.

Daniel Pitts, 08.05.2012 05:37:

> On 5/7/12 5:15 PM, Jerry Stuckle wrote:
[...]
>> I've had clients who have the same need. It's pretty simple to scale a
>> large number of images with a batch file (PHP, BASH, etc.), and proper
>> naming/cataloging takes care of the rest.
> Pretty simple if you have a small enough set of images. The processor
> time that would be needed to resize every last image in our catalog was
> calculated in months. Making this a distributed task would be necessary,
> and not entirely easy to do in PHP/BASH.

Months?

You have to deal with several million images? Because otherwise its hard
to imagine that scaling images to a number of sizes - not print
resolutions since these images are only used for a web site - will take
*months*.



--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

El 06/05/2012 11:12, Dominique Ottello escribió/wrote:
> ApacheLounge http://www.apachelounge.com/download/win64/
> and MySQL http://www.mysql.com/downloads/mysql/5.5.html
> gives us Windows 64 bit binaries for Apache and MySQL.
>
> PHP does not do it!
> Why? Could it be that complicated to compile for 32 AND 64 bit?

Well... Last time I checked, official Apache 2.2 32-bit binaries were
using an obsolete compiler that would clash with PHP's more modern
binaries and there weren't official Apache 2.4 binaries at all, neither
32 nor 64. So I don't know if it's difficult (though it probably is,
given that you can hardly find unofficial standalone binaries out there)
but it's not true that Apache gets it right.

I've been using Anindya's binaries for a while, given that he's the only
one who's taken the time to compile the official MSI installers, and
I've found no problems so far, though of course that means you must
basically trust a stranger

http://www.anindya.com/

As an alternative, you can use a WAMP bundle like Xampp if you don't
mind the added complexity.


--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

On 5/7/2012 11:37 PM, Daniel Pitts wrote:
> On 5/7/12 5:15 PM, Jerry Stuckle wrote:
>> On 5/7/2012 6:01 PM, Daniel Pitts wrote:
>>> On 5/7/12 2:49 PM, Peter H. Coffin wrote:
>>>> On Mon, 07 May 2012 20:23:24 +0100, The Natural Philosopher wrote:
>>>>> Arno Welzel wrote:
>>>>>> Dominique Ottello, 06.05.2012 19:04:
>>>>>>
>>>>>>> Arno Welzel<usenet@arnowelzel.de> ??crivait :
>>>>>>>
>>>>>>>> Why do you need 64 bit binaries?
>>>>>>> Because 32 bit PHP binaries do not work with Apache 64 bit.
>>>>>>
>>>>>> Ok - why do you need 64 bit at all for a web server?
>>>>>>
>>>>> helps a lot when rescaling images on the fly...
>>>>
>>>> Do you really do a lot of that, though? I mean, instead of pre-scaling
>>>> to a certain set number of sizes. Which seems more generally useful. If
>>>> you do, there's ways to handle that more rapidly and with less load
>>>> than
>>>> the general purpose tools that PHP has wrappers for. EG: VIPS is
>>>> something like 4 times the speed at rescale than Gmagick.
>>>>
>>> I haven't been following this thread, but I'll talk about my personal
>>> experience with image sizes.
>>>
>>> My particular company has a huge catalog of images. Right now, we do
>>> prescale the images to all the various sizes that might be needed, which
>>> works alright except that our design department every once in a while
>>> needs a new size. The amount of time required and effort to back-fill
>>> the old data is relatively large, and we don't necessarily need every
>>> size for every image (we just don't know where the images will show up
>>> eventually).
>>>
>>> Dynamic image scaling solves that problem nicely. With caching in place
>>> of course.
>>
>> I've had clients who have the same need. It's pretty simple to scale a
>> large number of images with a batch file (PHP, BASH, etc.), and proper
>> naming/cataloging takes care of the rest.
> Pretty simple if you have a small enough set of images. The processor
> time that would be needed to resize every last image in our catalog was
> calculated in months. Making this a distributed task would be necessary,
> and not entirely easy to do in PHP/BASH.
>

That does not compute. Repeatedly resizing the images on the fly would
then take years.

>> Who cares if you don't use all of the sizes? Disk space is cheap - much
>> cheaper than processor time.
>>
> Exactly true, but if you scale to sizes you don't need, you indeed use
> more processor time! Our disk space is definitely not the bottleneck.

And if you repeatedly rescale the same image to the same size, you're
using even more processor time!

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On 5/8/12 5:21 AM, Jerry Stuckle wrote:
> On 5/7/2012 11:37 PM, Daniel Pitts wrote:
>> On 5/7/12 5:15 PM, Jerry Stuckle wrote:
>>> On 5/7/2012 6:01 PM, Daniel Pitts wrote:
>>>> On 5/7/12 2:49 PM, Peter H. Coffin wrote:
>>>>> On Mon, 07 May 2012 20:23:24 +0100, The Natural Philosopher wrote:
>>>>>> Arno Welzel wrote:
>>>>>>> Dominique Ottello, 06.05.2012 19:04:
>>>>>>>
>>>>>>>> Arno Welzel<usenet@arnowelzel.de> ??crivait :
>>>>>>>>
>>>>>>>>> Why do you need 64 bit binaries?
>>>>>>>> Because 32 bit PHP binaries do not work with Apache 64 bit.
>>>>>>>
>>>>>>> Ok - why do you need 64 bit at all for a web server?
>>>>>>>
>>>>>> helps a lot when rescaling images on the fly...
>>>>>
>>>>> Do you really do a lot of that, though? I mean, instead of pre-scaling
>>>>> to a certain set number of sizes. Which seems more generally
>>>>> useful. If
>>>>> you do, there's ways to handle that more rapidly and with less load
>>>>> than
>>>>> the general purpose tools that PHP has wrappers for. EG: VIPS is
>>>>> something like 4 times the speed at rescale than Gmagick.
>>>>>
>>>> I haven't been following this thread, but I'll talk about my personal
>>>> experience with image sizes.
>>>>
>>>> My particular company has a huge catalog of images. Right now, we do
>>>> prescale the images to all the various sizes that might be needed,
>>>> which
>>>> works alright except that our design department every once in a while
>>>> needs a new size. The amount of time required and effort to back-fill
>>>> the old data is relatively large, and we don't necessarily need every
>>>> size for every image (we just don't know where the images will show up
>>>> eventually).
>>>>
>>>> Dynamic image scaling solves that problem nicely. With caching in place
>>>> of course.
>>>
>>> I've had clients who have the same need. It's pretty simple to scale a
>>> large number of images with a batch file (PHP, BASH, etc.), and proper
>>> naming/cataloging takes care of the rest.
>> Pretty simple if you have a small enough set of images. The processor
>> time that would be needed to resize every last image in our catalog was
>> calculated in months. Making this a distributed task would be necessary,
>> and not entirely easy to do in PHP/BASH.
>>
>
> That does not compute. Repeatedly resizing the images on the fly would
> then take years.
>
>>> Who cares if you don't use all of the sizes? Disk space is cheap - much
>>> cheaper than processor time.
>>>
>> Exactly true, but if you scale to sizes you don't need, you indeed use
>> more processor time! Our disk space is definitely not the bottleneck.
>
> And if you repeatedly rescale the same image to the same size, you're
> using even more processor time!
>
Who said repeatedly rescale? The process I've been talking about is more
like "lazy" scaling.