Help with OOP - page 7
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
Incorrect comparison, as it does not take into account the time for automatic removal of objects.
Modified.
Where 123 megabytes after V3 comes from, I don't know.
No, it is correct. And this is a point of principle. Automatic deletion doesn't happen in the main thread, where the time cost is extremely expensive. You can start a new run without waiting for the parallel thread to return the used memory back. Yes, it will be called too and it will consume CPU resources too, but it will be a side operation executed in the background. With any optimization, even the most aggressive one, a part of the CPU's resources will be available to other threads because this is the way all modern operating systems work nowadays. To put a 100% load on the CPU in modern processors is next to impossible.
--
Let me put it another way. Suppose there is a task to be executed in 5 time units. You can execute it either with one thread in 5 units, or with two threads in 3 and 2 units respectively. Obviously, the total execution time would be the same: 5 units, but the physical time needed in the second case would be 2 units less since the task is concurrent in the second case and not in the first one. There is a counterargument that optimization occupies all available physical cores of the CPU. But this is not true. Any optimization will at best allocate a number of threads equal to the number of cores in the OS. However, in addition to these tasks hundreds of other tasks will be executed in OS, and all 8 cores of processor (if there are eight of them) will be divided between hundreds of threads of system, instead of 8 threads allocated by optimizer. So, allocating one more thread in 8+1 or 8+8 mode, is always more sensible than naively thinking that once an application has allocated 8 threads, it will use all the CPU resources with 100%.
--
In general, it's amusing to hear arguments like"we don't count this time, because the total time of the whole system includes it."Or the argument that"methods of objects created through new are called slower" - If so, we should probably discount the benchmark by this time, because it's unfair when methods are called slower one way and faster the other way)))))) Well in that case, why pretend we're drowning in performance? Just let's face it, we're from the 90's and admit nothing but the false slogans "assembler is faster anyway!" or "when I work with pointers, I control everything".
--
Second point. Pay attention to V2. There there is no object deletion and a direct memory leak is purposefully committed. Even so, object allocation takes 1.4 seconds versus 1.2 seconds in V1, although no time is spent on deleting at all.
I don't know where 123 Mbytes comes from after V3.
It's hard to say. You need to know the specification of the mql virtual machine. But no one knows this, except the developers. Judging by analysis in ProcessHacker, it looks like the objects selected through * new are allocated individually in one place in some tricky way and then moved to another memory area as large arrays. I.e. it could be some temporary objects or something else.
No, correct. And this is a point of principle. Automatic deletion does not happen in the main thread, where the time cost is extremely expensive. You can start a new run without waiting for the parallel thread to return the used memory back. Yes, it will be called too and it will consume CPU resources too, but it will be a side operation executed in the background. With any optimization, even the most aggressive one, a part of the CPU's resources will be available to other threads because this is the way all modern operating systems work nowadays. To put a 100% load on the CPU in modern processors is next to impossible.
--
Let me put it another way. Suppose there is a task to be executed in 5 time units. You can execute it either with one thread in 5 units, or with two threads in 3 and 2 units respectively. Obviously, the total execution time would be the same: 5 units, but the physical time needed in the second case would be 2 units less since the task is concurrent in the second case and not in the first one. There is a counterargument that optimization occupies all available physical cores of the CPU. But this is not true. Any optimization will at best allocate a number of threads equal to the number of cores in the OS. However, in addition to these tasks hundreds of other tasks will be executed in OS, and all 8 cores of processor (if there are eight of them) will be divided between hundreds of threads of system, instead of 8 threads allocated by optimizer. So, allocating one more thread in 8+1 or 8+8 mode, is always more sensible than naively thinking that once an application has allocated 8 threads, it will use all the CPU resources with 100%.
--
In general, it's amusing to hear arguments like, "Well, we don't count this time because the total time of the whole system includes it."Or the argument that"methods of objects created through new are called slower" - If so, we should probably discount the benchmark by this time, because it's unfair when methods are called slower one way and faster the other way)))))) Well in that case, why pretend we're drowning in performance? Just let's face it, we're from the 90's and admit nothing but the false slogans "assembler is faster anyway!" or "when I work with pointers, I control everything".
--
Second point. Pay attention to V2. There there is no object deletion and a direct memory leak is purposefully committed. Even then, object allocation takes 1.4 seconds versus 1.2 seconds in V1, though no time is spent on deleting at all.
It's hard to say. You need to know the mql virtual machine's specification. And no one knows this except the developers. Judging by analysis in ProcessHacker, it looks like the objects selected through * new are allocated individually in one place in some tricky way and then moved to another memory area as large arrays. I.e. it could be some temporary objects or something else.
So if the deletion is not in the main thread, what difference does it make if it's included in the measurement or not? It's not like it's going to affect)))) So why not include it to see the truth?
And by the way Vasily, there 's a question waiting for you there (last line).
... Or the argument that"methods of objects created with new are called slower"...
Don't you have the guts to measure it? You're an empty shell, Vasya, you rattlesnake.
Don't you have the guts to measure?
Will you just sleep it off!
Just sleep it off!
Dream... and stomp your feet...
So if the deletion is not in the main thread, what difference does it make if it is included in the measurement or not? It's not like it's going to affect)))) So why not include it to see the truth?
Well then include in the benchmark the total time spent by Explorer, telegram, Chrome running during optimization. Even if you kill them all, and leave only MT, there will be a hundred other system threads that will waste CPU time, include them.
Well then include in the benchmark the total time spent by Explorer, telegram, Chrome running during optimization. Even if you kill all that, and leave only MT, there will be a hundred other system threads that will waste CPU time, include them.
It's in parallel threads))) (© Vasya)
Vasya, you're really stupid!
But keep going, keep persisting.
And by the way, Vasily, there 's a question waiting for you there (last line).
You can prove that you're an empty-headed and zero coder in no time at all. But who and why would need it when you're proving it year after year, fouling literally every thread on this forum. I've spent two years without posting anything here, only occasionally looked - and every time, in every thread was you, with your "authoritative opinion" in the style of "you're all morons, do not understand anything, and how to do - I will not say. You're a rotten man, Dima.
You can prove that you're an idiot and a zero coder in no time at all. But who needs it when you prove it year after year, shitting on literally every thread on this forum. I've spent two years without posting anything here, only occasionally looked - and every time, in every thread was you, with your "authoritative opinion" in the style of "you're all morons, do not understand anything, and how to do - I will not say. You're a rotten man, Dima.
What? The problem is I don't tell you how to do it right?
Yes, and you've already proved something very well here))
And I'm the one who's rotten? You're the one with both diarrhoea and scrofula when I write code.