Benchmark and test for htodw algos.

[hutch--]

 :bg

> For many years I use HIEW32 and IDA

Congratulations but if you cannot find the .DATA section in an EXE file you aren't doing it right.

> This is true because for many years I do not use your ancient code libraries

Thats no excuse for not having a tokeniser handy

> They are slow, with C-like code; without SSE, etc... or with other words smell of old age...Sorry

Gee SSE4.2 runs badly on an earlier processor. tried SSE3 on a PIII lately ? How about i7 opcodes on your Core series processor.

Come on Lingo, you can do better than that.

What fascinates me is after I bothered to write another test piece that showed your algo when its not fluctuating is fastest by a small amount on an i7/Core2 quad, you still want to lose the same argument.  ::)

[jj2007]

JJ,

'The table has to be created once,...

By you or by Hutch as a publisher of your algo? :lol
Because you don't post the file with it...

See attachment under reply #44:

Code Select Expand

.data?
hxjTable dd 65536/4 dup(?) ; bytes

.code
align 16
jj_htodw_s:
... table creation code...


...which costs a few nanoseconds"

How do you know when you haven't a ready to use table in your file?
Why these "few nanoseconds" are not included in the: 468 htodw JJ short?

They are included.

"It has no influence on average timings, and that's the only thing that counts in real life"
I'm sure that Hutch's "testing" program will have the same "problem" of "code placement" with it... :lol

There is no such problem because my code, including the creation of the table, is 124 bytes short.

"P.S. Calling other members liars gives you the image of an immature person."

I'm mature enough to know the thief is always a liar... :lol

When did you lose your last friend?

[lingo]

"How about i7 opcodes on your Core series processor."

You will lose this argument soon due to my wife will receive a gift for her birthday: I think to be a new lapi with i7-620M CPU in it. link

"..you still want to lose the same argument."
Non me ne frega un cazzo :lol 

[hutch--]

 :bg

> You will lose this argument soon due to my wife will receive a gift for her birthday: I think to be a new lapi with i7-620M CPU in it.

I am pleased to hear she is getting a new computer but I doubt that will help you to get i7 instructions to run on your Core series processor.  :P

[dedndave]

he has a wife ?   :eek

[ecube]

he has a wife ?   :eek

heh looks like you're not the only one married on here dave :P

[dedndave]

yah - but, i'm a nice guy   :bg

[hutch--]

Nah,

We have plenty of guys in here who have a better half, Jack is bashed around the eas regularly by a lovely lady Donna, Van posted a good photo of his better half and I know there are many others.

[Rockoon]

We do not talk about the girls because for most of us, our girls couldn't code their way out of a paper bag.

[hutch--]

 :bg

Thats what they have you for.  :P

[Antariy]

Code Select Expand

Intel(R) Celeron(R) CPU 2.13GHz
468 htodw JJ short (124 bytes)
703 Lingo long

Bravo, Jochen!

Thanks, Alex :bg

However, I did not advertise this one because it is limited to 8-byte strings. If your file has fixed length strings, it will be fine (and it's not even SSE...)

I know, Jochen.
This text is writte after testing - sources I see a bit later. All the same - this algo very good. Need only add support of short strings.


Alex

[NightWare]

hmm... i probably shouldn't enter these discussions, but :

to lingo :

"Yes, it seems, which Lingo's algo with big look-up table is very dependent from alignment and placement in the file. Need some "dancing with tambourine" to do it works faster :)" by the asian lamer with archaic CPU.

So, with other words Lingo is some kind of liar who try to manipulate the people and Lingo's algos are achieved by fraud...

hmm... not by fraud, but you use artifice/knowledge to defeat the others in the speed tests proposed.
ex: "jmp ecx" CAN'T be faster than "ret" (in most case). coz the code read is absorbed by the test loop.
plus, "ret" never need 2 memory clusters to be decoded (it's the case for "jmp ecx", with big slowdown, depending of the code placement)
jmp ecx CAN be faster ONLY in the situation of a speed test/like... and it's rarely the case in real life...

to hutch :
your speed test has no more values than the others, coz the read of the code is also absorbed by the loop. and you can't see the cost of the cache filling/no cache/cache effects on the others algos.

to the others, (ALL THE OTHERS):
lingo rarely initiate a speed test, he just propose a code for the test proposed (like every coder should do). if you don't understand the lacks of the test you've initiated it's not lingo's fault, if you only count on the result obtained without understanding what's really done/hidden it's not lingo's fault.
to make it short, if your're idiots, it's NOT lingo's fault.

personally i use and consider that MichaelW's macros give a good evaluation of the code written. i don't blindly follow the results. for the same reason explained before, i know that stuff like "add reg,1" CAN'T be faster than "inc reg" except in special circonstancies, rarely encountered in real life. THINK YOUR CODE ! AND UNDERSTAND WHAT'S UNDER THE RESULTS !  :P

[lingo]

Hutch,
I reordered something in my algo Lingo-long in your file lingoslow and now  I receive 46 with easy.
Please, try it. Thank you.
Note:Due to Hutch's testing program is very memory usage sensitive please close all other programs and run the test minimum 3 times. Get the best values. Thanks. :toothy

Code Select Expand


Intel(R) Core(TM)2 Duo CPU     E8500  @ 3.16GHz (SSE4)

C:\8>lingoslow
250 atodw library
109 Alex short
46 Lingo long
94 clive short
Press any key to continue ...

AMD Turion(tm) 64 Mobile Technology ML-30 (SSE3)

640 atodw library
265 Alex short
125 Lingo long
282 clive short
Press any key to continue ...

[ecube]

Code Select Expand


532 atodw library
203 Alex short
125 Lingo long
218 clive short
Press any key to continue ...


[jj2007]

Code Select Expand

641 atodw library
343 Alex short
141 Lingo long
281 clive short