Features of the mql5 language, subtleties and tricks - page 153

New comment
 
Roffild:

In the ArrayReverse help:

TheArraySetAsSeries()function does not physically move the elements of the array, but only reverses the indexing direction backwards to arrange access to the elements as in atimeseries. The ArrayReverse() function physically moves array items so that the array is "reversed".

But this code proves the opposite:

Why? That's right.

If we deal with an array where numbering is like in a timeseries, i.e. zero bar is the latest and the latest is the earliest, when a new element is added, it will be next to the latest, i.e. the earliest.

And if the array is not numbered as in timeseries, then the zero element is the earliest and the last element is the latest. Therefore, when a new element is added, it will be next to the latest.
Which is what happens in your test.

Where is the proof here I don't understand. How can we prove it and find out where the array's beginning is in memory and what increment step is positive or negative.
You can prove it only by passing the array and using pointers.
But it's easier to prove it by measuring the time it takes to execute this operation. If an array of 100 000 000 items "flips" instantly, it is clear that there is no flipping; the reference to the beginning changes and the increment changes its sign.
I use theArraySetAsSeries() function all the time, and I can see that it's absolutely free in time. So you're wrong.

To be honest, I don't understand why we need slowArrayReverse functionwhen we have fastArraySetAsSeries()

 
Roffild:

In the ArrayReverse help:

TheArraySetAsSeries()function does not physically move the elements of the array, but only reverses the indexing direction backwards to arrange access to the elements as in atimeseries. The ArrayReverse() function physically moves array items so that the array is "reversed".

But this code proves the opposite:

You have a memory reallocation for an array with the asSeries flag, naturally they took that into account. They must have something like this there:

template<typename T>
T* ReAllocArray(T* array, size_t size, size_t newSize, bool asSeries) {
    auto _array = (T*)realloc(array, newSize * sizeof(T));
    if (_array == NULL) throw bad_alloc();
    auto _ptr = _array + size;
    auto ptr = _array + newSize;
    if (asSeries){
        while (_ptr != _array) *(--ptr) = *(--_ptr);
        while (ptr != _array) new(--ptr) T;
    }
    else {
        while (_ptr != ptr) new(_ptr++) T;
    }
    return _array;
}
 
Vladimir Simakov:

You have memory reallocation for an array with asSeries flag, of course they took that into account. They must have something like that there:

Yes, they must have taken it into account. But this behavior does not correspond toCopyRates():

No matter what property the receiving array has - as_series=true or as_series=false, the data will be copied so that the oldest element in time will be at the beginning of the physical memory allocated to the array.

Also toArrayCopy():

If count<0 or count>src_size-src_start, the entire remainder of the array is copied. Arrays are copied from left to right. For serial arrays, the start position is correctly overridden , taking into account copying from left to right.

The last sentence is kind of ambiguous.
 

I'm in a bit of a state of shock. I wrote a test in Java. It turns out that Java is almost as fast as C, and therefore slightly faster than MQL5.

I don't know how they do it, it is in fact an interpreter language.

I wonder if it's the same with Python.

Of course, it's not saying that MQL5 is bad. It's just that Java is too cool.

I must have missed something. Since when did interpreters become as fast as compilers?

Apparently this is only possible with partial compilation, i.e. interpreters are not pure.

 
Nikolai Semko:

I'm in a bit of a state of shock. I wrote a test in Java. It turns out that Java is almost as fast as C, and therefore slightly faster than MQL5.

I do not understand how they are able to do it, it is in fact an interpreter language.

I wonder if it's the same with Python.

Of course, it's not saying that MQL5 is bad. It's just that Java is too cool.

I must have missed something. Since when did interpreters become as fast as compilers?

Apparently this is only possible with partial compilation, i.e. interpreters are not pure.

MQL is also an interpreter.

 
Nikolai Semko:

I'm in a bit of a state of shock. I wrote a test in Java. It turns out that Java is almost as fast as C, and therefore slightly faster than MQL5.

I do not know how they do it, it is in fact an interpreter language.

I wonder if it's the same with Python.

Of course, it's not saying that MQL5 is bad. It's just that Java is too cool.

I must have missed something. Since when did interpreters become as fast as compilers?

Apparently this is only possible with partial compilation, i.e. interpreters are not pure.

Java, although translated into bytecode, has its own virtual execution machine (JVM).
The language is also strictly typed, unlike other languages with an interpreter.
Most likely, strict typing and JVM is the reason for fast execution and transmission of instructions to the hardware.
The American trading terminals are written in Java for a reason. The CME Group in Chicago officially offers terminals written in Java.
A programmer once told me that Java has its roots in telecommunications.
In telecommunications you have to have the speed to process and transfer data from the beginning.
And Oracle has its own community for the development of this language.
That is, the language is alive and being finalised by the Oracle community.

Incidentally, the Quik brand and the LUA language were also developed by the Americans.
But in the shaggy 90s, it was successfully sold to the Russian Federation.
Back in those years, the americans already understood that LUA had no future development.
And they successfully sold it to the Russian Federation, where an exchange market had just begun to form after the collapse of the Soviet Union.

 
Nikolai Semko:

I'm in a bit of a state of shock. I wrote a test in Java. It turns out that Java is almost as fast as C, and therefore slightly faster than MQL5.

I don't understand how they do it, it's essentially an interpreter language.

The model there is the same as in .Net - the source code is compiled into bytecode, it will be an interpreter, and when you unpack the bytecode on a given PC, the native code will be generated for the virtual environment in which it will be executed, i.e. it will be compiled code

https://habr.com/ru/post/107585/


google "Java compiler or interpreter" for Java - there will be similar articles

 
Алексей Тарабанов:

MQL is also an interpreter.

Justification?

 
Nikolai Semko:

I'm in a bit of a state of shock. I wrote a test in Java. It turns out that Java is almost as fast as C, and therefore slightly faster than MQL5.

I do not know how they do it, it is in fact an interpreter language.

I wonder if it's the same with Python.

Of course, it's not saying that MQL5 is bad. It's just that Java is too cool.

I must have missed something. Since when did interpreters become as fast as compilers?

Apparently this is only possible with partial compilation, i.e. interpreters are not pure.

Have you ever wondered how much startup time it takes? How much memory is gobbled up and how many threads the JVM runs to compile bytes of code? I ran monster that compiled hello world on the fly and it ended up with both nativ. Except C monster doesn't have one. And about python.

Forum on trading, automated trading systems and strategy testing

MetaTrader 5 Python User Group - How to use Python in Metatrader

Vict, 2019.12.07 07:12

About python - recently talked about ranger (file manager), which is written in it. I've used it for a few days and my impressions are that it's a cool idea with interesting features, but python is really slow (if some complicated tasks are performed in the background). Ripped it off, I don't know why people like python so much. Put a similar thing on C.

Well ok - buy a multi-core number crusher with a wagon of RAM and say my java/sharp/... are very cool in this test, and let's keep quiet about the overall load. They'll never catch up with C. Progress, take tetris from the 80s, rewrite it in sharpe, and race as fast as before, but with a 60 core CPU)).

ZS: akin to how two threads in Elbrus are only involved in broadcasting from x86 instructions. BelAZ transporting a parcel.

 
By the way, as for Sharp, it looks like the little softwares made it possible to directly compile to native code. I haven't tried it yet, but it should be cool.
1...146147148149150151152153154155156157158159160...274
New comment