Речь идет об оперативной памяти. Скажем, у вас на сервере 2048 мб ОЗУ, она не увеличивается с каждым днем, то время, которое будешь тратить на экономию памяти таким образом, разумнее потратить на оптимизацию кода. Динамически выделять память под массивы, использовать подобие кэша и т.д Уменьшение расхода ОЗУ будет заметнее.
Ну это касаемо лишь игровых серверов. В действительности же, никого не волнует это. Спор на форуме, все равно что олимпиада среди умственно отсталых: даже если ты победил, ты все равно гермофродит. Хочешь остаться при своем мнении - держи его при себе.
Rockman, за 19 лет так и не научились выделять основную мысль
Quote (Ghost-X)
Ну это касаемо лишь игровых серверов. В действительности же, никого не волнует это.
В остальном - сейчас никого не волнует экономия памяти, поскольку память растет довольно быстро. У меня у самого отец программист, так он мне сказал такую вещь: Это раньше, память экономили, жесточайшие оптимизации, поскольку памяти было порядка 15-20 кбайт. Когда он начинал работать, им ставили память 4 мегабайта, хотя им было достаточно лишь одного.
Добавлено (07.02.2012, 13:23) --------------------------------------------- Еще добавлю - сказывается тот фактор, что программы пишутся не с целью экономии памяти, а с целью выпустить первыми.
Спор на форуме, все равно что олимпиада среди умственно отсталых: даже если ты победил, ты все равно гермофродит. Хочешь остаться при своем мнении - держи его при себе.
Сообщение отредактировал Ghost-X - Вторник, 07.02.2012, 13:19
Rockman, за 19 лет так и не научились выделять основную мысль
Здесь не может быть другой основной мысли. Если программист говорит: "А зачем мне оптимизация ? Сейчас оперативы у всех гигабайты. Пусть это их заботит", я думаю это плохой программист.
Добавлено (07.02.2012, 16:14) --------------------------------------------- Вы хотите сказать, что экономия ОЗУ волнует только программистов игровых серверов ?
ты думаешь прежде всего как скриптер игрового сервера, а не как программист) Говорю как есть. Выпустить первым - вот приоритет. А что касаемо памяти, это уже другая задача. Спор на форуме, все равно что олимпиада среди умственно отсталых: даже если ты победил, ты все равно гермофродит. Хочешь остаться при своем мнении - держи его при себе.
Ghost-X, никто не мешает писать код для софта "в процессе", таким образом, что бы он потреблял умеренное количество памяти. А если программист об этом не заботится, и сразу, первым делом втюхивает в код буфер на 300 метров, извините, это хреновый программист, и странно, что он вообще получил образование. More than 4 years of development, more than 250,000 lines of source code, more than a hundred units and more than 3400 revisions. Valakas Roleplay - choose your role.
Eakwarp, понятное дело, что преднамеренно не будет употреблять немеренное количество памяти. Больше экономии памяти мы получаем лишь при доп.оптимизации, когда просчитываем все до мелочей. Вот этот этап порой пропускают. Спор на форуме, все равно что олимпиада среди умственно отсталых: даже если ты победил, ты все равно гермофродит. Хочешь остаться при своем мнении - держи его при себе.
Помогали быстро проверять необходимые условия. А так же использовал битовый сдвиг влево, что бы ускорить умножение на 2 и вправо, что бы ускорить деление на 2
Откуда вы это берете? Сдвиг влево и сдвиг вправо на единицу не делает умножение/деление быстрее. Эту гипотезу я разрушил банально сравнив скорость выполнения операций на компиляторе gnu gcc, и результат оказался противоположным. Обычное деление и умножение на 15 миллисекунд быстрее, чем с побитовыми операторами сдвига на 100000000 итераций. К тому же, в рациональном коде, многие программисты отступают от правил того или иного компилятора, предпочитая для рутинного кода использовать свои прямолинейные обращения к данным по-средству введения ассемблерного кода, что повышает производительность в данных секторах. Касаемо рационального использования памяти, то опять-таки говоря о гибкости языка С/C++, дилемм не возникает. Все возможности для создания динамической структуры - есть, вопрос лишь в правильной обработке этих динамических данных, и опять же есть масса готовых инструментарий для динамической работы с данными (vector, lists, bitset, map и прочее).
В павн всегда не хватало гибкости в работе с данными в виду его не распространенности и без перспективности, но этого вполне достаточно для написания динамических, хотя и ограниченных систем.
Если же говорить о побитовых операторах, то я бы далеко не отбрасывал их на задний план. В рациональном программировании они встречаются довольно-таки часто. И суть их использования заключается в оптимизации. Яркий пример использования побитовых операторов состоит в том, чтобы передать в один аргумент несколько флагов и затем интерпретировать их соответствующим образом (OnPlayerKeyStateChange). Также побитовые операторы применяются для преобразования цвета в тот или иной формат при этом без потери самого цвета, изменение яркости, насыщенности, прозрачности и многие другое. Русскоязычныи портал о MTA/GTA-IV-MP | http://multi-theft-auto.ru
Откуда вы это берете? Сдвиг влево и сдвиг вправо на единицу не делает умножение/деление быстрее. Эту гипотезу я разрушил банально сравнив скорость выполнения операций на компиляторе gnu gcc, и результат оказался противоположным. Обычное деление и умножение на 15 миллисекунд быстрее, чем с побитовыми операторами сдвига на 100000000 итераций. К тому же, в рациональном коде, многие программисты отступают от правил того или иного компилятора, предпочитая для рутинного кода использовать свои прямолинейные обращения к данным по-средству введения ассемблерного кода, что повышает производительность в данных секторах. Касаемо рационального использования памяти, то опять-таки говоря о гибкости языка С/C++, дилемм не возникает. Все возможности для создания динамической структуры - есть, вопрос лишь в правильной обработке этих динамических данных, и опять же есть масса готовых инструментарий для динамической работы с данными (vector, lists, bitset, map и прочее).
В павн всегда не хватало гибкости в работе с данными в виду его не распространенности и без перспективности, но этого вполне достаточно для написания динамических, хотя и ограниченных систем.
Бывают случаи когда битовые сдвиги в разы быстрее обычного умножения, видел где то подробную статистику зависимости от типа переменных, от процессора и различных ситуаций, примерно в 50% сдвиги быстрее.
Quote (toneysix)
Если же говорить о побитовых операторах, то я бы далеко не отбрасывал их на задний план. В рациональном программировании они встречаются довольно-таки часто. И суть их использования заключается в оптимизации. Яркий пример использования побитовых операторов состоит в том, чтобы передать в один аргумент несколько флагов и затем интерпретировать их соответствующим образом (OnPlayerKeyStateChange). Также побитовые операторы применяются для преобразования цвета в тот или иной формат при этом без потери самого цвета, изменение яркости, насыщенности, прозрачности и многие другое.
Если говорить о pawn и о большинстве юзеров данного проекта, то ставить логические операторы в одном уроке с побитовыми не очень рационально. Большинство, я уверен, ничего не поняли о битовых операторах вообще.
Сообщение отредактировал Rockman - Вторник, 07.02.2012, 20:38
Бывают случаи когда битовые сдвиги в разы быстрее обычного умножения, видел где то подробную статистику зависимости от типа переменных, от процессора и различных ситуаций, примерно в 50% сдвиги быстрее.
Что значит "бывают"?
Quote
что бы ускорить умножение на 2 и вправо, что бы ускорить деление на 2
Я имею прямо противоположные результаты, которых я исследовал собственноручно. Поэтому не убедительно. Какие тут могут быть случаи - непонятно.
Quote
Если говорить о pawn и о большинстве юзеров данного проекта, то ставить логические операторы в одном уроке с побитовыми не очень рационально. Большинство, я уверен, ничего не поняли о битовых операторах вообще.
Эм, как можно сопоставлять рациональность к тождеству? xD Не знают - так узнают, не нужно ориентироваться на тех, кто этим профессионально не занимается. Да и потом, это не имеет никакого значения, от того, что в уроке присутствуют вполне уместно побитовые операторы - ни жарко, ни холодно никому не становится. Русскоязычныи портал о MTA/GTA-IV-MP | http://multi-theft-auto.ru
toneysix, я же описал, что это может зависеть от типа переменных, от конструкций в которых операции используются, от процессора и от многих других факторов. Не думаю, что в своих собственноручных исследованиях, вы использовали отличные от gcc компиляторы, различные ОС, процессоры и экспериментировали с типами.
Добавлено (07.02.2012, 21:20) --------------------------------------------- Так же есть разница в результатах при Debug и Release компиляциях.
Сообщение отредактировал Rockman - Вторник, 07.02.2012, 21:18
toneysix, я же описал, что это может зависеть от типа переменных, от конструкций в которых операции используются, от процессора и от многих других факторов. Не думаю, что в своих собственноручных исследованиях, вы использовали отличные от gcc компиляторы, различные ОС, процессоры и экспериментировали с типами.
Ваше описание выглядит не убедительно. Я проверял с типом INT, с разными знчениями, от больших, до маленьких, результат остается прежним. В среднем на 15 миллисекунд сдвиги вправо и влево на один проигрывают стандартным умножением и делением. Выбирайте правильный компилятор, все, что могу сказать я. Но, прочтите ещё раз ваш утвердительный тезис, который кроется в смысле вашего применения:
Quote
А так же использовал битовый сдвиг влево, что бы ускорить умножение на 2 и вправо, что бы ускорить деление на 2
Здесь ни слова о каких-то условиях. Я бы не говорил ничего, если бы уже не встречался с такими людьми, которые прочитав что-то, где-то, мыслят подобным образом. Поэтому мое убеждение для меня остается некой презумпцией, пока я не вижу действительно убеждающие в обратном данные. Приведите мне код, в котором деление на 2 будет быстрее стандартного способа, только потом будем о чем-то говорить. А если говорить о таких факторах, как влияние процессора, общей загруженности, значений, то пропадает истинный смысл использования данного способа в силу его не универсальности, ибо у одного будет быстрее, у другого медленнее - неоднозначность в программировании не ценится. Русскоязычныи портал о MTA/GTA-IV-MP | http://multi-theft-auto.ru
Сообщение отредактировал toneysix - Вторник, 07.02.2012, 21:34
Rockman Опять-таки, это частный случай, даже те, 15 миллисекунд это погрешность, не более того, на самом деле их можно приравнять. Мне нужен конкретно общий случай, который бы всегда позволял получать удовлетворяющий вариант. P.S: Вот мой код: http://best.of.by/paste/d155b2c2b Результаты: standart int: 3666 not standart int: 3760
standart int: 3697 not standart int: 3744
standart int: 3651 not standart int: 3678
gnu gcc Русскоязычныи портал о MTA/GTA-IV-MP | http://multi-theft-auto.ru
Сообщение отредактировал toneysix - Вторник, 07.02.2012, 22:49
