How do I go through an enumeration consistently? - page 3

 
Alexey Navoykov:

The examples shown here (case 1: return value1; case 2: return value2; case 3: return value3... An adequate person would put all values into an array and just get the required value by its index. And for the reverse task he/she would use binary search.

I am two hands in favor of nice code with arrays. But when writing a faster NormalizeDouble than the regular one, I have encountered an optimizer effect - the nice solution via const-array was much slower than the cumbersome switch-case solution. I have left the second variant because NormalizeDouble is used a lot in the tester. I put it into the indicator and don't look at this monster. But the backtests run faster.
 
fxsaber:
I'm two hands in favour of nice code with arrays. But when writing a faster NormalizeDouble than the regular one, I have encountered an optimizer effect - a nice solution via const-array was much slower than a cumbersome one via switch-case. I have left the second variant because NormalizeDouble is used a lot in the tester. I put it into the indicator and don't look at this monster. But the backtests run faster.

I remember once there was a thread discussing switch, where developers were only talking about implementation as a binary search, which of course is much slower than simple access by calculated index.But now they seem to have made it more wisely: if a step is constant, the index is calculated, otherwise binary search is performed. Of course, native implementation is always faster than wrapper one.

Of course, this depends on your priorities. But imho, if speed is so crucial that you're ready to invent crutches, then you should give up OOP and MQL as well ;) Although I'm sure with proper coding this difference in speed won't be that significant. In testing measurements you are just bouncing a function around in a loop millions of times. And you use it more rationally in real code, don't you?

 
Alexey Navoykov:

I remember once there was a thread discussing switch, where developers were only talking about implementation as a binary search, which of course is much slower than simple access by calculated index.But now they seem to have made it more wisely: if the step is constant, then the index is calculated, otherwise binary search. Of course, native implementation is always faster than wrapper one.

The compiler, if it is not dumb, would have to turn the const-array and the only type reference to it by the index into switch code.

Of course, you may have to depending on your priorities. But imho, if speed is so crucial that you're ready to invent crutches, then you should give up OOP and MQL in general ;) Although I'm sure with correct coding the difference in speed will not be so substantial. In testing measurements you are simply racing a function through a loop millions of times. And in real code you use it more rationally, don't you?

The speed is not crucial, but when I'm writing irrationally, I feel discomfort. Not to use OOP at all is not rational, of course. Anyway, look at the modest efforts in kodobase you've laid out and haven't counted for many days. There you will understand where the crutches in the form of the same NormalizeDouble appeared. It is the result of a random fact from sometimes irrational implementations of developers.
 
fxsaber:
The compiler, if it is not dumb, would have been obliged to turn the const-array and the only type reference to it by index into switch code.

So the array is just a const? What about static? And why "switch code"? It's a simple operation: compare index value with array/enum size, and if it's less, get the address of the required element as array address + index, and then read the value from there. I thought such nonsense must compile equally.

Anyway, look at the modest efforts in kodobase, which I've laid out and haven't counted for many days. There you will understand where the crutches in the form of that same NormalizeDouble appeared. It is a result of an accidental fact from sometimes irrational implementations of the developers.
And by the way, how long ago did you perform these comparisons? Maybe the compiler was still "dumb" back then?
 
Alexey Navoykov:

So the array is just a const? What about static? And why "switch code"? It's a simple operation: compare index value with array/enum size, and if it's less, get the address of the required element as array address + index, and then read the value from there. I thought such nonsense must compile in the same way.

I don't remember for sure whether you may create static arrays using const methods - you certainly may not. As a matter of principle I was making consts and not statics. Counting on the compiler's intelligence. After the compilation, there should have been no hint of an array in the guts at all. A statik is a much more complicated structure than const. That's why I was sure the compiler would fail to cope with the statik. But I would have to give it a try.

I'm not quite clear what "efforts" you mean. And by the way, how long ago did you carry out these comparisons? Maybe the compiler was still "dumb" then?
The effort will be visible as soon as one of the moderators presses a few buttons and gives the go-ahead to publish the code in kodobase. Made a convenient solution for myself, not thinking about performance, and got a gain of almost an order of magnitude in the build 1383 32-bit.
 
fxsaber:

I don't remember exactly whether static arrays can be made const. methods - definitely not. As a matter of principle, I was making consts, not statics. Counting on the compiler's intelligence. After the compilation, there should have been no hint of an array in the guts at all. A statik is a much more complicated structure than const. That's why I was sure the compiler would fail to cope with the statik. But I would have to give it a try.

Oh, well, that explains it. You should not rely on excessive intelligence of the compiler, that it further optimizes a poorly-designed solution for you. If you yourself are too lazy to do it properly, saying that "statics is much more complicated" (although what is complicated there, I do not understand), then why accuse the compiler?

 
Alexey Navoykov:

Oh, well, that explains it. You should not rely on excessive intelligence of the compiler, as it will optimize a poorly-designed solution for you. If you yourself are too lazy to do it properly, saying "static is much more complicated" (although what is complicated there, I do not understand), then why accuse the compiler?

I added static to the array. It worked almost three times faster than switch! Throw that switch away. Thanks for the tip!
 
fxsaber:
I added static to the array. It worked almost three times faster than switch! Trash this switch. Thanks for the tip!

You're welcome. It will be a lesson for the future, that one should think 7 times, before running to invent crutches.)

It turns out now, that I praised the switch, or rather its developers too early. So everything is implemented there through binary search only, even when enumeration goes with multiples. Not good.

 
Alexey Navoykov:

You're welcome. It'll be a lesson for the future, to think 7 times before running around inventing crutches )

Almost four times faster than standard NormalizeDouble (build 1395)... is a crutch of the developers.

 
fxsaber:
Almost four times faster than standard NormalizeDouble (build 1395)... is a crutch of the developers.

Everybody is not without sin )