Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:57411 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 53472 invoked from network); 18 Jan 2012 12:13:18 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Jan 2012 12:13:18 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.20.127 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 213.123.20.127 c2bthomr09.btconnect.com Received: from [213.123.20.127] ([213.123.20.127:42916] helo=mail.btconnect.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4C/D6-21653-B57B61F4 for ; Wed, 18 Jan 2012 07:13:16 -0500 Received: from host81-138-11-136.in-addr.btopenworld.com (EHLO _10.0.0.4_) ([81.138.11.136]) by c2bthomr09.btconnect.com with ESMTP id FZB97718; Wed, 18 Jan 2012 12:13:13 +0000 (GMT) Message-ID: <4F16B758.7010206@lsces.co.uk> Date: Wed, 18 Jan 2012 12:13:12 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0.1) Gecko/20111220 Firefox/9.0.1 SeaMonkey/2.6.1 MIME-Version: 1.0 To: PHP internals References: <4F16AB37.1070107@lsces.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mirapoint-IP-Reputation: reputation=Good-1, source=Queried, refid=tid=0001.0A0B0301.4F16B758.0140, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.1.18.111216:17:7.586, ip=81.138.11.136, rules=__MOZILLA_MSGID, __HAS_MSGID, __SANE_MSGID, __USER_AGENT, __MIME_VERSION, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __CT, __CT_TEXT_PLAIN, __CTE, __ANY_URI, __CP_URI_IN_BODY, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4F16B759.0071:SCFSTAT14830815,ss=1,re=-4.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Subject: Re: [PHP-DEV] 64bit Windows builds From: lester@lsces.co.uk (Lester Caine) Pierre Joye wrote: > Lester, > > On Wed, Jan 18, 2012 at 12:21 PM, Lester Caine wrote: >> 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