I've written a few macros to inject code into procedures at compile time. The code it mostly just simple RDTSC instructions and appropriate add/sub/store arithmetic for counters and accumulators. I'm sure many others here have done the same. It is no big thing but, as you say, they are hard to use and set up properly.

Instrumenting code changes its behaviour so the user must be aware of what they are doing else the results can be meaningless. It is also application specific as to how the measurements should be made. Each application will have its own requirements and quirks that need programmer attention.

Executive summary: Profiling is not just simple plug-and-play thing. You've got to know what you are doing.

Where can I get that [profiler]?

Do you know how to use codeXL?

I could use RDTSC at both ends but I think its more complicated than that.

It would be nice and fun to have this, even a basic one should do so that we can bitch-slapping each other over whose codes are the fastest or the shortest.

Speed of execution is not a constant. Different systems do things in different ways, some things are faster and other things are slower, so comparisons are mostly pointless for people with disparate systems.

For probably the least intrusive measurements the statistical profiling is a nice concept to play with. Though I have only ever used it in DOS environment.

But could be useful as per code comparison, like seeing the effect of unrolling my loops things like that. Without it, I am completely clueless on code performance. Nothing. Nada. I just write code for the sake of completion.

sampling profiling

codexl does it
for linux there is the perf framework
https://perf.wiki.kernel.org/index.php/Main_Page
program has to have debug symbols
ofc, you can diy it http://en.wikipedia.org/wiki/Hardware_performance_counter
guess that is what Tomasz did

rdtsc is fine but you should account for it changing the alignment
so rdtsc stuff - align 16 - loop measured
intel cpu's would probably slow down on crossing the page border, so aligning to page length
and ofc make the loop measured run for long enough to increase the precision of the measurement

perf stat -B ./low64
0.00324449999999999

 Performance counter stats for './low64':

          0.151585 task-clock (msec)         #    0.231 CPUs utilized          
                 2 context-switches          #    0.013 M/sec                  
                 0 cpu-migrations            #    0.000 K/sec                  
                 3 page-faults               #    0.020 M/sec                  
           196,858 cycles                    #    1.299 GHz                    
            79,876 stalled-cycles-frontend   #   40.58% frontend cycles idle   
     <not counted> stalled-cycles-backend  
     <not counted> instructions            
     <not counted> branches                
     <not counted> branch-misses           

       0.000655774 seconds time elapsed    

system error wrote:

But could be useful as per code comparison, like seeing the effect of unrolling my loops things like that. Without it, I am completely clueless on code performance. Nothing. Nada. I just write code for the sake of completion.

Sure, but for "bitch-slapping" it would be useless. But you should also be aware of the pitfalls that a particular method will have.

I actually think that a custom written profiler for each app is really the only sensible and most reliable method. Some form of universal profiler is not gong to make the grade if one is really serious about performance. But if you are just dabbling for "bitch-slapping" reasons then I guess any profiler will do, even if it is wrong.

It looks very bad.

revo, we can't just skip code performance measures just because it is not easy to implement. It is not healthy for FASM programmers.

system error wrote:

revo, we can't just skip code performance measures just because it is not easy to implement. It is not healthy for FASM programmers.

Maybe you misunderstand me. I was suggesting taking the hard route, not the easy route. The easy route might work, might. But to be really sure we need to go deeper and properly do things to make sure we are really getting the right result. I am pleased that someone cares enough to start profiling but please make sure you know you are using the right tool for your situation, else I would be unhappy to learn that you got bad results and didn't realise they were bad.