Re: [fpc-devel] x86_64.inc CompareByte

2017-10-22 Thread Markus Beth
I used 2 different benchmarks. One for (very) short buffers [1] and one for rather large buffers [2]. [1]: var key, key2: string; res: LongWord; i: SizeInt; begin key := 'A'; key2 := 'A'; for i:= 0 to 10 do begin res := CompareByte(key[1], key2[1], Length(key)); end;

Re: [fpc-devel] x86_64.inc CompareByte

2017-10-22 Thread Florian Klämpfl
Am 21.10.2017 um 01:24 schrieb Markus Beth: > Find attached the already announced version of CompareByte. > What benchmark did you use? In my tests it is slightly slower than that one of fpc 3.0.x? I used the following test program: var buf1,buf2 : array[0..127] of byte; pos,len,i,j :

Re: [fpc-devel] rdtscp

2017-10-22 Thread Marco van de Voort
In our previous episode, Martok said: > Tangent: On Windows, RDTSC is wrapped by the QueryPerformanceCounter() call. > QPC > incidentally is complicated enough that it is very likely no out-of-order > instructions are pending by the time it gets to actually executing RDTSC, but > with less jitter

Re: [fpc-devel] rdtscp

2017-10-22 Thread Martok
Hi, Am 21.10.2017 um 21:41 schrieb Wolf: > rdtsc cannot do it either. You need to have a CPU capable of > understanding rdtscp. From what I understood, that doesn't give you cycles either, but only the same timestamp intervals RDTSC returns. Tangent: On Windows, RDTSC is wrapped by the

Re: [fpc-devel] rdtscp

2017-10-22 Thread Nikolay Nikolov
On 10/21/2017 10:41 PM, Wolf wrote: Hi, How do you measure time with a one cycle resolution? EpicTimer clearly does not cut it, and from what I gather , rdtsc cannot do it either. You

[fpc-devel] rdtscp

2017-10-22 Thread Wolf
Hi, How do you measure time with a one cycle resolution? EpicTimer clearly does not cut it, and from what I gather , rdtsc cannot do it either. You need to have a CPU capable of