Is it possible to make this little code smarter or / and faster ? !:*)

[hutch--]

Yep, I can continue too.  :bg

No matter what you do with a system API call, its no faster if its called in assembler, C or even VB, optimising an API call is a non event as its within the system and beyond your control. There is a trick on some API calls to copy them to local memory and you see a speed improvement but thats hardly what is being discussed. Then there is the processor compatibility issue, SSE3 runs really lousy on hardware that does not support it and a vast amount of data processing has no advantage trying to use MMX or SSE.

Agner Fog's various optimisation manuals do not deal with optimising a system API call as it is a non-event. If you program in assembler runs slower than the same functionality in C, stop wasting time trying to optimise an API call and start timing assembler code where it matters. If you write unreadable code, get used to the idea that few others either can or will be bothered to decypher it.

I have sold the argument for a long time of putting your effort where it matters, not where it is wasted. Having the fastest MessageBoxA on the planet is a "so what" affair but putting your effort into a decent data munching algorithm or image processing algo and you will see a reasonable result from bothering.

Now to invert your automotive example, why bother putting twin superchargers and an afterburner on something you are going to drive around the city at 50 KPH ? Spend your effort on a 3000 HP+ dragster and you will see something go fast.  :bg

[FairLight]

My questions were not to be intended for ... "Wow, i've got the fastest API-call, as fast as API calls !"
Only wanted to look @ other people's code how they will write a solution for small steps of data ...
I have got thousands of learning books, pdfs, tutorials, links, forums, example code,... (except AFog, Iczel, etc.) ,
but was too lazy to read them all !
:'( And there's so much information about learning assembler in my own language, it's very amazing ! C'est la vie !

.. Sorry about that !

And sorry that i was born. Sorry, that i have every time in the world ! Sorry to start this topic ...
sorry about my very bad english ... sorry about that i am not as excellent as lingo is ...
sorry about that i want to learn from other people:
"Time and money makes the world go round !"

mov Recyclebin, Topic
xor Recyclebin,Recyclebin
SYS 64738

btw.:
"A protected forum where programmers learning assembler can ask questions in a sensible and safe atmosphere without being harassed or insulted. This is also targetted at experienced programmers from other languages learning assembler that don't want to be treated like kids."

O and O and Cul8'er.



:(

[hutch--]

FairLight,

have no concern about the debate, it does not effect you and it was not pointed at you. Just write your code to get it reliable, faster if you can and it will do the job. When you start writing algos in assembler, thats where the fast stuff will be and where the real fun starts.  :bg

[FairLight]

 :U   :bg

[lingo]

Ich bin mit dem Hutch einverstanden, keinem beleidige hier.
Es war mein freundlicher Rat und reiner assembler code :wink

[CoR]

       

SYS 64738

         Haha  :green C64 (fat model) was my first comp!

[lingo]

"I have sold the argument for a long time of putting your effort where it matters,
not where it is wasted.

We do programming under different OS and we ALWAYS will call
OS system functions (APIs are slow) using different
languages. So, again (according to Hutch):
"APIs are slow, hence we can use every shit to call them"
and no optimization, no new technology, no A.Fog and write all
in I486 way... :lol

[hutch--]

 :bg

I will make you a deal, you can write the fastest MessageBoxA call on the planet and we will all applaud you for doing so. "Hay man, I have the fastest MessageBoxA on the planet, big deal huh ?"

[lingo]

Do you permit me to change the name of
API from MessageBoxA to strlenA?  :lol

[j_groothu]

Analysing my mum's computer habits, replacing all calls to MessageBoxA with an assumed return value of "MB_DONTCARE" or "MB_GOAWAYMESSAGEBOX" would radically improve program flow  :lol

[hutch--]

 :bg

> Do you permit me to change the name of
> API from MessageBoxA to strlenA?

I would not want you to miss out on such a claim to fame as creating the fastest MessageBoxA on the planet. Think of this, if you did the jumps correctly you could shave off two processor cycles after reading the message in the MessageBoxA and clicking the OK button.

[hutch--]

 :bg

Here is a slightly slowed down MessageBoxA application.

Code Select Expand


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

    .data
      msg$ db "! huH wolS",0
      ttl$ db "sgniteerG",0
      pmsg dd msg$
      pttl dd ttl$

    .code

start:
   
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

    call main

    exit

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

main proc

    push MB_OK
    mov pttl, rev$(pttl)
    push pttl
    mov pmsg, rev$(pmsg)
    push pmsg

    mov ecx, 1000
  @@:
    sub ecx, 1
    jnz @B

    push 0
    call MessageBoxA

    ret

main endp

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

end start


This is why I don't bother to try and optimise API code, its so slow it just does not matter.

[TomRiddle]

Hutch, where is the info for making macro's like rev$?  :toothy

Thanks in advance!

[hutch--]

Tom,

In the MACROS.ASM file in the MACROS directory.