You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
If you change the size of arrays in the body of the loop, on-the-fly optimization does not work
so change the code:
)))) simply you also have to change the value of your size variable, so the named first method using ArraySIze will benefit
Well I can't say anything against IMHO.
On very large replays, my wins have become random for the first and second method... Most likely it became dependent on current CPU cache and overall load.
My question wasn't about the loop - it was about how the function unfolded. It's just that ArraySize was used as an example.
That's good) The perfection of a high-level language is precisely when a convenient entry is just as cheap as an unhandy one, but inherently cheap. Too bad it's not always like that, and help with a helper for newbies not always at all either..... there would be no questions)))
If you change the size of arrays in the body of the loop, on-the-fly optimization does not work
So change the code:
it doesn't work
runtime optimization is in the lead
you can't test such simple mashin commands without a profiler, or you can write in the loop, or test in a tester, speed is important for it
I was not talking about the loop but about how the compiler unfolds functions..... come on.
I'll leave you to it.
)))) you are also allowed to change the value of your size variable, so the first method using ArraySIze will win
I wrote above - such simple code cannot be tested with simple measurements, there are many factors - the code is small - it will fit into the processor cache, the code must be well broken down in the processor into parallel micro-commands in the processor pipeline, i.e. registers will be quickly loaded by data prefetching
and perhaps rand() will also be cached somewhere
well, i don't know how to test without debugger - at least there you can see time of instructions execution in tacts
Then prove me wrong.)
Because in my test for some reason they are the same.
Changed my post.
It seems to me that ArraySize now is faster than cnt variable.
Earlier it was vice versa. Maybe increment cnt-- is affecting, loop body is different and probably something else must be invented for load.
This is strange.
Using ArraySize(arr) in the loop condition shows less time than using the cnt variable.
It was vice versa before. Maybe it's an error? It shouldn't be like that.
You didn't mix up anything in your code, who will change the value for you?
cnt
change it for you, as it happens in the first variant
500p question (no check), which way is faster. see how many external functions are called in the top method
as a variant of the test - you can also slip only different arrays into each test - in my example arr1,arr2...
i.e. tst1_arr1[],tst1_arr2[] .... and tst2_arr1[],tst2_arr2[]
this would be a fairer test.
i'm off, very distracting - imho, handy, use it
I don't know how to test without debugger - at least you can see the execution time of instructions in clock cycles.
Well, yes - you can't do without debugger. And in the clock time there...
This is strange.
Using ArraySize(arr) in the loop condition shows less time than using the cnt variable.
It was vice versa before. Maybe it's an error? It shouldn't be like that.
There is a random result there. When compiling, accesses to a memory cell with an array size value are unfolded, while the array size will be received and put into the memory cell beforehand, when the array is formed, even if the array is dynamic and cells with an array size and a variable's value will have the same access time.
And judging by the phrase that compilers do in the 3-4 year computer science course ... in general, I will hope that a sufficiently necessary level of framing will not make me very nervous in an MCL environment)