Re: [PHP-DEV] Optimization for ..._MULTIPLY_LONG on more systems

2008-07-21 Thread Lukas Kahwe Smith


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

2008-07-17 Thread Matt Wilmas
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

2006-11-10 Thread Nuno Lopes

 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

2006-11-09 Thread Nuno Lopes

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

2006-11-09 Thread Matt Wilmas
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

2006-11-09 Thread Edin Kadribasic
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

2006-11-09 Thread Nuno Lopes

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

2006-11-09 Thread Ilia Alshanetsky

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
multiply_long.txt
--
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

2006-11-09 Thread Stanislav Malyshev

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

2006-11-09 Thread Matt Wilmas
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



[PHP-DEV] Optimization for ..._MULTIPLY_LONG on more systems

2006-11-08 Thread Matt Wilmas
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
Index: zend_multiply.h
===
RCS file: /repository/ZendEngine2/zend_multiply.h,v
retrieving revision 1.10.2.1
diff -u -r1.10.2.1 zend_multiply.h
--- zend_multiply.h 4 Jan 2006 23:53:04 -   1.10.2.1
+++ zend_multiply.h 9 Nov 2006 03:54:01 -
@@ -31,6 +31,19 @@
else (lval) = __tmpvar; 
\
 } while (0)
 
+#elif SIZEOF_LONG_LONG  SIZEOF_LONG
+
+#define ZEND_SIGNED_MULTIPLY_LONG(a, b, lval, dval, usedval) do {  \
+   long long __result = (long long) (a) * (long long) (b); 
\
+   if (__result  LONG_MAX || __result  LONG_MIN) {   
\
+   (dval) = (double) __result; 
\
+   (usedval) = 1;  
\
+   } else {
\
+   (lval) = (long) __result;   
\
+   (usedval) = 0;  
\
+   }   
\
+} while (0)
+
 #else
 
 #define ZEND_SIGNED_MULTIPLY_LONG(a, b, lval, dval, usedval) do {  
\

-- 
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

2006-11-08 Thread Andi Gutmans
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