On Mon, Feb 4, 2013 at 8:59 PM, Ard Biesheuvel wrote:
> On 02/04/2013 01:50 PM, Dmitry Stogov wrote:
>
>> I can't remember if I did any special benchmarks except for bench.php when
>> I introduced fast math functions.
>> That time, I rearranged the code to allow inlining of the most probable
>> pa
On 02/04/2013 01:50 PM, Dmitry Stogov wrote:
I can't remember if I did any special benchmarks except for bench.php when
I introduced fast math functions.
That time, I rearranged the code to allow inlining of the most probable
paths and added assembler code to catch overflow (C can't do it in opti
I can't remember if I did any special benchmarks except for bench.php when
I introduced fast math functions.
That time, I rearranged the code to allow inlining of the most probable
paths and added assembler code to catch overflow (C can't do it in optimal
way). As I remember the bench.php showed so
Hi Dimitry,
The main problem I have with this code is that most of it (the double
handling) is outside the hot path, and that it is riddled with
hardcoded constants, struct offsets etc. However, if it works than I
am not necessarily in favour of making changes to it.
So can you explain a little b
Hi Ard,
Actually with your patch the fast_increment_function() is going to be
compile into something like this
incl (%ecx)
seto %al
test %al,%al
jz .FLOAT
.END:
...
.FLOAT:
movl $0x0, (%ecx)
movl $0x41e0, 0x4(%ecx)
movb $0x2,0xc(%ecx)
jmp . END
while before th
On Fri, Jan 18, 2013 at 7:08 PM, Ard Biesheuvel
wrote:
> Hello,
>
> Again, apologies for prematurely declaring someone else's code 'crap'.
> There are no bugs in the inline x86 assembler in Zend/zend_operators.h, as
> far as I can tell, only two kinds of issues that I still think should be
> addre
Hello,
Again, apologies for prematurely declaring someone else's code 'crap'.
There are no bugs in the inline x86 assembler in Zend/zend_operators.h,
as far as I can tell, only two kinds of issues that I still think should
be addressed.
First of all, from a maintenance pov, having field offs
