php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #70621 gmp on windows much faster with php 5.2
Submitted: 2015-10-02 10:23 UTC Modified: 2015-10-16 10:37 UTC
From: anna1008 at t-online dot de Assigned:
Status: Open Package: Performance problem
PHP Version: 5.6.14 OS: Windows 7 Home Premium 32bit SP1
Private report: No CVE-ID: None
View Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
10 + 18 = ?
Subscribe to this entry?

 
 [2015-10-02 10:23 UTC] anna1008 at t-online dot de 
Description:
------------
I've experienced slow performance of the recent VC11 builds compared to the old VC6 builds when running gmp_*-functions on big integers. My test script factorizes the first 1,000 integers >= 2^16, 2^24 and 2^32 with trial division. All tests were executed in CLI and shared the same php.ini (default production-ini just with gmp extension).





Test script:
---------------
<?php
for ($e = 16; $e <= 32; $e+=8) { # 16, 24, 32
	$n = gmp_pow(2, $e); # n := 2^e
	$t0 = microtime(true);
	for ($i = 0; $i < 1000; $i++) {
		trialdiv($n);
		$n = gmp_add($n, 1); # n++
	}
	$dt = microtime(true) - $t0;
	echo phpversion() . " e=$e dt=$dt sec\n";
}
	
function trialdiv($n) {
	if (gmp_prob_prime($n) != 0) return; # n is probably or surely prime
	$p = gmp_init(2); # start with prime 2
	for (;;) {
		if (gmp_cmp(gmp_mul($p, $p), $n) > 0) return; # p^2 > n, trial division complete
		while (gmp_cmp(gmp_mod($n, $p), 0) == 0) $n = gmp_divexact($n, $p); # while p divides n do n:= n/p
		$p = gmp_nextprime($p); # try next prime		
	}
}
?>

Expected result:
----------------
I've expected marginal performance differences between the old VC6-builds and the recent VC11-builds.

Actual result:
--------------
my results with php-5.2.14-Win32-VC6-x86:

5.2.14 e=16 dt=0.046411037445068 sec
5.2.14 e=24 dt=0.27050685882568 sec
5.2.14 e=32 dt=2.0851769447327 sec

my results with php-5.6.14-Win32-VC11-x86:

5.6.14 e=16 dt=0.046800136566162 sec
5.6.14 e=24 dt=0.51480078697205 sec
5.6.14 e=32 dt=8.533215045929 sec

summary:
At 2^16 the differences are marginal.
At 2^24 the VC6-build is 1.9 times faster
At 2^32 the VC6-build is 4.1 times faster.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-10-03 07:57 UTC] nikic@php.net 
I can confirm that there is a large GMP slowdown between PHP 5.3 and 5.4, at least on Windows. I kindof doubt this is related to VC versions though.
 [2015-10-03 11:58 UTC] anna1008 at t-online dot de 
@nikic:
Yes, it's better to say: "the 5.2-build is much faster than the following builds". I didn't want to relate it to the compiler or anything else. But I wouldn't exclude the compiler as a reason, when I consider that I need to install a Microsoft "Visual C++ Redistributable" to run the builds...

Here are more results with all available lastest 5.x-builds.
When I look at the php-gmp-changelog I can only see one big change:
the change from php resource to php object in 5.6
(other changes are mostly adding of missing gmp-functions).
But the slowdown already began with 5.3 and became real big with 5.4.

my results with php-5.2.17-Win32-VC6-x86:

5.2.17 e=16 dt=0.047152042388916 sec
5.2.17 e=24 dt=0.27974796295166 sec
5.2.17 e=32 dt=2.1529459953308 sec

my results with php-5.3.29-Win32-VC9-x86:

5.3.29 e=16 dt=0.060003995895386 sec
5.3.29 e=24 dt=0.39502215385437 sec
5.3.29 e=32 dt=3.2831878662109 sec

my results with php-5.4.45-Win32-VC9-x86:

5.4.45 e=16 dt=0.052003145217896 sec
5.4.45 e=24 dt=0.58403301239014 sec
5.4.45 e=32 dt=9.3995378017426 sec

my results with php-5.5.30-Win32-VC11-x86:

5.5.30 e=16 dt=0.051002025604248 sec
5.5.30 e=24 dt=0.55403208732605 sec
5.5.30 e=32 dt=8.8055038452148 sec

my results with php-5.6.14-Win32-VC11-x86:

5.6.14 e=16 dt=0.046002864837646 sec
5.6.14 e=24 dt=0.51803016662598 sec
5.6.14 e=32 dt=8.6654949188232 sec
.
 [2015-10-03 13:20 UTC] anna1008 at t-online dot de
-Summary: gmp much faster with old VC6-builds +Summary: gmp on windows much faster with php 5.2
 [2015-10-03 13:20 UTC] anna1008 at t-online dot de 
I don't have a linux environment installed, but my provider offers different php versions.  Here are the results with Ubuntu/Apache mod:

5.2.17-nmm2 e=16 dt=0.100540876389 sec
5.2.17-nmm2 e=24 dt=0.789358854294 sec
5.2.17-nmm2 e=32 dt=6.72271108627 sec

5.3.28-nmm4 e=16 dt=0.107861995697 sec
5.3.28-nmm4 e=24 dt=0.798853874207 sec
5.3.28-nmm4 e=32 dt=6.73689603806 sec

5.4.42-nmm1 e=16 dt=0.105895042419 sec
5.4.42-nmm1 e=24 dt=0.763396978378 sec
5.4.42-nmm1 e=32 dt=6.51089191437 sec

5.5.26-nmm1 e=16 dt=0.111220121384 sec
5.5.26-nmm1 e=24 dt=0.796920061111 sec
5.5.26-nmm1 e=32 dt=6.52268314362 sec

5.6.10-nmm1 e=16 dt=0.0878250598907 sec
5.6.10-nmm1 e=24 dt=0.723581075668 sec
5.6.10-nmm1 e=32 dt=6.16323590279 sec

No big differences, but all also much slower than php-5.2.17-Win32-VC6-x86 in CLI mode.
 [2015-10-16 10:37 UTC] ab@php.net 
@anna1008, the Ubuntu experiment shows, that it's not PHP. MPIR (and GMP) have quite some optimization variants. Some are generic, some target certain processors. That's what is to see - on Ubuntu PHP 5.2 and 5.6 are of nearly same speed. It's because the GMP build variant on Ubuntu is made with same optimizations.

On the Windows side, MPIR is being built statically and for a generic processor. We could look to improve it a bit, should inspect whether some new optimized build variants are available in MPIR 2.7. I doubt it can be improved for x64, but for x86. 

On Windows side one could actually do a more complex approach - do all the build variants for all the processor optimizations as a separate DLL, and then load the best DLL at runtime. However it can and will get very messy to automate as one has to determine what exact processor is used, at run time. What probably could work is that linking ext/mpir with some DLL and supplying a full set of DLLs elsewhere, so users can fetch some dedicated for a certain processor (or a generic). But that sounds not good enough to me, too. At least that sounds as quite a big effort for a little gain.

Thanks.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Oct 29 04:00:01 2025 UTC