Помогите с ООП - страница 7
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Некорректное сравнение, т.к. не учитывается время на автоматическое удаление объектов.
Изменил.
Откуда берутся 123 мегабайта после V3 - не знаю.
Нет, корректное. И это принципиальный момент. Автоматическое удаление происходит не в основном потоке, где стоимость времени крайне дорогое. Вы можете приступить к новому прогону, не дожидаясь, когда параллельный поток вернет используемую память обратно. Да, он тоже будет вызван, и тоже потребует ресурсов ЦП, но это будет побочная операция выполняемая в фоне. При любой, даже самой агрессивной оптимизации, часть ресурсов ЦП будет доступна другим потокам, потому что сейчас так работают все современные ОС. Положить стрелку загрузки ЦП в современных процессорах в 100% сейчас практически невозможно.
--
Напишу иначе. Допустим есть задача выполняемая за 5 единиц времени. Можно выполнить ее либо одним потоком за 5 единиц, либо двумя за 3 и 2 единицы соответственно. Очевидно, что общее время выполнения будет одинаковым: 5 единиц, но физического времени потребуется в во втором случае на 2 единицы меньше, так как во втором случае, задача параллелится, а в первом нет. Существует контраргумент, согласно которому оптимизация занимает и так все доступные физические ядра ЦП. Но это не соответствует действительности. Любая оптимизация в лучшем случае выделит количество потоков, равное количеству ядер ОС. Однако в ОС по мимо этих задач будут выполнятся сотни других, и все 8 ядер процессора (если их восемь) будут делится между сотнями потоков системы, а не 8 потоками, выделенными оптимизатором. Таким образом, выделить еще один поток в режиме 8+1 или 8+8, всегда целесообразнее, чем наивно считать, что раз приложение выделило 8 потоков, оно задействует все ресурсы ЦП со 100%.
--
Вообще прикольно выслушивать аргументы вида "Вот это время мы не считаем, потому что суммарное время всей системы его включает." Или аргумент что "методы объектов созданных через new вызываются медленнее" - Ну раз так, мы наверное должны дисконтировать бенчмарк на это время, ведь это нечестно, когда методы одним способом вызываются медленнее, а другим быстрее)))))) Ну в таком случае, зачем притворятся что мы топим за производительность? Просто давайте признаемся что мы из 90-ых, и ничего кроме ложных лозунгов "ассемблер все равно быстрее!" или "когда я работаю с указателями - я все контролирую" не признаем.
--
Второй момент. Обратите внимание на V2. Там нет удаления объектов и целенаправленно допущена прямая утечка памяти. Даже в этом случае выделение объектов идет 1.4 сек. против 1.2 в V1, хотя время на удаление не тратится вообще.
Откуда берутся 123 мегабайта после V3 - не знаю.
Сказать сложно. Нужно знать спецификацию виртуальной машины mql. А этого никто кроме разрабов не знает. По анализу в ProcessHacker складывается впечатление что объекты выделенные через * new каким-то хитрым образом выделяются поштучно в одном месте, затем перемещаются в другую области памяти уже как большие массивы. Т.е. этим может быть какие-то временные объекты или что-то еще.
Нет, корректное. И это принципиальный момент. Автоматическое удаление происходит не в основном потоке, где стоимость времени крайне дорогое. Вы можете приступить к новому прогону, не дожидаясь, когда параллельный поток вернет используемую память обратно. Да, он тоже будет вызван, и тоже потребует ресурсов ЦП, но это будет побочная операция выполняемая в фоне. При любой, даже самой агрессивной оптимизации, часть ресурсов ЦП будет доступна другим потокам, потому что сейчас так работают все современные ОС. Положить стрелку загрузки ЦП в современных процессорах в 100% сейчас практически невозможно.
--
Напишу иначе. Допустим есть задача выполняемая за 5 единиц времени. Можно выполнить ее либо одним потоком за 5 единиц, либо двумя за 3 и 2 единицы соответственно. Очевидно, что общее время выполнения будет одинаковым: 5 единиц, но физического времени потребуется в во втором случае на 2 единицы меньше, так как во втором случае, задача параллелится, а в первом нет. Существует контраргумент, согласно которому оптимизация занимает и так все доступные физические ядра ЦП. Но это не соответствует действительности. Любая оптимизация в лучшем случае выделит количество потоков, равное количеству ядер ОС. Однако в ОС по мимо этих задач будут выполнятся сотни других, и все 8 ядер процессора (если их восемь) будут делится между сотнями потоков системы, а не 8 потоками, выделенными оптимизатором. Таким образом, выделить еще один поток в режиме 8+1 или 8+8, всегда целесообразнее, чем наивно считать, что раз приложение выделило 8 потоков, оно задействует все ресурсы ЦП со 100%.
--
Вообще прикольно выслушивать аргументы вида "Вот это время мы не считаем, потому что суммарное время всей системы его включает." Или аргумент что "методы объектов созданных через new вызываются медленнее" - Ну раз так, мы наверное должны дисконтировать бенчмарк на это время, ведь это нечестно, когда методы одним способом вызываются медленнее, а другим быстрее)))))) Ну в таком случае, зачем притворятся что мы топим за производительность? Просто давайте признаемся что мы из 90-ых, и ничего кроме ложных лозунгов "ассемблер все равно быстрее!" или "когда я работаю с указателями - я все контролирую" не признаем.
--
Второй момент. Обратите внимание на V2. Там нет удаления объектов и целенаправленно допущена прямая утечка памяти. Даже в этом случае выделение объектов идет 1.4 сек. против 1.2 в V1, хотя время на удаление не тратится вообще.
Сказать сложно. Нужно знать спецификацию виртуальной машины mql. А этого никто кроме разрабов не знает. По анализу в ProcessHacker складывается впечатление что объекты выделенные через * new каким-то хитрым образом выделяются поштучно в одном месте, затем перемещаются в другую области памяти уже как большие массивы. Т.е. этим может быть какие-то временные объекты или что-то еще.
Ну так если удаление не в основном потоке выполняется, то какая разница, включено оно в измерение или нет? Оно же не повлияет)))) Поэтому, почему бы не включить, чтобы увидеть правду?
И кстати между прочим, Василий, вас там вопрос ждет (последняя строка).
... Или аргумент что "методы объектов созданных через new вызываются медленнее"...
А измерить у тебя тяма не хватит? Шалаболка ты пустая, Вася, погремушка.
А измерить у тебя тяма не хватит?
Да проспись ты уже наконец!
Да проспись ты уже наконец!
Мечтай... и ножками потопай
Ну так если удаление не в основном потоке выполняется, то какая разница, включено оно в измерение или нет? Оно же не повлияет)))) Поэтому, почему бы не включить, чтобы увидеть правду?
Ну тогда включи в бенчмарк суммарное время затраченное Explorer, telegram, Chrome запущенными во время оптимизации. Даже если ты все это поубиваешь, и оставишь только МТ, будет еще сотня другая системных потоков, которые будут тратить время ЦП, включай их.
Ну тогда включи в бенчмарк суммарное время затраченное Explorer, telegram, Chrome запущенными во время оптимизации. Даже если ты все это поубиваешь, и оставишь только МТ, будет еще сотня другая системных потоков, которые будут тратить время ЦП, включай их.
Оно же в параллельном потоке))) (© Вася)
Вася, ты реально тупой!
Но продолжай, продолжай упорствовать.
И кстати между прочим, Василий, вас там вопрос ждет (последняя строка).
Доказать что ты пустобрех и нулевой кодер можно на раз два. Но кому и зачем это нужно, если ты это доказываешь год от когда засерая буквально каждую ветку этого форума. Я два года сюда ничего не постил, лишь изредко смотрел - и всякий раз, в любой ветке был ты, со своими "авторитетным мнением" в стиле "вы тута все дебилы, ничего не понимаете, а как нужно - не скажу". Гнилой ты человек, Дима.
Доказать что ты пустобрех и нулевой кодер можно на раз два. Но кому и зачем это нужно, если ты это доказываешь год от когда засерая буквально каждую ветку этого форума. Я два года сюда ничего не постил, лишь изредко смотрел - и всякий раз, в любой ветке был ты, со своими "авторитетным мнением" в стиле "вы тута все дебилы, ничего не понимаете, а как нужно - не скажу". Гнилой ты человек, Дима.
Что? Проблема в том, что я не рассказываю как правильно?
Да, и ты уже очень классно доказал здесь кое что))
И это я-то гнилой? Это у вас здесь и понос и золотуха начинается, когда я код пишу.