Asynchronous and multi-threaded programming in MQL - page 37

New comment
 

I understood why std::async is so slow. The thing is that I have linux+gcc/clang, there is no thread pool behind async, a new thread is stupidly started every time for each new job. What confused me was that two threads created consecutively and immediately destroyed would have the same id:

void f() {
   cout << this_thread::get_id() << endl;
}

int main()
{
   thread t1{f};
   t1.join();

   thread t2{f};
   t2.join();
   return 0;
}
// cout: 140448079447808
// cout: 140448079447808

The async test on wind+msvc showed that in the test where gcc started 10 threads, msvc started 6 (4-core CPU), i.e. it is not a dumb new thread starting for the task, there is obviously some kind of queue.

Conclusion: more or less adequate async only on winnda (via thread pool).

В моём случае это точно, так как понял что пул статичный по количеству потоков, мне это не подходит.

The pool is not static and the size can be changed. But as if you strongly control async() :), as-is evident - the standard does not even guarantee implementation (a thread pool or not), and if it is a pool, you do not have any influence on it (the compiler may want to assign 1 thread to the pool, it will not even ask you).

But if you are writing only for the wind, then you can use async in principle (although I don't like it now).

SZY: why we need async without thread pool I don't understand at all ...

 
Vict:

I understood why std::async is so slow. The thing is that I have linux+gcc/clang, there is no thread pool behind async, a new thread is stupidly started every time for each new job. What confused me was that two threads created consecutively and immediately destroyed would have the same id:

The async test on wind+msvc showed that in the test where gcc started 10 threads, msvc started 6 (4-core CPU), i.e. it is not a dumb new thread starting for the task, there is obviously some kind of queue.

Conclusion: more or less adequate async only on winnda (via thread pool).

The pool is not static and the size can be changed. But as if you strongly control async() :), as-is evident - the standard does not even guarantee implementation (a thread pool or not), and if it is a pool, you do not have any influence on it (the compiler may want to assign 1 thread to the pool, it will not even ask you).

But if you are writing only for wind, then async could be used (although I don't like it now).

SZY: I don't understand why we need async without thread pool ...

Given the results of the experiment and the new information, has your opinion on the need for multi-threading in MQL changed?
 
Реter Konow:
Taking into account the results of the experiment and new information, has your opinion concerning the necessity of multithreading in MQL changed?

Well I've been winging async here - a high-level wrapper for the lazy. In general, I'm not against multithreading.

Would I use multithreading in µl? No, I won't. Peter, I'm past the marketplace, and frankly I'm not much interested in a closed ecosystem with a powerful language. Why create another C++ (which is not an easy task at all)? So that the most "enterprising" would selltheir "grails" strictly through the marketplace? Well, it's not that kind of mission.

 
Vict:

Well I've been winging async here - a high-level wrapper for the lazy. In general, I'm not against multithreading.

Would I use multithreading in µl? No, I won't. Peter, I'm past the marketplace, and frankly I'm not much interested in a closed ecosystem with a powerful language. Why create another C++ (which is not an easy task at all)? So that the most "enterprising" would sell their "grails" strictly through the marketplace? Well, it's not that kind of mission.

Well, it's probably the other way around. So that the most enterprising would sell something other than"grails". After all, it is the "grails" that do not require serious tools. If new powerful applications appear, perhaps "grail-parasitism" in algotrading will decline and the value of professional approach will prevail. Not a fact, of course, but it may be...
 
Vict:

Will I use multithreading in µl? No, I won't.

At least one sincere answer to the question: why do you need multithreading in MQL-problems?

If I'm not mistaken, I asked it 5 times without any specific answers.

ReTeg Konow:
Well, it's probably the other way around. For the most enterprising to sell something other than "grails". After all, it's the "grails" that don't require serious tools.

Peter, you have a talent of making loud statements due to low competence!

If I'm not mistaken, you have no skills at all in writing trading Expert Advisors, even a simple open/close one indicator, and now you are saying that it doesn't take serious tools to create an Expert Advisor that trades on a purely positive history?

Try to write just one trading Expert Advisor - a world of exciting adventures awaits you!

))))

 
Igor Makanu:

At least one sincere answer to the question: why do we need multithreading in MQL-problems?

If I'm not mistaken, I asked 5 times why it's needed, no answers were given, there were attempts to link threading to NS training, but in my opinion "past it".

Peter, you have a talent of making loud statements due to low competence!

If I'm not mistaken, you have no skills at all in writing trading Expert Advisors, even a simple open/close one indicator, and now you are saying that it doesn't take serious tools to create an Expert Advisor that trades on a purely positive history?

Try to write just one trading Expert Advisor - a world of exciting adventures awaits you!

))))

I don't want to start an off-topic in the thread, but you also have a talent for making loud statements due to low competence. In this case, you don't know my capabilities and experience. I have never written indicators, it's true, but I have written them. And what about your statements about the Sharpe in MQL, that must have crushed my developments? That I cannot do anything serious with my approach and that everything works badly, etc.? High competence? )

Just look at the marketplace to see that (almost) nothing but"grails" are sold there. 13000 "grails" and 1000 utilities, indicators and libraries. At a guess. Consequently, it is easy to make these "grails". Especially on MT4. And it is creation of the "grails" that defines the MQLQL-development toolkit in great demand, putting a barrier for application development.

 
Реter Konow:

I don't want to start an off-topic, but you also have a talent for making loud statements due to low competence. In this case, you do not know my capabilities and experience. I have never written indicators, it's true, but I have written experts and done a lot of them. And what about your statements about the Sharpe in MQL, that must have crushed my developments? That I cannot do anything serious with my approach and that everything works badly, etc.? High competence? )

Just look at the marketplace to see that (almost) nothing but "grails" are sold there. 13000 "grails" and 1000 utilities, indicators and libraries. At a guess. Consequently, it is easy to make these "grails". Especially on MT4. And it is creation of the "grails" that defines the MQLQL-development toolkit in great demand, putting a barrier for application development.

strange, if you were writing trading experts, why did you have questions in the "my approach" thread about elementary actions, how to get the properties of an open order? (when you wrote the table), just like now, the loud statement that writing a tester grail is not labor intensive?

well since you know how to do everything, then you didn't make a good joke?


my claims about Sharp are on my blog and in KB in@fxsaber's publications, everything works and so do the tables, and@fxsaber was testing under his vision of how tables should work, in this turned out to be quite difficult technical implementation - he needed to display a table of deal history over 6000 rows on 20 columnsover 100 thousandvalues! and in the second tab current open orders as 19 columns of information, everything works and nothing is slow neither online nor in the tester ;) . The main thing is that it does not overload the terminal and the PC in general ( I have tested it and it takes 7-8% of CPU load neither on PC nor on laptop)

PS: about Market will not say anything and you do not advise, see my pre-post - neither you nor I am not published there, respectively, the level of competence is zero ;)

PSPS: you're too keen on some kind of a battle )))) to prove that Sharp is inferior to your work by the speed of writing applied software? )))) - well try in your "My Approach" thread to post a table with at least10k cells, see how it works;)

 
Igor Makanu:

strange, if you were writing trading experts, why did you have questions in the "My approach" topic about elementary actions, how to get the properties of an open order? (when you wrote the table), just like now, the loud statement that writing a tester's Grail is not labor-intensive?

well since you know how to do everything, then you didn't make a good joke?


my claims about Sharp are on my blog and QB in@fxsaber's publications, everything works and so do the tables, and tested by @fxsaber to his vision of how tables should work, in this one turned out to be quite a difficult technical implementation - he needed to display a table of trade history over 6000 lines in 20 columns ~ 12 000values and in the second tab the current open orders as 19 columns of info, everything works and nothing is slow neither online nor in tester ;) . The main thing is that it does not overload the terminal and PC in general ( I checked it and it was not over 7-8% CPU load either on PC or laptop).

PS: I will not say anything about Market and I advise you not to, see my pre-post - neither you nor I am not published there, respectively, the level of competence is zero ;)

The order history was not necessary in my strategies and I have not worked with it, but it does not mean that I do not know how to open orders, etc. Besides, I worked with EAs a long time ago. But it is all very simple, (especially with my approach). I do not have difficulty in creating a trading Expert Advisor. The level of difficulty in creating charts is much higher, and that is why there are a lot of Expert Advisors and almost no charts. (Ask@fxsaber.) And I've been waiting for an article about connecting Sharp tables for a long time. (Only you won't get my level of connectivity ease, take my word for it. :))

Market seller status hardly makes one a thinker and opens one's eyes to the existential problems of algotrading.)

 
Igor Makanu:
...

PSPS: you're just itching for some kind of battle )))) to prove that Sharp is inferior to your work in terms of speed of writing application software? )))) - well, try in your topic "My approach" to post a table with at least 10 thousand cells, see how it works;)

I posted a table in MQL4 with 1000 rows and each row had more than 20 cells in it. In total more than 20 thousand cells. You saw it. It worked very fast. Look again, if you do not believe me. I underline MQL4. It would work 10 times faster on a 5.

 
Реter Konow:

I posted a table there on MQL4 with 1000 rows and each row had more than 20 cells in it. In total over 20k cells. You have seen it. It worked very fast. Look again, if you do not believe me. I underline MQL4. It would work 10 times faster on a 5.

Even if it's a million cells. If you can see a maximum of 1000 of them on the screen, why update/draw everything?

1...3031323334353637383940
New comment