Author Topic: Too simple to be true  (Read 5458 times)

Gunther

  • Member
  • *****
  • Posts: 3585
  • Forgive your enemies, but never forget their names
Re: Too simple to be true
« Reply #15 on: January 12, 2016, 04:22:35 AM »
Hi Philippe,

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
Get your facts first, and then you can distort them.

jj2007

  • Member
  • *****
  • Posts: 9686
  • Assembler is fun ;-)
    • MasmBasic
Re: Too simple to be true
« Reply #16 on: January 12, 2016, 04:49:19 AM »
These 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

  • Member
  • ***
  • Posts: 330
  • Never be pleased, Always improve
    • Asm for fun
Re: Too simple to be true
« Reply #17 on: January 12, 2016, 06:05:39 AM »
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.
Kenavo (Bye)
----------------------
Asm for Fun
My Links
"La garde meurt mais ne rend pas"
Cambronne à Waterloo

Gunther

  • Member
  • *****
  • Posts: 3585
  • Forgive your enemies, but never forget their names
Re: Too simple to be true
« Reply #18 on: January 14, 2016, 04:18:11 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
Get your facts first, and then you can distort them.

Grincheux

  • Member
  • ***
  • Posts: 330
  • Never be pleased, Always improve
    • Asm for fun
Re: Too simple to be true
« Reply #19 on: January 14, 2016, 04:57:14 AM »
I have read them
Kenavo (Bye)
----------------------
Asm for Fun
My Links
"La garde meurt mais ne rend pas"
Cambronne à Waterloo

dedndave

  • Member
  • *****
  • Posts: 8823
  • Still using Abacus 2.0
    • DednDave
Re: Too simple to be true
« Reply #20 on: January 14, 2016, 06:26:47 AM »
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

  • Member
  • *****
  • Posts: 1056
Re: Too simple to be true
« Reply #21 on: January 16, 2016, 09:53:45 AM »
Hi Steve,

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.

Code: [Select]
PUSH CX, POP AX

Timed count: 02795 microseconds

MOV

Timed count: 04477 microseconds

XCHG

Timed count: 03728 microseconds

Cheers,

Steve N.