My approach. The core is the engine. - page 39
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
Imho, gui for mql is important and necessary (and maybe a metalanguage too). But if it's done without OOP, it says more about the state of mind of its author, not about the method. 38 pages in 4 days is cool. Apparently, everyone likes this state of mind.
How much will you save on matches?
How much will you save on matches?
What matches?
In short, you guys are wrong to keep cornering Peter and in the process driving the topic into flub.
Peter has posted something of an engine. This can be compiled and run. Next, I hope to get constructive: discussing the engine, its interfaces and how to do this and that.
In short, you guys are wrong to keep cornering Peter and in the process leading the thread into flub.
Peter has posted something of an engine. This can be compiled and run. Next, I hope to start constructive: discussion on the engine, its interfaces and how to do this and that.
Details please - where you put it, what and how. There is nothing in the thread or in Peter's profile
If in the course of a 40-page flood, something was attached, it is not "posted" but "imposed" ... And in general, it violates the rules of the forum - a discussion of a commercial product
Nobody is arguing that direct access to a huge global array is faster than all these interface contrivances and type conversions. We can also think of design patterns, such as Visitor with double dispatch - there is a heck of a lot of overhead there.
However, all this is compensated by the convenience of support and modification. Unfortunately, maximum transferring of any thinking effort to computer has been mainstream programming development for a long time. It reaches a point that the sum of an arithmetic progression is calculated by means of a loop instead of using the well-known sum formula. In that sense, I agree with Peter that people are "degrading".
But, alas, there is no choice - either you "degrade" with everyone else, trying not to do it so fast, or you are hopelessly behind. And the fact that your programme is ineffective is of little importance.
Here I even see an analogy with competition in biology, in relations between predator and prey. The hare, running away from the wolf, is in fact competing not at all with the wolf, but with other hares. He does not need to get away from the wolf as fast as possible. It is much more important for him not to be the last to run away from the wolf. Because if he runs away last, he gets eaten, and if he runs away fastest, he uses more energy than necessary, and it can be spent on more useful directions.
It's the same with all sorts of programming technologies... The most efficient way to program in assembler, but it takes so much effort that it's useless - the energy is better spent more productively, even if the code isn't so efficient at that. Peter's array with global access is of the same sort. Accessing it is efficient, but remembering what lies where and how to access what takes too much effort.
Hm, I didn't think I was going to argue with you, have you looked at the calendar lately? What year is it? What inefficiency of interface spinoffs? Have you heard about memory organization and CPU level memory access and cache? ... again about the calendar.... there's no first "stump" anymore, it's 2018 and Intel-core processors
what assembler? i won't talk about the calendar.... but i can tell you that i bought the book on Pentium-1 back in 1996 and it was even "chewed up" how to load effectively the cache and how the pages of virtual memory will work, the whole book about 500-700 pages in one assembler, it was interesting and still real to program the processor
and now you want to load the CPU cache efficiently? - all you get by "gut feeling" is a constant cache dump and Pentium-1 level "efficient" assembly language program, only the LUT compilers with processor support released after 2010 can get the efficient and optimized code that will properly load the cache and the CPU pipeline
SZZY: These constant Windows "patches" (updates) are also work on optimizing the work of the OS with the processor, with memory and cache load, and here you are ... Count Monte Cristo!!! with the assembler!!! )))
...And anyway, it violates forum rules to discuss a commercial product
What are you talking about? What commercial product? Where is the link to it? Maybe it's available on the Market? Compiled ex4 can be downloaded and discussed.
Details please - where you posted it, what and how.
Page 30.
What are you talking about? What commercial product? Where is the link to it? Is it available on the Market? Compiled ex4 can be posted and discussed if anything.
it's a free and affordable product? where did you see it...where did you see the product we're discussing :-)
Peter does not hide the fact that the code will be closed and hesitates whether it will be paid and on what basis
Hm, I didn't think I'd be arguing with you, have you looked at the calendar lately? What year is it? What inefficiency of interface frills? Have you heard of memory organisation and CPU level memory access and cache? ... again about the calendar.... there's no first "stump" anymore, it's 2018 and Intel-core processors
what assembler? i won't talk about the calendar.... but i can tell you that i bought the book on Pentium-1 way back in 1996 with description of processor commands and it was even "chewed up" how to load effectively the cache and how virtual memory pages would work, the whole book about 500-700 pages in one assembler, it was interesting and still real to program the processor
and now you want to load the CPU cache efficiently? - all you get by "gut feeling" is a constant cache dump and Pentium-1 level "efficient" assembly language program, only the LUT compilers with processor support released after 2010 can get the efficient and optimized code that will properly load the cache and the CPU pipeline
SZZY: These constant Windows "patches" (updates) are also working on optimizing the work of the OS with the processor, with memory and cache load, and here you are ... Count Monte Cristo!!! with the assembler!!! )))
And how does it cancel my words?
C code tends to be close to assembly code, but it's still assembly code that gets the most efficiency. Whatever the year.
I don't understand about "loading CPU cache by gauge". That's why the assembler is used to load the cache as efficiently as possible ! What gauge method?
please give details - where, what and how. There is nothing in the thread or in Peter's profile
It would be a good idea to attach this post to the start page in order to reduce the number of such questions.
here. it would be a good idea to attach this post to the start page to reduce the number of such questions.
Let TC get to work and release the "kernel-motor"... put it in an accessible place and formulate the terms of use. And keep explanatory documentation there.
or else misguided users will have to scour the entire forum, reading all 3 volumes of 100 pages each :-)
he's been told for a year "do it already, stop talking" - but damn, another topic...