Canvas is cool! - page 18
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
There seems to be a misunderstanding of what was being talked about here. I was talking about an example of a private Tester problem, where integer prices can give a gain in certain situations. The universal case was not in mind. That's why my Tester, to which I gave the link above, is implemented on dubs, as it's universal.
Can't agree 100% of the time.
You have made an assertion:
I'm almost certain that if you make the ticks integer, the Tester will start working much faster.
It is absolutely wrong when trying to implement it in practice. Wrong 100% of the time in practice.
So no need to go into theory or topic replacement. The topic is "the current tester can be accelerated when converted to integer". And the topic is 100% wrong with no exceptions.
You have made an assertion:
It is completely wrong when you try to put it into practice. It is 100% wrong in practice.
So no need to go into theory or changing the subject. The topic is "the current tester can be accelerated when converted to integer". And the topic is 100% wrong without exception.
Please note that this is the only statement of mine where I originally took the word Tester in inverted commas. You misunderstood the point I raised.
This is an add-on to your Tester, which without changing the code of any EA (with any indicators) makes a full pass with all trades and profits. But it does it faster than the regular Tester. All reproducible proofs have been given. People from the resource have verified these claims.
Show them.
And then prove that it's about switching to an integer mechanism, not that we've inefficiently implemented one mechanism or another through oversight.
If we are talking about the impact of recalculating the base of open positions, then there are real brakes there, which we will fix in the coming days.Please note that this is the only statement of mine where the word Tester was originally taken by me in inverted commas. You misunderstood the subject that was raised.
I got it right.
And correctly broached the subject with unpleasant details for you. If you think we didn't calculate the integer tester, you are sorely mistaken.
Show me.
Show.
And then prove that it's about switching to an integer mechanism, not that we've inefficiently implemented one mechanism or another through oversight.
Gave up on the integer testers because they weren't versatile. They were faster, but there were more minuses than pluses. However, as a phenomenon, they can exist. Virtual-work - on dubs.
That would be great!
I show you.
This one?
https://www.mql5.com/ru/forum/285631/page107#comment_10271917
I'm pretty sure that if you make the ticks integer, the "Tester" will be much faster.
I compared the speed of double and int in these two identical scripts:
Surprisingly, the variant dominated by double was even slightly faster on my CPU.
It turned out great.
I got 347 fps without antialiasing and 97 with antialiasing on a 2100x550 pixel canvas.
For information, we have a window update rate limiter of 500 fps. This shows how much performance can be achieved in the graphics.
Thank you.
Actually with antialiasing double circles are slower than the original without antialiasing int circles by about 20%. I have 300 vs 250 fps.
It's just that you've apparently measured anti-aliased circles with shadows, and the shadow of a circle is much more voracious than the circle itself. The shadow can be disabled with the draw a shadow parameter? = false.
I compared the speed of double and int in these two identical scripts:
Surprisingly, the variant dominated by double was even slightly faster on my CPU.
Beware of mass conversions like (int)double or (double)int and int+double mixing in math operations in general.
This gives the wildest overhead in the processor - just such an expensive assembler command. If you're counting in double, keep counting in it and don't switch to integer types.
Commands like cvtsi2sd/cvttsd2si are very long. A small tip in the article"The slowest x86 instruction", villain number 2.
The Intel® 64 and IA-32 Architectures Optimization Reference Manual says that the cost of the cvtsd2si instruction is 5 latencies (see Appendix C-16). cvtsi2sd, depending on your architecture, has latency varying from 1 on Silvermont to more like 7-16 on several other architectures.
Agner Fog's instruction tables have more accurate/sensible numbers, like 5-cycle latency for cvtsi2sd on Silvermont (with 1 per 2 clock throughput), or 4c latency on Haswell, with one per clock throughput (if you avoid the dependency on the destination register from merging with the old upper half, like gcc usually does with pxor xmm0,xmm0).
Thank you.
Actually with antialiasing double circles are slower than the original without antialiasing int circles by about 20%. I have 300 vs 250 fps.
It's just that you've apparently been measuring anti-aliased circles with shadows, and the shadow of a circle is much more voracious than the circle itself. The shadow can be disabled with the draw a shadow? = false.
Turns out I was looking at the web generation frequency, not the output frequency.
They are different numbers, multiples of each other.