Which is faster - Floating-Point or Integer arithmetic? - page 10

[Fernando Carreiro]

nicholishen: Alain, not sure how you got those results... I'm right where Fernando is on a 2.4 GHz i5. 

Fernando, thanks for also running these on MT4...that answers that for me... 

Surprisingly, array read/write/sort performance is the same as well. That's where I thought <int> might have a more significant edge. 

1. With regards to @Alain Verleyen's results, there is definitely a environmental factor involved that affects results, which I am hoping to understand. However, for the sake of completeness, can you post your full test results for both MT4 and MT5 for both the 1E7 and 1E8 tests please?
2. Can you please also provide more details on the hardware and OS you used (using the MetaTrader journal details for example). These are mine:
• MetaTrader 5 build 1745 - Windows 10 (build 16299) x64, IE 11, UAC, Intel Core i7-4790T  @ 2.70GHz, Memory: 9026 / 16274 Mb, Disk: 354 / 893 Gb, GMT+0
• MetaTrader 4 build 1090 - Windows 10 Pro (x64 based PC), IE 11.00, UAC, 8 x Intel Core i7-4790T  @ 2.70GHz, RAM: 9356 / 16274 Mb, HDD: 363310 / 915146 Mb, GMT+00:00
3. I'm also preparing two other machines for testing both on MT4 and MT5, both running Windows 2008 R2. One machine is a VPS on "vultr.com" and the other is a physical one with an very old Intel Core2 Quad. I will supply results on those machines once I am into this at full steam.
4. I am also looking at standards based benchmark tests (like Whetstone, Dhrystone, etc.) so that we can be sure that our tests are not "flawed" in any way due to our own biases. This way we can all agree on the test code at a common level.
5. I also reached out to @whroeder1 via PM and asked his opinion on the matter, due to his FPU/CPU comment, but he has not answered yet.

[nicholish en]

Fernando Carreiro:

1. With regards to @Alain Verleyen's results, there is definitely a environmental factor involved that affects results, which I am hoping to understand. However, for the sake of completeness, can you post your full test results for both MT4 and MT5 for both the 1E7 and 1E8 tests please?
2. Can you please also provide more details on the hardware and OS you used (using the MetaTrader journal details for example). These are mine:
• MetaTrader 5 build 1745 - Windows 10 (build 16299) x64, IE 11, UAC, Intel Core i7-4790T  @ 2.70GHz, Memory: 9026 / 16274 Mb, Disk: 354 / 893 Gb, GMT+0
• MetaTrader 4 build 1090 - Windows 10 Pro (x64 based PC), IE 11.00, UAC, 8 x Intel Core i7-4790T  @ 2.70GHz, RAM: 9356 / 16274 Mb, HDD: 363310 / 915146 Mb, GMT+00:00
3. I'm also preparing two other machines for testing both on MT4 and MT5, both running Windows 2008 R2. One machine is a VPS on "vultr.com" and the other is a physical one with an very old Intel Core2 Quad. I will supply results on those machines once I am into this at full steam.
4. I am also looking at standards based benchmark tests (like Whetstone, Dhrystone, etc.) so that we can be sure that our tests are not "flawed" in any way due to our own biases. This way we can all agree on the test code at a common level.
5. I also reached out to @whroeder1 via PM and asked his opinion on the matter, due to his FPU/CPU comment, but he has not answered yet.

Fernando, I hope you don't mind me bowing out of this for now. I've already committed way too much time to this, and I'm convince that the optimization is to avoid casting whenever possible and use whatever data-type makes sense. Good luck!

[Fernando Carreiro]

nicholishen: Fernando, I hope you don't mind, but I've already committed way too much time to this. I'm convince that the optimization is to avoid casting whenever possible and use whatever data-type makes sense. Good luck!

Thank you for your cooperation and contributions, and for opening our eyes about our assumptions on integer arithmetic being always faster. The current reality is that with modern CPU's this is actually a very "grey" area that depends on many factors!

In my own EAs I still plan to continue using Integer based arithmetic, mainly because of the tick-size and lot-step alignment, but I will from now on always double check the performance impact of that decision.

Again, thank you!

[nicholish en]

Fernando Carreiro:

Thank you for your cooperation and contributions, and for opening our eyes about our assumptions on integer arithmetic being always faster. The current reality is that with modern CPU's this is actually a very "grey" area that depends on many factors!

In my own EAs I still plan to continue using Integer based arithmetic, mainly because of the tick-size and lot-step alignment, but I will from now on always double check the performance impact of that decision.

Again, thank you!

Just keep in mind that for most applications you only ever really need to round to tick and lot-step when it comes time to send an order, however, with the int method you have to round the incoming tick data and indicator data (assuming you use indicators) . There will be 1000's of ticks for each order placed. That's a lot of extra overhead. 

[Fernando Carreiro]

nicholishen: Just keep in mind that for most applications you only ever really need to round to tick and lot-step when it comes time to send an order, however, with the int method you have to round the incoming tick data and indicator data (assuming you use indicators) . There will be 1000's of ticks for each order placed. That's a lot of extra overhead. 

Yes I am well aware of that, but no, I don't use Indicators in the normal sense, because I always re-code their functionality into the EA because of the self-optimisation routines and the Virtual/Simulated Order systems I implement.

I have already run several tests on them, and there is no extra overhead (or just negligibly) in the sense you describe. In all my cases (except for two EAs), my Integer implementation is still faster than the floating-point alternative and hence why I was adamant about it in our discussions.

I do however, now recognise that it is not a "universal" rule and that it depends on many factors and that for other implementations, floating-point could well be much faster than Integer.

[nicholish en]

Fernando Carreiro:

Yes I am well aware of that, but no, I don't use Indicators in the normal sense, because I always re-code their functionality into the EA because of the self-optimisation routines and the Virtual/Simulated Order systems I implement.

I have already run several tests on them, and there is no extra overhead (or just negligibly) in the sense you describe. In all my cases (except for two EAs), my Integer implementation is still faster than the floating-point alternative and hence why I was adamant about it in our discussions.

I do however, now recognise that it is not a "universal" rule and that it depends on many factors and that for other implementations, floating-point could well be much faster than Integer.

Well none of this really matters much on a tick by tick basis, but I know that you like to optimize for mt4 backtesting....

[Fernando Carreiro]

nicholishen: Well none of this really matters much on a tick by tick basis, but I know that you like to optimize for mt4 backtesting....

Please lets not start getting "heated" about this again. I have already explained that I code for both MT4 and MT5 (simultaneously) and that most of my EAs use self-optimisation and not necessarily pre-optimisation via the Strategy Tester, be that on MT4 or MT5, and in my cases I still benefit form using the "ints".

[nicholish en]

Fernando Carreiro:

Please lets not start getting "heated" about this again. I have already explained that I code for both MT4 and MT5 (simultaneously) and that most of my EAs use self-optimisation and not necessarily pre-optimisation via the Strategy Tester, be that on MT4 or MT5, and in my cases I still benefit form using the "ints".

I'd really love to see an example of int conversion that covers the cost of all that rounding doubles to int...still haven't seen one

[Alain Verleyen]

nicholishen:

Alain, not sure how you got those results... I'm right where Fernando is on a 2.4 GHz i5. 

I just ran the script. I know the results are "weird" and that's well why we got these big misunderstanding yesterday.

Just once again :

2018.01.16 09:54:43.599 224626_2 (NZDUSD,H1) <int>: 41 ms for 10000000 iterations

2018.01.16 09:54:43.599 224626_2 (NZDUSD,H1) result = 9981401 sum=327635664846

2018.01.16 09:54:43.640 224626_2 (NZDUSD,H1) <double>: 40 ms for 10000000 iterations

2018.01.16 09:54:43.640 224626_2 (NZDUSD,H1) result = 9981401 sum=327635664846.000000

---

2018.01.16 09:47:47.153 224626_2 (NZDUSD,H1) <int>: 4175 ms for 100000000 iterations

2018.01.16 09:47:47.155 224626_2 (NZDUSD,H1) result = 99813994 sum=3276804185274

2018.01.16 09:47:55.396 224626_2 (NZDUSD,H1) <double>: 8233 ms for 100000000 iterations

2018.01.16 09:47:55.415 224626_2 (NZDUSD,H1) result = 99813994 sum=3276804185274.000000

I suppose it depends on the workload of the CPU/GPU (yesterday morning it was 8 times slower for double, now it's 2 times (1E8), while 1E7 iterations give similar results). 

[Fernando Carreiro]

nicholishen: I'd really love to see an example of int conversion that covers the cost of all that rounding doubles to int...still haven't seen one

Sorry, but I don't feel the need to "prove" it by showing my EA code implementations! All that is important for this thread is that it has been shown that the assumptions (mine included) about the faster Integer advantage are no longer a given, and that in many cases Floating-point is actually faster.