News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Too simple to be true

Started by Grincheux, January 11, 2016, 12:39:15 AM

Previous topic - Next topic

Gunther

Hi Philippe,

Quote from: Grincheux on January 12, 2016, 01:52:46 AM
These last days I read many things about optimization. Optimization means instructions speed, aligment...
But what said Hutch and Guga has more sense, speaks better to me.
I will change the way I see programming.

Have you checked Agner Fog's manuals?

Gunther
You have to know the facts before you can distort them.

jj2007

Quote from: Grincheux on January 12, 2016, 01:52:46 AMThese last days I read many things about optimization. Optimization means instructions speed, aligment...

It means lot of things. As Hutch wrote earlier, a redesign of a procedure may dramatically speed up your code. But that is not always possible, and therefore sometimes raw power is important. Especially libraries like the CRT should be fast for frequently used functions, such as strlen or instr. That is one area where SSE can be very useful.

Same applies for sort functions, for example. No problem if you want to sort a thousand lines, but if it approaches the Millions, you better use the fastest available algo. The Masm32 Laboratory is a fascinating place in this respect :P

Grincheux

Gunther, I have read, and re-read AF manuals, Amd, Intel, Sandpile, nasm... and more.
I have downloaded many files (asm, pdf, html...)
But I agree with Hutch, Guga and JJ2007 it is not always a question of speed, sometimes the way we code the algorythm is more important than selection the best opcode.

Gunther

Quote from: Grincheux on January 12, 2016, 06:05:39 AM
But I agree with Hutch, Guga and JJ2007 it is not always a question of speed, sometimes the way we code the algorythm is more important than selection the best opcode.

No doubt about that, but Agner's manuals are a must. You should have a look into those.

Gunther
You have to know the facts before you can distort them.

Grincheux


dedndave

algorithm design is first and foremost
selecting the right approach to a problem far outweighs specific instructions used

many of the algorithms in the masm32 package are faster than they really need to be   :biggrin:
i mean, how many times are you going to convert a value to a hex string ?
i might write a program to convert 4 or 5 values and display them
i have never needed a program to perform thousands upon thousands of such conversions
for 4 or 5 values, you would hardly notice a speed difference of 10 nS or 10 mS

but, the algo design is fast
they use a look-up table for maximum performance
that's because it is a "general purpose" routine - to be used many different ways

FORTRANS

Hi Steve,

Quote from: hutch-- on January 11, 2016, 04:18:17 PM
It come from a fundamental difference between early and much later x86 hardware, very early 8088 processors  chomping along at 2 meg had the common instructions we use hard coded directly into silicon but as the much later versions were developed they shifted from CISC (complex instruction set computers) to RISC (reduced instruction set computers) that provided a CISC interface for compatibility reasons. The preferred instructions were written directly into silicon where the old timers were dumped into a form of slow bulk storage that is commonly called microcode. Old code still works but its so slow that it is not worth using.

   Just for laughs I coded up the above three tests in a 16-bit version.
Code obviously is a bit different, but hopefully similar in intent.  Ran
it on an 80186 for timings.

PUSH CX, POP AX

Timed count: 02795 microseconds

MOV

Timed count: 04477 microseconds

XCHG

Timed count: 03728 microseconds


Cheers,

Steve N.