Здравствуйте, Aquilaware, Вы писали:
A>Когда-то мне понадобилось выделить 80 Мб непрерывной памяти — но на 32 битных системах это часто не срабатывало из-за фрагментации памяти.
Какой памяти?
A>иногда даже относительно скромные 80 Мб одним блоком выделить не получается, потому что в адресном пространстве иногда не бывает достаточно продолжительной свободной "дырки".
Чтобы создать такую ситуацию, нужно очень долго и целенаправленно забивать адресное пространство разным мусором. Для типичного приложения такая ситуация нереальна.
Здравствуйте, Философ, Вы писали:
Ф>Чтобы жрать больше памяти? Размер указателя то X2...
"Вот прямо сразу" это ощутимо только на больших (миллионы элементов) списках. Сам по себе рост грамотно организованных кода/данных не настолько значителен.
Основная претензия к 32-разрядному коду в 64-разрядных системах в том, что все общение с системой идет через трансляцию. Приложение загружает 32-разрядные библиотеки-переходники, вызывает оттуда системные функции, те преобразуют параметры, вызывают 64-разрядные библиотеки, затем преобразуют результаты. Когда в запросе участвуют отдельные слова или небольшие структуры, накладные расходы невелики, но при обмене большими массивами данных приходится каждый раз выделять память из кучи, затем освобождать.
Но основной жор, как известно, создают просто неграмотно сделанные приложения. Предел в 2 Гб — единственное, что не дает им возможности жрать больше.
Здравствуйте, eustin, Вы писали:
E>Можно ли в 2023 перейти целиком на 64 бита (b2c)? Сейчас для некоторых продуктов тащится 32 Битный exe на всякий случай.
Как видите, 64-битный режим работы имеет такие плюсы и минусы:
+ 64-битная система может работать со всем объемом оперативной памяти;
+ некоторые операции на 64-битном процессоре выполняются существенно быстрее;
— 64-битные указатели требуют больше памяти. Это увеличивает объем занимаемой приложениями оперативной памяти.
Там ещё идёт сравнение.
Результаты исследования вполне ожидаемы. Из-за использования режима совместимости 64-битная система при работе с обычными 32-битным программами показала чуть меньшую производительность.
Данное сравнение производительности также показало, что реальной пользы от 4 гигабайт оперативной памяти в том наборе приложений нет. Тут важно заметить, что на самом деле в тяжелых приложениях вроде графических редакторов, систем автоматизированного проектирования (CAD) и прочих объем оперативной памяти играет ключевую роль. Там от дополнительных гигабайт оперативной памяти реальная польза действительно есть.
Лично я же думаю так.
1. Смысл в 32-ух битных приложениях для повышенной совместимости включая 32-ух и 64-ёх битную архитектуру процессора и операционной системы.
2. Смысл в 64-ёх битных приложениях для использования 64-ёх битных инструкций и 64-ёх битной адресации при том, что архитектура процессора и операционная система тоже 64-ёх битные.
1. Каждый вариант имеет преимущества и недостатки.
2. Использование сразу двух вариантов имеет только преимущества без недостатков.
Большинство пользователей скорее всего сидят на 64-ёх битных процессорах и операционных системах. Потери 32-ух битных пользователей скорее всего будут небольшими, но они будут. В принципе, конечно, пора уже отказываться от 32-ух битов. Но с другой стороны 32-ух битные приложения более совместимы.
А ещё моду на отбрасывание 32-ух бит задала Apple, но тут нужно понимать, что они вообще всё отбрасывают. Отбрасывают свои же старые интеловские макбуки и переходят на свои процессоры. Отбрасывают стандартные графические библиотеки и пилят своё.
Плюют на крупнейшего производителя игрового движка вроде Unreal Engine от Epic Games. Вообще всех гнобят и старые айфоны уж извините это старые айфоны, покупайте новые или гуляйте без учётной записи.
В общем я тоже разрешаю отказаться от 32-ух битной архитектуры в пользу одной лишь 64-битной. Но если есть время, то можно было бы сделать две версии для каждого семейства операционок.
Cмысла в 32-ух битах лично я не вижу и сам не использую, за исключением того, если только у разработчика есть только такая версия. Хотя для Wine 32-ух битное приложение было бы лучше, но это из-за изначальных настроек и скорости развития самого Wine. Да и здесь больше уже вопрос создания нативных версий для других семейств операционных систем отличных от Windows.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, Философ, Вы писали:
Ф>>Чтобы жрать больше памяти? Размер указателя то X2... ЕМ>"Вот прямо сразу" это ощутимо только на больших (миллионы элементов) списках. Сам по себе рост грамотно организованных кода/данных не настолько значителен. ЕМ>.. ЕМ>Но основной жор, как известно, создают просто неграмотно сделанные приложения. Предел в 2 Гб — единственное, что не дает им возможности жрать больше.
Зачем миллионы? Достаточно одного объекта в куче, у которого пара булевых полей, пара интовых, а ещё несколького геттеров, несколько сеттеров и один vtable. Сам посчитай оверхед. Собственно, чем больше объектов тем меньше оверхед. Но даже если их очень много, в этом примере оверхед значительный. Я могу на примере формочки с кнопочкой такое продемонстрировать, с цифирками.
ЕМ>Основная претензия к 32-разрядному коду в 64-разрядных системах в том, что все общение с системой идет через трансляцию.
гм... любопытно. А где об этом можно почитать? Почему при нативных вызовах такого не происходит?
Всё сказанное выше — личное мнение, если не указано обратное.
V>- 64-битные указатели требуют больше памяти. Это увеличивает объем занимаемой приложениями оперативной памяти.
А значит меньше программы влезет в кэш процессора
Но эмуляция арифметических 64-бит операций в 32-битной программе будет, конечно, медленней чем нативные 64-бит
Здравствуйте, TailWind, Вы писали:
TW>А значит меньше программы влезет в кэш процессора
Думаете, среди нас есть такие, кому лично довелось испытать сколько-нибудь заметное падение быстродействия собственного софта по этой причине, и при этом в софте не было явных косяков?
Здравствуйте, Философ, Вы писали:
Ф>Зачем миллионы? Достаточно одного объекта в куче, у которого пара булевых полей, пара интовых, а ещё несколького геттеров, несколько сеттеров и один vtable. Сам посчитай оверхед.
У одного такого объекта оверхед будет десяток-другой байтов, это критично?
Ф>Собственно, чем больше объектов тем меньше оверхед.
Почему меньше? Он постоянный на каждый объект.
Ф>Но даже если их очень много, в этом примере оверхед значительный.
Вот он и становится заметным, только когда таких объектов очень много. Впрочем, на фоне современных браузеров почти любой оверхед уже выглядит незначительным. У них тоже начиналось с "ну ладно, пусть страница занимает на 100 килобайт больше, зато навигация будет быстрее". А теперь — "вроде бы эти 20 мегабайт тут лишние, да и хрен с ними, щас прикрутим еще какую-нибудь свистоперделку".
ЕМ>>все общение с системой идет через трансляцию.
Ф>где об этом можно почитать?
Если про винду, то гуглите по WOW64. Собственно, то же самое происходит и при запуске 16-разрядного кода в 32-разрядной винде.
Ф>Почему при нативных вызовах такого не происходит?
Основной обрабатывающий код реализован в родной разрядности. Дублировать его полностью нецелесообразно, хотя многие мелкие функции полностью отрабатывают в 32-разрядных библиотеках. А когда функция требует обращения к ядру, желательно унифицировать интерфейс, чтобы ядру не приходилось разбираться с разрядностью указателей. Поэтому вся трансляция делается в библиотеках пользовательского режима (DLL в винде), а в ядро уже идут только стандартные, "родные" запросы.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Почему меньше? Он постоянный на каждый объект.
А если 0 объектов, а vtable в памяти!?
Ф>>Но даже если их очень много, в этом примере оверхед значительный.
ЕМ>Вот он и становится заметным, только когда таких объектов очень много. Впрочем, на фоне современных браузеров почти любой оверхед уже выглядит незначительным. У них тоже начиналось с "ну ладно, пусть страница занимает на 100 килобайт больше, зато навигация будет быстрее". А теперь — "вроде бы эти 20 мегабайт тут лишние, да и хрен с ними, щас прикрутим еще какую-нибудь свистоперделку".
ЕМ>>>все общение с системой идет через трансляцию. Ф>>где об этом можно почитать? ЕМ>Если про винду, то гуглите по WOW64. Собственно, то же самое происходит и при запуске 16-разрядного кода в 32-разрядной винде.
Ты говорил про большие объёмы данных и выделение памяти в куче для трансляции. Я не могу этого в документации найти, как минимум тут и вот тут нету. Про трансляцию через выделение в куче я ничего не могу найти. Про то, что стековые аргументы расширяются до 64 бит и так ясно. Про то, что ядерные вызовы дорогими получаются тоже понятно, но они без этого как бы не дешёвые.
Всё сказанное выше — личное мнение, если не указано обратное.
ЕМ>Думаете, среди нас есть такие, кому лично довелось испытать сколько-нибудь заметное падение быстродействия собственного софта по этой причине, и при этом в софте не было явных косяков?
Думаю, что вы опять задаёте странные вопросы, когда не согласны с тезисом
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Думаете, среди нас есть такие, кому лично довелось испытать сколько-нибудь заметное падение быстродействия собственного софта по этой причине, и при этом в софте не было явных косяков?
Лично мне просто не приходило в голову собирать под 64 бита то, для чего 32 вполне хватало (это для моих поделок). А на работе всё по большей части упиралось либо в сеть, либо в диск, либо в системные вызовы, либо в SQLite. Ну а потому, когда на работе работаешь обычно не до бенчмарков — данные подбираются так, чтобы их для задачи хватило.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>мне просто не приходило в голову собирать под 64 бита то, для чего 32 вполне хватало
Я бы тоже не собирал, но некоторые системные операции (например, установка/удаление драйверов в винде) могут выполняться только из приложений родной разрядности. Ну и многие юзеры искренне полагают, что 32-разрядное приложение в 64-разрядной системе — это что-то кривое, наподобие 16-разрядного в 32-разрядной, и просят "родное". Так что все релизы давно собираются под x86/x86, а сейчас еще и под arm64.
Здравствуйте, Философ, Вы писали:
Ф>А если 0 объектов, а vtable в памяти!?
Мы сейчас реальные, ощутимые затраты оцениваем, или занимаемся мелочным крохоборством?
Ф>Ты говорил про большие объёмы данных и выделение памяти в куче для трансляции.
Я сейчас с ходу не вспомню, где это используется — есть у винды какие-то функции, где могут передаваться/приниматься длинные таблицы, размеры данных в которых зависят от разрядности. А большинство преобразований, конечно же, идет через стек.
Здравствуйте, TailWind, Вы писали:
TW>Минутка психотерапии:
Вы твердо уверены, что из нас двоих психотерапия нужна именно мне?
TW>Сложно сказать: я делал тест производительности с компилятором 32 и 64 бит и на моих задачах не было существенной разницы?
Конечно, делал, и не раз.
Но дискуссия, напомню, не о том, имеют ли смысл 32-разрядные приложения вообще, а о том, стоит ли индивидуальному разработчику (это во многом определяет уровень сложности и применимости задач) полностью переходить на 64-разрядную архитектуру. Раз Вы в рамках этой дискуссии утверждаете "меньше программы влезет в кэш процессора", значит, считаете этот фактор важным и существенным именно в этом аспекте. Вот мне и стало интересно, кому из нас действительно имеет смысл помнить о размере кэша процессора и соотносить его с размером кода/данных, ибо все более важные причины нехватки быстродействия уже устранены.
У них тоже начиналось с "ну ладно, пусть страница занимает на 100 килобайт больше, зато навигация будет быстрее". А теперь — "вроде бы эти 20 мегабайт тут лишние, да и хрен с ними, щас прикрутим еще какую-нибудь свистоперделку". 