Is MQL compiled or interpreted? - page 5
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
In other words, why are you arguing about this? What difference does it make whether it is compiled, byte-code or interpreted?
By knowing it, will it make it run any faster (or slower)? Will it make you change how you code things? Will it make you a better trader? Do you have any say in the matter? Can you change how MetaTrader works?
NO!
Instead of concentrating and discussing issues that do matter and can make your MQL code better or your trading better, you are wasting your time and energy “arguing about the gender of angels”.
...you are wasting your time and energy “arguing about the gender of angels”.
I can recognize an interpreter when I see it, and from 2009 when I started with MQL4 I don't believe there was any.
alphatrading:
2. The new 64-bit MQL5 compiler is faster than the current MQL5 from 2 to 10 times. <=== This is because of the switch from interpreted to compiled.
That's sort of the way I am leaning, too; that MT4 and maybe an earlier version of MT5 were interpreted, but that this has changed with later versions of MT5.
Instead of concentrating and discussing issues that do matter and can make your MQL code better or your trading better, you are wasting your time and energy “arguing about the gender of angels”.
I come to see where this thread has gone between compilations of my MQL5 code. :-D
I don't see this as a serious topic for the very reason(s) you mention, but I do find it interesting.
As you obviously know things better than the CEO himself it makes no sense to argue with you.
Look at page 2 post #13 from Vasiliy sokolev:
"Received the first performance compare old and new compiler on a real example of a large project (~ 20 000 lines of source code)."
And they go on talk about old and new compilers, who said something about interpreter?
And yes, I happen to know more about compilers in my past.
And if the old was interpreter, they had to mention that they saved the whole interpretation time - this is the main advantage moving from interpreter to compiler. This was never mentioned.
Moreover, the tests have been made on a standard compilers benchmarks, and do not include interpretation.
I come to see where this thread has gone between compilations of my MQL5 code. :-D
I don't see this as a serious topic for the very reason(s) you mention, but I do find it interesting.
It was never interpreter since MT4 (I don't know about MT3). In MT4 it was a byte code (look at this article and the comment from MQ below - the article has incorrect statement about bytecode in MQL5). After this they improved MQL5 and made MQL4 almost the same as MQL5 (except for trading APIs), both are compiled to native code. And, yes they generate 2 versions of the code both for 32 and 64 bits and pack them into the single executable (to choose an appropriate variant at runtime). You may find more discussions again on the russian forum.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Обсуждение статьи "Отладка программ на MQL5"
Renat Fatkhullin, 2013.03.01 13:24
At the first stage of compilation, universal bytecode is stored, but when executed in the terminal, this byte code is fully 100% translated into native 32 or 64 bit code with additional optimization. It is due to the translation into the native code that we have multiply raised the speed of execution of MQL5 programs compared to MQL4.
Pure bytecode without translation to native was in MQL4.
But the question was about a "normal" compilation... how is the exact line number and char known to the terminal when the program was explicitly compiled NOT using the debugger?
Even "normal" compilation does store symbolic information taken from the source. Very minimal information.
PS. In addition to "fat" debug version (with extended metadata), they also can produce another kind of "fat" versions for profiling.
"Module ex5 contains both versions of the code at once (32 bit and 64 bit)."
That's interesting.
Anyway, let me explain why I feel prior versions were interpreted. Feel free to shoot this with bullets.
1. It just felt that way. Everything was run through the MetaQuotes environment. I've not seen anyone say, "Oh, just change the .ex4 to .exe and run it." MT4 always felt clunky to me, like there were extra layers involved. I realize this is just a gut feeling, but there you have it.
2. Something Enrique pointed out . . . MT4 code was easily decompiled. I may be showing my ignorance, but wouldn't P-code be easier to decompile than a .exe? Yes, I realize they have taken steps to obfuscate (or fuzzification—what a great word!) since the MT4 days. But have you ever seen decompiled MT4 code? It looks like real code with the variable names changed. (For the record, I do not use decompiled code. I am a strong believer in rolling your own.)
3. I once architected a home software package. So what's the first thing you do when you design a software package for a company? Gather requirements.
So, I talked to the CEO, and he wanted it to be cross-platform. Oh hell. So I gave him some options of languages, libraries, etc. that would facilitate this. I tried to make it very clear that this would introduce unknowns and take more development time. That was all OK—he wanted it cross platform. Well, as you can image, the software was released on Windows-only, the Mac port never happened, and all those hours and design tradeoffs were wasted.
Thus, I imagine some sort of early discussions at MetaQuotes of a similar nature. "Oh, sure, we can have it write P-code, have it run through an interpreter, and the .ex4 (.ex3?) files can simply be copied between platforms." In fact, this actually sounds like a really cool thing to write.
Then somewhere around 2015 they realized they hadn't released anything for Mac, they already had a significant part of market-share, customer support was already a pain in the bum, and a user can simply run MetaQuotes products on Wine / Mac OS reasonably well. No reason to keep going with a non-native boondoggle any more.
- -
OK, I realize some of this is stretching a bit.