Амбициозные идеи !!! - страница 5
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вы ошибаетесь так как не знаете простейших вещей.
Данные любых массивов располагаются в памяти линейно. От первого до последнего, при этом чтобы обратиться к элементу x[15], то для вычисления этой переменной компилятор вычислит адрес начала массива плюс смещение 15 что и будет адресом переменной. При двумерном массиве например x[2][5], сначала нужно вычислить смещение для второй строки а потом прибавить к ней смещение для 5 элемента, то есть в два раза большее количество операций.
x[2] [5] --> х[((2-1)* ArrayRange(x[0])+5)]
x[15] --> x(+15)
это все на уровне компилятора, но ArrayRange(x[0]) для статического массива ВСЕГДА неизменно, его не нужно вычислять постоянно, достаточно один раз посчитать и сохранить на стадии компиляции
Вы занимаетесь ассемблером? к чему эти проблемы? если занимаетесь ассемблером, то увы - русской документации, по ПРАВИЛЬНОЙ загрузке конвейера команд процессоров старше Pentium-I я не видел, да и ПРАВИЛЬНОЙ загрузкой процессора занимаются даже не разработчики компиляторов, а разработчики ОС и архитектуры процессоров
если Вы переживаете, что выполнение операции умножения будет выполняться в тактах процессора дольше операции сложения, то увы - поезд ушел вместе с 486-м процессором, загрузка кэшей и конвейеров команд занимает больше времени чем выполнение арифметических и логических операций
ЗЫ: еще раз обращаюсь - начинайте читать первоисточники, вот https://www.mql5.com/ru/docs/basis/types/classes разработчики mql5 описывают как ПРАВИЛЬНО организовать выравнивание данных, такая же инфа есть по всем компиляторам, есть инфа как правильно использовать вызов системных ф-ций Windows и т.п. - пишу это к тому, что русской документации, соответствующей современным возможностям ОС и процессоров очень мало, а то старье - материал которому учат в колледжах и ВУЗах - не соответствует действительность на данном этапе развития ОС и железа
x[2] [5] --> х[((2-1)* ArrayRange(x[0])+5)]
x[15] --> x(+15)
это все на уровне компилятора, но ArrayRange(x[0]) для статического массива ВСЕГДА неизменно, его не нужно вычислять постоянно, достаточно один раз посчитать и сохранить на стадии компиляции
На стадии компиляции вычисляется лишь адрес первого элемента. Все остальные элементы будут считаться в режиме счета через смещение, которое каждый раз разное.
При двумерном массиве нужно посчитать два смещения по столбцам и по строкам помноженным на номер строки и тоже разумеется в процессе счета. Асемблер и компилятор тут ни причем абсолютно, это просто основы адресации памяти для правильного использования выч. ресурсов на практике.
Отсюда Вы легко поймете что если даже между одномерным и двумерными массивами есть такая значительная потеря производительности, то время адресации тем более значительно замедлится при более сложных случаях, например объектах.
На стадии компиляции вычисляется лишь адрес первого элемента. Все остальные элементы будут считаться в режиме счета через смещение, которое каждый раз разное.
При двумерном массиве нужно посчитать два смещения по столбцам и по строкам помноженным на номер строки и тоже разумеется в процессе счета. Асемблер и компилятор тут ни причем абсолютно, это просто основы адресации памяти для правильного использования выч. ресурсов на практике.
Отсюда Вы легко поймете что если даже между одномерным и двумерными массивами есть такая значительная потеря производительности, то время адресации тем более значительно замедлится при более сложных случаях, например объектах.
успехов в понимании сути происходящего и потери производительности
у меня нет проблем с оптимизацией компиляторов и написания своих конструкций по доступу к данным
ЗЫ: объекты не являются сложными случаями - все манипуляции по созданию связей - все на уровне компилятора, увы процессору все равно объект это или нет, он не имеет проблем с вычислением смещений относительно выровненных данных, даже если "чудо программист" экономит память - пишет данные в массивы типа byte,но не заглядывает в документацию к компилятору, то эффективность такого кода будет видна только в отражении самодовольной физиономии этого программера в зеркале, а на самом деле это фейк
все на уровне компилятора, увы процессору все равно объект это или нет, он не имеет проблем с вычислением смещений относительно выровненных данных
Вроде как только что на простом примере Вам было объяснено насколько будет тормозить двумерный массив относительного одномерного в процессе выполнения программы, а не компилирования. Не вижу смысла повторяться. Отсюда видно что задачей написания более-менее оптимального вычислительного кода вы себя не сильно утруждаете, возможно оно Вам и не надо. В таком случае ООП создано прямо для Вас. :)
Ты мыслишь категориями амебы :) .
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%" (с) Дональд Кнут
Раз четвертый уже на этом форуме цитирую.
Вроде как только что на простом примере Вам было объяснено насколько будет тормозить двумерный массив относительного одномерного в процессе выполнения программы, а не компилирования. Не вижу смысла повторяться. Отсюда видно что задачей написания более-менее оптимального вычислительноо кода вы себя не сильно утруждаете, возможно оно Вам и не надо. В таком случае ООП создано прямо для Вас. :)
о каком оптимальном коде идет речь? Вы совершенно не представляете как работают компиляторы и виртуальные машины
программисту нет необходимости выяснять как идет доступ и адресация к физическим элементам памяти в каждом конкретном компиляторе(да хоть по диагонали, а не в столбик - тут ничего не поделаешь) - это задача разработчиков, если программиста не устраивает код - он оптимизирует свой код:
- путем увеличения размера кода и уменьшения размера данных и теряет скорость вычисления
- увеличивает размер данных в коде и приобретает бОльшую скорость
- как вариант использует другой компилятор
ВСЕ ВАРИАНТОВ больше нет!
ООП - это еще одна ветвь для написания ЭФФЕКТИВНОГО кода, эффективность ООП в том, что программист может составить математические модель в виде некой архитектуры - тем самым добиться многофункциональности своего кода, если Вы выдумываете, что в классах иной вид адресации для физического доступа к данным - вы заблуждаетесь, тот микроскопический дополнительный объем данных - таблица связей обьекта ни в коей мере не увеличит время доступа к физическим данным в памяти, а излишек данных будет с лихвой компенсирован многофункциональностью
я в шоке - Вы начали гадить на ООП, потом перешли в рассуждения об адресации в многомерных и одномерных массивах - Вас этому где-то учили, или так - все домыслы и фантазии?
работа с многомерными массивами давно реализована на уровне железа - тот же Z- буффер при работе видеокарт, ах, да "бараны разработчики железа" - не посоветовались с Вами и не узнали, насколько эффективна адресация многомерных массивов, так и не советуясь с Вами - все программисты не задумываясь используют многомерные массивы и не ищут счастья в увеличении кода ради мнимой эффективности при работе с одномерными массивами
А разве достоверность информации зависит от того кто её излагает? Вроде любой здравомыслящий человек должен понимать что информация это вещь объективная, а не субъективная. :)
если программиста не устраивает код - он оптимизирует свой код:
- путем увеличения размера кода и уменьшения размера данных и теряет скорость вычисления
- увеличивает размер данных в коде и приобретает бОльшую скорость
- как вариант использует другой компилятор
ВСЕ ВАРИАНТОВ больше нет!
Оптимизация кода требует от программиста минимального понимания того насколько будет тот или иной фрагмент кода ресурсоемкой в плане производимых элементарных операций (сложение, умножение, обращение к памяти, вычисление адреса и т.п). Без этого никакая оптимизация в принципе невозможна и никакой даже самый лучший компилятор против такого горе-программиста будет бессилен. Вроде вещь очевидная, но вижу что и это для многих может оказаться большой новостью. :)
А любой человек, задавшийся целью разобраться в вопросе, поймет, что информация, как, кстати, и ее количество, - вещь субъективная, а не объективная.:))
Ну нужно путать и смешивать в гремучую смесь разные вещи. :)
Одно это источник информации который объективен, а другое - это приемник, который субъективен ибо не всегда способен воспринять всю информацию, а только её часть.