flat assembler
Message board for the users of flat assembler.
![]() |
Author |
|
revolution 09 Apr 2014, 06:36
Speed tests for something like this will not be useful. As you saw the results vary a lot because internally the CPU is doing other things that sometimes do and sometimes don't affect the timings.
I'd suggest that you need to look at your entire program to see if and where it needs optimising. Little functions like this are only worthwhile looking at if such a thing is called thousands of times per second for endless hours where saving 5% runtime might actually have some realtime benefit. Also, what might be faster on your system could be slower on another system. If your algorithm is strong then such small linear timing details won't matter much. |
|||
![]() |
|
DavidB3 09 Apr 2014, 07:06
Thank you.
revolution wrote: Speed tests for something like this will not be useful. As you saw the results vary a lot because internally the CPU is doing other things that sometimes do and sometimes don't affect the timings. Ok, but how can I know if it's faster than regular code code and it's worth using? revolution wrote: I'd suggest that you need to look at your entire program to see if and where it needs optimising. Little functions like this are only worthwhile looking at if such a thing is called thousands of times per second for endless hours where saving 5% runtime might actually have some realtime benefit. I already optimized the most part of the code. And these function are sometimes called millions of times per minute. So it's worth trying to code them in assembler. |
|||
![]() |
|
revolution 09 Apr 2014, 08:44
DavidB3 wrote: Ok, but how can I know if it's faster than regular code code and it's worth using? If it was significantly faster, and you are calling it millions of times, then you would know pretty quickly by the reduced runtimes. Optimising for speed is hard. It is not just a simple matter of writing a tighter loop or avoiding div. Things like algorithm selection, cache management and streaming data to DRAM etc. are where the majority of speed-ups are to be found. Usually only horribly inefficient code will be responsive to simplistic instruction level improvements. And these days many compilers do a reasonable job of not producing horribly inefficient code (as long as you get the algorithms right). |
|||
![]() |
|
DavidB3 09 Apr 2014, 09:16
revolution wrote: If you can't detect any significant changes in runtime then that is your answer: It is neither faster or slower. As I mentioned the test results are weird. I tried directly with the application's code. It showed ~23% speed increase. Ok. I added some code in other areas (that has nothing to do with the code involved in test). I tested again, this time was no difference in speed (?!). I'm not new in this kind of testing and ALWAYS I got consistent results. This is happening ONLY when I start using the assembler from Delphi. So either it's a bug in Delphi assembler (but I doubt that) or it's a bug in my assembler code which allows it to access memory it shouldn't have. |
|||
![]() |
|
revolution 09 Apr 2014, 09:22
DavidB3 wrote: I added some code in other areas (that has nothing to do with the code involved in test). |
|||
![]() |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.