Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:80482 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 35491 invoked from network); 14 Jan 2015 19:43:17 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Jan 2015 19:43:17 -0000 Authentication-Results: pb1.pair.com header.from=dmitry@zend.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=dmitry@zend.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.172 as permitted sender) X-PHP-List-Original-Sender: dmitry@zend.com X-Host-Fingerprint: 209.85.220.172 mail-vc0-f172.google.com Received: from [209.85.220.172] ([209.85.220.172:55516] helo=mail-vc0-f172.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 68/09-19120-4D6C6B45 for ; Wed, 14 Jan 2015 14:43:16 -0500 Received: by mail-vc0-f172.google.com with SMTP id hq11so3544502vcb.3 for ; Wed, 14 Jan 2015 11:43:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hk9rzBOzwqYuOSA86DCOcSzWl7qMAdcoOWWK6aBc95Q=; b=c5cqCGTskwoScpExO7cD07M3gYDEQfRNIITspF+BdOexJNQIzQ/3TiopMvqOiFjqHJ b6V4fR0fssWswZl9hQqKL9DNQRC0W0wjPdY6JD2aDeOEoarMfy8MOAgrPh3Sxy9245xq aLCvSMLOTF1bschw28lUg4mBfe8jcECWlikrZisEJVsSLaMujAA9UfdempDpPxxW7qMq i1GD6ZVkQMZNSLMj2/stHaaiM5D2koHPvbs0jFcoI4hMTTMw6u6FAR3dFt1KuRShtEDc RQJF4dQGt9i+0pGxcw7yMROLM0GZFJwsSC5CEEsABUnzaXSi+uPb84jlkTmQiuTBcZMv WDpQ== X-Gm-Message-State: ALoCoQmpaBrZaIFVsA7Q5/aAOmi8PTUAjZUkaxPDSiMKMpKAIbbefiOhMgA/q4+NlBeBqTz/dRlaFFkPD/ymvT65Hyi77K3VO1fxEUXTReMepnMy3Ano3v4IFTIdBUGJJOX8Rv09Bm8Fy1K5OV1ogZjEISc0ZQa8yg== MIME-Version: 1.0 X-Received: by 10.220.69.68 with SMTP id y4mr3816719vci.21.1421264593526; Wed, 14 Jan 2015 11:43:13 -0800 (PST) Received: by 10.52.26.40 with HTTP; Wed, 14 Jan 2015 11:43:13 -0800 (PST) In-Reply-To: References: <8C47FA53-0964-49C0-963C-332A936348A5@ajf.me> <68229C26-4EEC-49DC-BA05-D5AC9728D1E8@ajf.me> <93376D88-A704-4F89-AB90-82EEDAE82081@ajf.me> Date: Wed, 14 Jan 2015 23:43:13 +0400 Message-ID: To: Andrea Faulds Cc: PHP Internals Content-Type: multipart/alternative; boundary=047d7b3a92523ab997050ca1f35c Subject: Re: [PHP-DEV] [RFC] Big Integer Support From: dmitry@zend.com (Dmitry Stogov) --047d7b3a92523ab997050ca1f35c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Andrea, Where can I get the code? Thanks. Dmitry. On Thu, Jan 8, 2015 at 7:02 PM, Dmitry Stogov wrote: > I'm really surprised by the results :) > I'll try to find time for bigint on next week and play with it a bit. > > Thanks. Dmitry. > > > On Wed, Jan 7, 2015 at 2:54 AM, Andrea Faulds wrote: > >> Hey Dmitry, >> >> > On 23 Oct 2014, at 16:22, Dmitry Stogov wrote: >> > >> >> I=E2=80=99ve so far been scared to touch the asm=E2=80=A6 but actuall= y, I don=E2=80=99t think >> it >> >> could be *that* hard. It=E2=80=99s not doing something especially com= plex. The >> >> bigint API looks fairly stable now and I=E2=80=99m unlikely to change= it much >> >> further, so there=E2=80=99s little worry about having to change the a= sm a >> second >> >> time. The main problem with asm, I suppose, is testing it. I do have = a >> >> 32-bit Ubuntu VM set up, but I=E2=80=99d also need to set up Windows = VMs, and >> >> possibly others (don=E2=80=99t we have PowerPC in the source just now= ?). >> >> >> > >> > change asm for 32-bit Linux and add TODO marks for others. I don't tes= t >> PHP >> > on PPC as well. >> >> After procrastinating about this for a long time, I finally went and >> updated the overflow checks today and ran bench.php. >> >> I still haven=E2=80=99t touched the inline asm, I=E2=80=99ve just remove= d it, since clang >> and GCC (only in GCC 5.0, sadly) have checked arithmetic intrinsics. If >> someone wants to, they can rewrite the inline asm for compilers that hav= e >> no overflow-checking intrinsics, but this is good enough for now, at lea= st >> for the purposes of performance checking on my machine. I=E2=80=99m usin= g clang, by >> the way. If you want to replicate these results, you=E2=80=99ll probably= also need >> it, since GCC 5.0 isn=E2=80=99t out yet, unfortunately. >> >> I compiled the bigint-libtommath branch (theoretically this was just a >> branch, but actually all the new changes have gone there, I=E2=80=99ll m= erge it >> into the bigint branch once LibTomMath port is done), and the current >> master branch. >> >> For bigint-libtommath, I used ./configure --enable-debug --enable-phpdbg >> =E2=80=94-disable-all =E2=80=94-enable-bigint-gmp >> >> Because of the =E2=80=94-enable-bigint-gmp flag, it=E2=80=99s using the = GMP backend, not >> the LibTomMath one. I=E2=80=99m doing this since there=E2=80=99s still o= ne or two small >> things I haven=E2=80=99t finished implementing for LibTomMath, e.g. the = binary >> bitwise ops have the wrong behaviour just now. >> >> For master, I used ./configure --enable-debug --enable-phpdbg >> =E2=80=94-disable-all >> >> Then, I ran bench.php four times, and each time I ran it first on >> ./php-bigint-gmp, then on ./php-bigint-master. >> >> On each run, the bigint branch turned out faster, as well as overall: >> >> bigint master >> 6.593 6.659 >> 6.424 6.661 >> 6.414 6.588 >> 6.381 6.673 >> AVERAGE >> 6.453 6.64525 >> DIFFERENCE >> -0.19225 0.19225 >> RATIO >> 0.971069561 1.0297923446 >> >> So master is 2.9% slower! Full output here: >> https://gist.github.com/TazeTSchnitzel/759c1513b442571f5e26 >> >> I can=E2=80=99t actually explain why bigints would be faster. It might j= ust be >> because I got rid of fast_increment_function in favour of just checking = of >> op1 =3D=3D ZEND_LONG_MAX in zend_vm_execute.h, ditto for >> fast_decrement_function. Maybe using overflow intrinsics is faster than >> inline asm. Maybe it=E2=80=99s something completely different. I honestl= y don=E2=80=99t >> know. >> >> The result surprised me as I expect bigints would be slower, so I redid >> it. Again, bigints came out on top: >> >> bigint master >> 6.55 6.779 >> 6.353 6.738 >> 6.326 6.674 >> 6.144 6.177 >> AVERAGE >> 6.34325 6.592 >> DIFFERENCE >> -0.24875 0.24875 >> RATIO >> 0.9622648665 1.0392149135 >> >> This time master was around 3.9% slower. Full log here: >> https://gist.github.com/TazeTSchnitzel/59c190b86c9dd5b20570 >> >> If we combine the two runs: >> >> bigint master >> 6.593 6.659 >> 6.424 6.661 >> 6.414 6.588 >> 6.381 6.673 >> 6.55 6.779 >> 6.353 6.738 >> 6.326 6.674 >> 6.144 6.177 >> AVERAGE >> 6.398125 6.618625 >> DIFFERENCE >> -0.2205 0.2205 >> RATIO >> 0.9666849232 1.0344632216 >> >> master=E2=80=99s 3.4% slower. >> >> Just to check I named the files correctly: >> >> oa-res-26-240:php-src ajf$ ./php-master -r 'var_dump(PHP_INT_MAX * 2);' >> float(1.844674407371E+19) >> oa-res-26-240:php-src ajf$ ./php-bigint-gmp -r 'var_dump(PHP_INT_MAX * >> 2);' >> int(18446744073709551614) >> >> Yes, it=E2=80=99s definitely the bigint branch. >> >> So, at least by these preliminary results, the bigint branch would appea= r >> to be faster than master. This is merely bench.php, but it=E2=80=99s sti= ll a good >> sign. :) >> >> Thanks! >> -- >> Andrea Faulds >> http://ajf.me/ >> >> >> >> >> > --047d7b3a92523ab997050ca1f35c--