Re: [PHP-DEV] Optimization for ..._MULTIPLY_LONG on more systems
On 17.07.2008, at 16:20, Matt Wilmas wrote: Hi all, Replying to this OLD message about the ZEND_SIGNED_MULTIPLY_LONG() change... It's just a small thing, but it's been on the TODO for a while, so I attempted to correct the issue with my original patch that used "long long" type, which wasn't available on the older MSVC versions, etc. I created a zend_long64 type (when possible, #if logic copied from snprintf.h's WIDE_INT definition), hopefully it's mostly correct/OK, and maybe it can be used elsewhere too. Since the new memory manager, ..._MULTIPLY_LONG() isn't used for safe_emalloc() anymore, so I made another safe_address() variation (overflow safe, I hope). I noticed ~0.6% slowdown on bench.php, though it seems this zend_ulong64 version should use fewer cycles than the doubles one for sure, if someone wants to analyze it more. :-) Finally, is it even possible to also have a Windows assembly version of these 2 things, where I left the comments? There is for zend_mm_[high|low]_bit(), but they're very simple... http://realplain.com/php/multiply_long.diff http://realplain.com/php/multiply_long_5_3.diff any takers for this patch? otherwise it will probably not make the cut by the 24th regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Optimization for ..._MULTIPLY_LONG on more systems
Hi all, Replying to this OLD message about the ZEND_SIGNED_MULTIPLY_LONG() change... It's just a small thing, but it's been on the TODO for a while, so I attempted to correct the issue with my original patch that used "long long" type, which wasn't available on the older MSVC versions, etc. I created a zend_long64 type (when possible, #if logic copied from snprintf.h's WIDE_INT definition), hopefully it's mostly correct/OK, and maybe it can be used elsewhere too. Since the new memory manager, ..._MULTIPLY_LONG() isn't used for safe_emalloc() anymore, so I made another safe_address() variation (overflow safe, I hope). I noticed ~0.6% slowdown on bench.php, though it seems this zend_ulong64 version should use fewer cycles than the doubles one for sure, if someone wants to analyze it more. :-) Finally, is it even possible to also have a Windows assembly version of these 2 things, where I left the comments? There is for zend_mm_[high|low]_bit(), but they're very simple... http://realplain.com/php/multiply_long.diff http://realplain.com/php/multiply_long_5_3.diff - Matt - Original Message - From: "Matt Wilmas" Sent: Wednesday, November 08, 2006 > Hi, > > Here's an additional ZEND_SIGNED_MULTIPLY_LONG() for platforms with 32-bit > longs that don't use the assembly version (so all Windows systems at > least?). On my Windows system, mul_function() is 40% faster with this > version (no overflow), which makes PHP's * operator 20% faster; with > overflow mul_function() is 20% faster (though I don't see any difference > with the * operator). The macro is also used in safe_emalloc()... > > Patch just against 5_2 as the file versions are the only difference. > > > Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Optimization for ..._MULTIPLY_LONG on more systems
> Did it not work for you as-is on Windows...? It did for me, since it seems > there's already a typedef for __int64 -> long long. I'd wondered the same, I think some VC versions on windows don't know "long long" but do know __int64, but I don't remember from the top of my head which version, but I think maybe VC6 might have a problem with that. Otherwise looks fine, so if adjusted for VC6 it's OK. I forgot to mention that I had seen this in main/config.w32.h: /* MSVC.6/NET don't allow 'long long' or know 'intmax_t' */ #define SIZEOF_LONG_LONG_INT 0 #define SIZEOF_LONG_LONG 8 /* defined as __int64 */ SIZEOF_LONG_LONG was changed from 0 to 8 in v1.86 and the comment about __int64 added. So, I also assumed "long long" could be used as-is because of that. Why have SIZEOF as 8 if it's unusable...? It was changed to fix Bug #34052, I know, but I wouldn't think it was just a "hack" to make it non-zero -- especially with the __int64 comment. yes, it is just an "hack". (/me hides). But anyway, I'll leave it to the experts if the patch needs tweaking. ;-) Me too, as I don't have karma on that module. Nuno -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Optimization for ..._MULTIPLY_LONG on more systems
Hi Andi, - Original Message - From: "Andi Gutmans" Sent: Wednesday, November 08, 2006 > Nice patch! Looks good to me... Any other thoughts? Since I don't have a *nix system to test on, I was wondering how my version compares to the assembly one. But I guess the latter is still fastest where supported, at least in case of no overflow. I thought I was going to mention something else I noticed when benchmarking the * operator, which is why I didn't reply sooner, but it's not multiplication-specific, so nevermind. :-) I'll send a new e-mail after looking into it more... Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Optimization for ..._MULTIPLY_LONG on more systems
- Original Message - From: "Stanislav Malyshev" Sent: Thursday, November 09, 2006 > > Did it not work for you as-is on Windows...? It did for me, since it seems > > there's already a typedef for __int64 -> long long. I'd wondered the same, > > I think some VC versions on windows don't know "long long" but do know > __int64, but I don't remember from the top of my head which version, but > I think maybe VC6 might have a problem with that. Otherwise looks fine, > so if adjusted for VC6 it's OK. I forgot to mention that I had seen this in main/config.w32.h: /* MSVC.6/NET don't allow 'long long' or know 'intmax_t' */ #define SIZEOF_LONG_LONG_INT 0 #define SIZEOF_LONG_LONG 8 /* defined as __int64 */ SIZEOF_LONG_LONG was changed from 0 to 8 in v1.86 and the comment about __int64 added. So, I also assumed "long long" could be used as-is because of that. Why have SIZEOF as 8 if it's unusable...? It was changed to fix Bug #34052, I know, but I wouldn't think it was just a "hack" to make it non-zero -- especially with the __int64 comment. But anyway, I'll leave it to the experts if the patch needs tweaking. ;-) Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Optimization for ..._MULTIPLY_LONG on more systems
Did it not work for you as-is on Windows...? It did for me, since it seems there's already a typedef for __int64 -> long long. I'd wondered the same, I think some VC versions on windows don't know "long long" but do know __int64, but I don't remember from the top of my head which version, but I think maybe VC6 might have a problem with that. Otherwise looks fine, so if adjusted for VC6 it's OK. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Optimization for ..._MULTIPLY_LONG on more systems
Matt, Looks like a good patch to me. On 8-Nov-06, at 11:46 PM, Matt Wilmas wrote: Hi, Here's an additional ZEND_SIGNED_MULTIPLY_LONG() for platforms with 32-bit longs that don't use the assembly version (so all Windows systems at least?). On my Windows system, mul_function() is 40% faster with this version (no overflow), which makes PHP's * operator 20% faster; with overflow mul_function() is 20% faster (though I don't see any difference with the * operator). The macro is also used in safe_emalloc()... Patch just against 5_2 as the file versions are the only difference. Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Optimization for ..._MULTIPLY_LONG on more systems
Great patch! From my quick tests I got about 35% performance increase. Ah, it needs a little tweak to work on windows, as 'long long' is defined as __int64 (probably we could do a typedef once for all, as there are already many #ifdefs in the code because of this). Did it not work for you as-is on Windows...? It did for me, since it seems there's already a typedef for __int64 -> long long. I'd wondered the same, but before I added the (double) cast in case of overflow, I got the "Conversion from *__int64* to double: possible loss of precision" warning. :-) I haven't tried the patch on windows, I was just guessing. But Edin's mail explains why it worked for you (we use VC 6 for official builds). Nuno -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Optimization for ..._MULTIPLY_LONG on more systems
Matt Wilmas wrote: > Hi Nuno, > > - Original Message - > From: "Nuno Lopes" > Sent: Thursday, November 09, 2006 > > > >> Great patch! From my quick tests I got about 35% performance increase. >> Ah, it needs a little tweak to work on windows, as 'long long' is defined >> > as > >> __int64 (probably we could do a typedef once for all, as there are already >> many #ifdefs in the code because of this). >> > > Did it not work for you as-is on Windows...? It did for me, since it seems > there's already a typedef for __int64 -> long long. I'd wondered the same, > but before I added the (double) cast in case of overflow, I got the > "Conversion from *__int64* to double: possible loss of precision" warning. > :-) > > Glad you and Andi like the patch though! I didn't know if there'd be any > interest, LOL. I'll respond to Andi's message later... > Could be compiler version. VC6 doesn't support "long long", but I've heard that the new versions supported it. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Optimization for ..._MULTIPLY_LONG on more systems
Hi Nuno, - Original Message - From: "Nuno Lopes" Sent: Thursday, November 09, 2006 > Great patch! From my quick tests I got about 35% performance increase. > Ah, it needs a little tweak to work on windows, as 'long long' is defined as > __int64 (probably we could do a typedef once for all, as there are already > many #ifdefs in the code because of this). Did it not work for you as-is on Windows...? It did for me, since it seems there's already a typedef for __int64 -> long long. I'd wondered the same, but before I added the (double) cast in case of overflow, I got the "Conversion from *__int64* to double: possible loss of precision" warning. :-) Glad you and Andi like the patch though! I didn't know if there'd be any interest, LOL. I'll respond to Andi's message later... > Nuno Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Optimization for ..._MULTIPLY_LONG on more systems
Great patch! From my quick tests I got about 35% performance increase. Ah, it needs a little tweak to work on windows, as 'long long' is defined as __int64 (probably we could do a typedef once for all, as there are already many #ifdefs in the code because of this). Nuno - Original Message - Nice patch! Looks good to me... Any other thoughts? -Original Message- From: Matt Wilmas [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 8:47 PM To: internals@lists.php.net Subject: [PHP-DEV] Optimization for ..._MULTIPLY_LONG on more systems Hi, Here's an additional ZEND_SIGNED_MULTIPLY_LONG() for platforms with 32-bit longs that don't use the assembly version (so all Windows systems at least?). On my Windows system, mul_function() is 40% faster with this version (no overflow), which makes PHP's * operator 20% faster; with overflow mul_function() is 20% faster (though I don't see any difference with the * operator). The macro is also used in safe_emalloc()... Patch just against 5_2 as the file versions are the only difference. Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Optimization for ..._MULTIPLY_LONG on more systems
Nice patch! Looks good to me... Any other thoughts? > -Original Message- > From: Matt Wilmas [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 08, 2006 8:47 PM > To: internals@lists.php.net > Subject: [PHP-DEV] Optimization for ..._MULTIPLY_LONG on more systems > > Hi, > > Here's an additional ZEND_SIGNED_MULTIPLY_LONG() for > platforms with 32-bit longs that don't use the assembly > version (so all Windows systems at least?). On my Windows > system, mul_function() is 40% faster with this version (no > overflow), which makes PHP's * operator 20% faster; with > overflow mul_function() is 20% faster (though I don't see any > difference with the * operator). The macro is also used in > safe_emalloc()... > > Patch just against 5_2 as the file versions are the only difference. > > > Matt > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
