Добро пожаловать на Pro Pawn - Портал о PAWN-скриптинге.
Страница 2 из 2 ПерваяПервая 1 2
Показано с 11 по 16 из 16
  1. #11
    Аватар для Daniel_Cortez
    "Это не хак, это фича"

    Статус
    Оффлайн
    Регистрация
    06.04.2013
    Адрес
    Novokuznetsk, Russia
    Сообщений
    2,192
    Репутация:
    2589 ±
    Цитата Сообщение от Mike World Посмотреть сообщение
    Спасибо, а можете помочь с вывод компилятора?
    Наверняка можно сказать только одно: упаковка строк приводит к уменьшению расхода памяти под данные, а не к повышению расхода оной под код, так что это явно не связано с упаковкой. Точную причину здесь просто так не назовёшь, для этого нужно знать, как выглядел мод до и после. Может быть вы подключили какой-то инклуд, или ещё что-то, от чего мог "разрастись" код? Да что угодно.

    И да, как уже заметил DeimoS, упаковка строк - это не что-то сильно важное, этот приём просто помогает сэкономить немного памяти. Этим следует заниматься, когда пишете новый код, ставя "!" перед строками по привычке, а перешаривать ради этого весь мод - едва ли стоит того.
    Индивидуально в ЛС по скриптингу не помогаю. Задавайте все свои вопросы здесь (click).

  2. #12
    Аватар для Long-
    Пользователь

    Статус
    Оффлайн
    Регистрация
    02.11.2016
    Сообщений
    131
    Репутация:
    23 ±
    Цитата Сообщение от DeimoS Посмотреть сообщение
    Упаковка строк - это явно не то направление, которое следует выбирать, если ты хочешь заняться оптимизацией. Лучше займись переработкой алгоритмов, если в текущем виде мод создаёт лаги
    Я конечно понимаю что сейчас важно препроцессорное время и думаю о оптимизации памяти это последнее о чем нужно думать, но этот элемент тоже не стоит пропускать халатностью, т.е "Ай пофиг выделю 300 ячеек под текст с 3 символами."

  3. #13
    Аватар для DeimoS
    Модератор?

    Статус
    Оффлайн
    Регистрация
    27.01.2014
    Адрес
    Восточный Мордор
    Сообщений
    5,588
    Репутация:
    1984 ±
    Цитата Сообщение от Long- Посмотреть сообщение
    Я конечно понимаю что сейчас важно препроцессорное время и думаю о оптимизации памяти это последнее о чем нужно думать, но этот элемент тоже не стоит пропускать халатностью, т.е "Ай пофиг выделю 300 ячеек под текст с 3 символами."
    Не путай расточительное выделение памяти с паковкой строк.
    От того, что крупные скрипты писали без упаковки строк, ещё никто не умер. И смысла от этого столько же, сколько и от попытки экономить воздух, дабы завтра можно было подышать чуть больше.
    Связаться со мной в VK можно через личные сообщения этой группы
    Заказы не принимаю

    Широко известно, что идеи стоят 0.8333 цента каждая (исходя из рыночной цены 10 центов за дюжину).
    Великих идей полно, на них нет спроса.
    Воплощение идеи в законченную игру требует долгой работы,
    таланта, терпения и креативности, не говоря уж о затратах денег, времени и ресурсов.
    Предложить идею просто, воплотить – вот в чём проблема

    Steve Pavlina

  4. #14
    Аватар для Long-
    Пользователь

    Статус
    Оффлайн
    Регистрация
    02.11.2016
    Сообщений
    131
    Репутация:
    23 ±
    Цитата Сообщение от DeimoS Посмотреть сообщение
    Не путай расточительное выделение памяти с паковкой строк.
    От того, что крупные скрипты писали без упаковки строк, ещё никто не умер. И смысла от этого столько же, сколько и от попытки экономить воздух, дабы завтра можно было подышать чуть больше.
    А здесь разговор был только о паковки строк?
    Здесь еще вроде бы и паковке массива.

  5. #15
    Аватар для DeimoS
    Модератор?

    Статус
    Оффлайн
    Регистрация
    27.01.2014
    Адрес
    Восточный Мордор
    Сообщений
    5,588
    Репутация:
    1984 ±
    Цитата Сообщение от Long- Посмотреть сообщение
    А здесь разговор был только о паковки строк?
    Здесь еще вроде бы и паковке массива.
    Сути это не меняет, ибо строка - это и есть массив, который функции обрабатывают целиком, пока не встретят нуль-символ, преобразуя записанные в ячейках числа в символы :)
    Как я уже выше писал, задумываться об оптимизации памяти стоит в двух случаях: либо при возникновении проблем, либо при наличии свободного времени, которое некуда девать (хотя и тут я бы лучше уделил внимание разработки чего-то нового). А целенаправленно заниматься паковкой вообще, как уже правильно заметил Daniel Cortez, следует лишь тогда, когда ты просто привык паковать строки, ставя восклицательный знак перед ними. В остальных случаях ты лишь потратишь время на то, что на деле никакой видимой пользы не принесёт.
    Связаться со мной в VK можно через личные сообщения этой группы
    Заказы не принимаю

    Широко известно, что идеи стоят 0.8333 цента каждая (исходя из рыночной цены 10 центов за дюжину).
    Великих идей полно, на них нет спроса.
    Воплощение идеи в законченную игру требует долгой работы,
    таланта, терпения и креативности, не говоря уж о затратах денег, времени и ресурсов.
    Предложить идею просто, воплотить – вот в чём проблема

    Steve Pavlina

  6. #16
    Аватар для DeimoS
    Модератор?

    Статус
    Оффлайн
    Регистрация
    27.01.2014
    Адрес
    Восточный Мордор
    Сообщений
    5,588
    Репутация:
    1984 ±
    Хоть форум и откатился на пару дней, унеся с собой всю переписку, но не пропадать же писанине :)

      Открыть/закрыть
    Цитата Сообщение от Long- Посмотреть сообщение
    Лол. Раньше и всякой техники не было, но как то же жили, так же и мы не стоим на месте и делаем все для лучшей производительности.
    Плохой пример от профика как ты показывать всем новичкам то, что оптимизация не важна.
    Где я сказал, что оптимизация не важна? О_о


    Не путай оптимизацию с пессимизацией.
    Оптимизация - это когда у тебя есть проблемный код и ты пытаешься его сделать лучше с учётом того, что тебе нужно (либо оптимизируя память, либо оптимизируя скорость обработки).
    Пессимизация - это когда ты ещё не определил, проблемный ли перед тобой код или нет, но уже пытаешься его оптимизировать. Это схоже с тем, что ты сейчас начнёшь принимать инсулин (ибо вдруг у тебя сахарный диабет, о котором ты не знаешь), вместо того, чтоб обратиться к врачу, обследоваться и только потом начать принимать инсулин, если всё же диабет обнаружится.

    Как я уже говорил ранее, от того, что ты оптимизируешь и без того хорошо работающий год, ты ничего не изменишь, так как разница была бы ощутима лишь если бы старый код вызывал дискомфорт при игре.

    Цитата Сообщение от Long- Посмотреть сообщение
    Почему бы не сделать сразу действительно качественный мод, и не парится и не бояться что вдруг где то он щас крашнется.
    Сейчас ты примерно говоришь - "Да ладно, работает и похер".
    Что? -_- Я наоборот говорю, что нужно изначально писать качественный код и тогда не будет никаких проблем. Но чтоб начать писать такой код, нужно понимать тонкости языка, а не просто заучить 100 разных вариантов оптимизации, суя их где ни попадя.

    И "качественный код" - это не тогда, когда на бенчмарке ты добился максимально хорошего результата, а когда твой код просто не создаёт никаких проблем при игре. Просто потому что такова специфика онлайн игр. От того, что ты ускоришь свой код на 0.10 миллисекунды, не изменится ничего, ибо пинг нивелирует все твои потуги. Да и даже если бы речь шла о сингловой игре, эти доли миллисекунды никак бы не отразились ни на чём, ибо игрок просто не заметит изменений. Изменения заметны лишь при появлении проблем и последующем их исправлении. Такова психология человека, увы.
    Так же стоит понимать, что процессорное время в миллион раз дороже памяти. Именно поэтому при оптимизации и написании кода алгоритмам нужно уделять в разы больше внимания.


    Цитата Сообщение от Long- Посмотреть сообщение
    Я лично привык работать на "все и сразу", если делать, то делать качественно и по максимуму, именно такой и нужно подавать пример.
    Это как раз очень плохо, если ты не видишь чувства меры. Оптимизировать можно бесконечно долго. А чтоб таким не заниматься, нужно банально знать возможности той платформы, под которую ты пишешь код, не перегружая эту самую платформу. Большего от тебя и не нужно, ибо, как я уже выше говорил, от того, что раньше твой код обрабатывался за 10 миллисекунд, а теперь за 9.50, не изменится ровным счётом ничего, если до этого (когда код обрабатывался за 10 миллисекунд) пользователь не испытывал никакого дискомфорта.

    Да и если ты однажды начнёшь профессионально заниматься программированием, работая в какой-нибудь компании, то там ты с таким подходом станешь лишь головной болью у руководства, ибо вместо результата ты будешь лишь затягивать сроки :)




    Цитата Сообщение от Long- Посмотреть сообщение
    Блин, кто-то я помню писал совсем иные слова :)
    Спор с Nexius'om был, когда ты говорил то, что я писал выше в этом посте, если найду пруфы, кину сюда, щас просто не помню тему, по моему про пикапы нажатия на ALT или нет.
    Как буд то совсем другой человек пишет.
    Ты просто не можешь понять разницу между оптимизацией и пессимизацией.
    Возможно, дело в моей подаче информации. Давай попробую процитировать другого человека, который крайне правильные мысли излагает
    Цитата Сообщение от dimonml
    ...
    А вообще есть правило программирования - не пессимизировать, то есть не пытаться оптимизировать то, что оптимизировать не нужно и выигрыш от оптимизации чего будет минимален (а какой будет выигрыш на начальном этапе разработки, как правило, сказать нельзя).

    На хостинге есть ресурсы - процессор и память. Можно оптимизовать как по одному параметру, так и по другому. Но оптимизировать сразу оба как правило очень сложно (если возможно). Вот ты смущаешься размеру amx, а тебе это мешает? Это проблема? Стоит вообще смотреть в эту сторону?

    Тут и в англоязычном разделе многие предлагают использовать битовые поля и прочие методики сокращения использования памяти. Да, безусловно, памяти от этого используется меньше. А на сколько возрастает использование процессора? Кто ни будь задавался таким вопросом и пытался замерить? Например, архитектура х86 очень старая и у процессора есть оп-коды, которые позволяют прочитать из памяти любой байт (по любому адресу). В более новых архитектурах, например в Itanium, такой возможности нет и из памяти можно прочитать только машинное слово (по скольку архитектура 64 разрядная, то 8 байт) и только по адресу кратному величине этого машинного слова. С одной стороны непонятно, за чем такое ограничение, но если приглядеться, то станет видно, что даже x86 процессоры, если у них просят прочитать байт из памяти по адресу, не кратному машинному слову (4ым или 8и байтам), то делает это намного медленней чем если адрес кратен. И по этой причине современные компиляторы во время оптимизации стараются выравнивать элементы структур по величине машинного слова. По этой причине в С++ sizeof(bool) == 4. Мы тратим на хранение 1 бита информации 4 байта, но мы с этим битом работаем быстро.

    Все кричат, что нужно использовать строки по 128 слов, вместо 256, но в англоязычном разделе показали, что скорость возрастает не более чем на 5%. Стоит ли такое оптимизировать, учитывая что во многих случаях это усложнит код?

    К чему я это все написал. Прежде чем что либо оптимизировать хорошо бы подумать, для чего это делается и что вы будете ухудшать взамен. Если вы оптимизируете использование памяти, то очень часто будет ухудшаться скорость работы, также как и на оборот. И в обоих случаях будет усложняться код - нужно будет его больше тестировать и больше времени потратить на нахождение ошибок (ведь известно, у одного программиста, количество ошибок в основном пропорционально объему кода, грубо говоря, количество строк).


    Цитата Сообщение от Long- Посмотреть сообщение
    Можно весь мод уместить спокойно в 16384 байт, я просто не представляю куда больше и на что его можно потратить?Признаки быдлокодерства
    И так-же стэк показывает признаки халатности скриптера, и его уровень быдлокодерства.
    Сделать систему отображения логов разработки в игре? Или любую другую систему, в которой нужно отобразить много текста?
    Помещать текст в сегмент данных, объявляя глобальный массив/используя static? Так этим ты только больше памяти потратишь, ибо вместо стэка, который и так уже занимает свой кусок сегмента данных, ты выделишь новый, подчас такого же размера, как и стэк, ещё больше раздувая сегмент данных.
    Вообще, не в обиду, но очень похоже, что ты даже не особо понимаешь принципы работы памяти, а просто повёлся на модную в русскоязычном сегменте сообщества SA-MP фишку оптимизировать всё и вся, видимо, показывая этим свой невероятный скилл, под час даже не понимая, что на самом деле ты делаешь только хуже. Стандартные 16384 байт - это не эталон размера стэка, а просто, фактически, рандомное число, которое разработчик выбрал с расчётом на то, что на многие нужды такого количества памяти хватит. Нет ничего плохого в том, что ты увеличишь стэк. Наоборот, вместо выделения дополнительных 4к ячеек (ну или сколько там понадобится выделить, если вдруг ты не сможешь уместить данные в стэке), ты просто выделишь ещё 100-200 ячеек, дабы все данные уместились в стэк.



    Цитата Сообщение от Long- Посмотреть сообщение
    Как я говорил выше, лучше сделать сразу качественно, и не бояться что , ой вдруг щас не хватит памяти и крашнет.
    Что бы не бояться, достаточно понимать как работает твой код и осознанно его писать. Тогда, не поверишь, в некоторых случаях можно даже пренебрегать оптимизацией, от слова совсем.

    Цитата Сообщение от Long- Посмотреть сообщение
    Неужели самому не приятно, когда все аккуратно, не боясь, ставить на любой даже нубохостинг, и не бояться.
    Ну, если нравится делать двойную работу - пожалуйста, но учить этому новичков как минимум глупо :).
    Довольно забавно читать кучу упрёков в свою сторону от человека, который просто не так понимает мой посыл, вкладывая в мои слова свой смысл :)


    Цитата Сообщение от Long- Посмотреть сообщение
    А мы говорим про кривые алгоритмы? Можно просто написать неоптимизированный алгоритм где будет полный быдлокод, но алгоритм будет работать, а-ля тот же SendMess.
    SendMess - это как раз пример кривого алгоритма :)
    А вот, например, пикапы домов на кнопку, реализованные через обычный цикл без каких-либо дополнительных условий - это уже неоптимизированный алгоритм, который сам по себе не создаст никаких проблем (ибо для сервера 1000 итераций с IsPlayerInRangeOfPoint - семечки), но вместе с другими неоптимизированными алгоритмами может создать проблем. Хотя, при этом, долгое время в SA-MP как-то уживались с такими циклами и никто не умирал, что лишь подтверждает мои слова о бессмысленности пессимизации :)

    Цитата Сообщение от Long- Посмотреть сообщение
    Следовательно встречный вопрос, зачем тогда использовать sscanf, dc_cmd, mysql, давайте как в старые времена будет сидеть на файлах, использовать стандартный командный процессор, ведь было все норм никто не жаловался? :)
    Потому что это удобнее?
    sscanf позволяет разобрать кучу данных, используя всего одну строку
    командные процессоры несут в себе кучу другого дополнительного функционала, помимо скорости обработки
    mysql позволяет более удобно совершать выборку данных

    Их, в первую очередь, используют потому что они упрощают определённые действия. А уже потом думают о скорости работы (в иностранном сегменте, например, во всю используют Y_CMD, который далеко не самый быстрый, но функциональный. И ничего, сервера не падают от перегрузки).
    Да и сейчас ты как раз приводишь примеры оптимизации, а не пессимизации. Вот если ты сейчас сядешь и начнёшь искать способ ускорить и без того быстрый Pawn.CMD, добившись, в итоге, выигрыша в 0.00001мс, то это уже будет чистой воды пессимизация. А вот если ты выбираешь Pawn.CMD вместо обычного командного процессора, то ты, во-первых, ускоряешь обработку команд (не прилагая к этому никаких усилий, кроме, собственно, подключения плагина), а, во-вторых, улучшаешь синтаксис команд, не привязывая их к одному коллбэку.


    Цитата Сообщение от Long- Посмотреть сообщение
    Тогда опять же встречный вопрос , зачем тогда бегать по темам и давать всем советы как оптимизировать код , и как сделать лучше, если это вообще тебе не нужно ? :)
    Опять же, не путай пессимизацию и оптимизацию. Я не против оптимизации.

    Цитата Сообщение от Long- Посмотреть сообщение
    Даже упомяну тот случай где ты спорили Я, Ты, Ziggi, Snegovik1337(вроде), помнишь? По поводу какой код быстрее работает.
    Если ты заглянешь в ту тему и почитаешь мои сообщения, то в одном из них увидишь ответ на твой вопрос. А именно то, что я сугубо ради забавы проводил тесты, параллельно пытаясь показать на примере, что далеко не всегда "меньше кода" = "лучше".

    Цитата Сообщение от Long- Посмотреть сообщение
    И делать такие выводы, ты видимо не был еще в более сложных ЯП, по типу JS, BP, C(++, #, ), где каждый байт лучше оптимизировать . и занимается "пессимизацией", и отучать всех других - глупо :(
    Громкое заявление, но, увы, даже тут ты не прав.
    Важность оптимизации определяется не языком, на котором ты пишешь код, а, как я уже говорил выше, платформой, для которой ты этот код пишешь.
    Так же, как я уже выше говорил, если ты однажды начнёшь работать по специальности "программист", твои оптимизаторские замашки никому не нужны будут, ибо в 99% случаев тебе нужно будет написать код в кротчайшие сроки и так, чтоб он просто работал без проблем. А если ты будешь сидеть над каждой строчкой по 10 минут, тебя быстро спишут со счетов, ибо из-за тебя компания будет терять прибыль, так как сроки будут увеличиваться.




    Напоследок хочется подкинуть тебе простую задачку.
    Представим, что у нас есть SA-MP сервер и есть код, который сервер оптимально обрабатывает за 5 миллисекунд. То бишь, обрабатывая код эти 5 миллисекунд, игроки не испытывают никакого дискомфорта и спокойно себе играют. Но тут ты видишь, что если половину кода заменить на #emit, а другую половину переписать в виде плагина, то можно выиграть 2.5 миллисекунды. Вопрос: стоит ли оно того?
    Судя по твоей логике, естественно стоит. Только вот если отбросить понтокодерские замашки и обратится к здравому смыслу, можно понять, что игроки не почувствуют разницы. А раз игроки не почувствуют разницы (хотелось бы напомнить, что мод ты пишешь, в первую очередь, для них), то и смысла в твоих действиях чуть меньше, чем нисколько



    И да, не нужно только опять писать что-то в стиле: "настрочил тонну текста, лень читать". Я лишь ответил на все вопросы, что ты задавал :) Так что если хочется меньше текста, то и самому стоит писать более конкретно)
    Связаться со мной в VK можно через личные сообщения этой группы
    Заказы не принимаю

    Широко известно, что идеи стоят 0.8333 цента каждая (исходя из рыночной цены 10 центов за дюжину).
    Великих идей полно, на них нет спроса.
    Воплощение идеи в законченную игру требует долгой работы,
    таланта, терпения и креативности, не говоря уж о затратах денег, времени и ресурсов.
    Предложить идею просто, воплотить – вот в чём проблема

    Steve Pavlina

 

 
Страница 2 из 2 ПерваяПервая 1 2

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •