Вот не соглашусь. При большом количестве игроков начиналось знатное лагалово, и затыком становился именно клиент, причём проблема была не в отрисовке графики, а в обработке данных процессором и натягивании совы (Unreal engine) на глобус. Такое ощущение, что вместо нормальных коллекций и алгоритмов разработчики использовали простые алгоритмы с неоптимальной асимптотикой. И да, были утечки памяти: после нескольких часов работы клиента он начинал тормозить даже на простых сценах. Например, сервер частенько забывал отправить пакет, что объект пропал и его нужно удалить. В результате при многочасовой прокачки на споте в памяти клиента висели тысячи невидимых объектов, которые он был вынужден обрабатывать.
Я просто раньше занимался написанием бота-радара под Lineage II, видел всю дичь. Ещё я проводил стресс-нагрузку клиента: смотрел, что будет, если постоянно спавнить и удалять объекты. Нормальному клиенту было бы пофигу, но в родном клиенте начиналась утечка памяти.
Проблема курицы и яйца. Нет смысла писать 64-битный софт, если им никто не пользуется, потому что все сидят на 32-битных система. Нет смысла ставить 64-битную систему, потому что нет софта.
Только когда возникла реальная необходимость в 64-битных системах (≥4 гигов памяти), тогда и пошли подвижки.
Так ценность вполне себе может быть выражена стоимостью. Есть как прямые материальные затраты, так и косвенные. Например, общество ценит детей, и потому требует от родителей определённых действий по воспитанию и содержанию. Родители вынуждены либо сами тратить время (которое вполне может выражаться в денежном эквиваленте), либо нанимать человека.
Мне кажется, вы не очень знакомы с архитектурой современных процессоров. Да, есть архитектуры, где данные можно читать только 64-битными блокам. Но это не наш случай: и в x86-64, и aarch64 процессоры умеют эффективно работать и с 32-битными, и с 64-битными данными. Чуть менее эффективно — с 8- и 16-битными (поэтому лучше не использовать типы с размером меньше int без веских аргументов).
А вот что эти процессоры умеют не очень хорошо, так это в невыровненный доступ. Некоторые процессоры обрабатывают такие данные медленнее, некоторые же поднимают лапки и бросают исключение. И чтобы такого не было, данные надо выравнивать: значения типа int32 должны иметь адрес, кратный 4 (и на 32-битных, и на 64-битных архитектурах) а значения типа int64 — адрес, кратный 8.
То есть массив из 10 int32 будет занимать 40 байт, но никак не 80. А вот массив из 10 экземпляров структуры, состоящей из int32 и int64, будет занимать 160 байт.
А ещё не только указатели, но и выравнивание структур до 8 байт, выравнивание стека (любой аргумент в стеке занимает минимум 8 байт).
Я помню, что в старые времена, когда у подавляющего большинства людей было не более 2 гигабайт памяти и когда 64-битные процессоры только входили в массовое обращение, утверждалось, что 64-битный код потребляет где-то на 25% больше памяти, чем 32-битный. И потому люди даже на 64-битных архитектурах ставили 32-битные системы.
Понятное дело, что 25% — грубая оценка. Те же графические ресурсы занимают одинаково. Но другой оценки у меня нет.
Ключевое слово "захотел". Часто бывает, что процесс закоммитил с десяток гигов, а реально пользуется только парой гигов, остальное — нулевые страницы. С другой стороны, в Windows нет overcommit, поэтому да, commit size — хороший способ изменения памяти.
За последние 50 лет средняя площадь дома в США выросла почти в 2 раза, а количество проживающих в них снизилось на ~15%. Также вовлечение женщины в экономику подняло средний доход семьи, что потянуло вверх нормы потребления, включая стоимость жилья.
Но если сейчас жахнет мировой кризис и ипотечные ставки взлетят до 15% и выше, тогда спрос на ипотеку резко упадёт, и жильё снова станет доступным.
Вот только повышение эффективности труда сейчас приводит не к сокращению рабочего дня, как ожидал Маркс, а к увеличению нормы выработки.
Прогресс и автоматизация разгружает человека от типовой работы, зато увеличивает количество нетиповой. А это очень сильно утомляет человека. Оптимальный рабочий паттерн — немного нетиповой работы, разбавленной большим количеством типовой, за время которой мозг отдыхает.
Именно так.
Вот не соглашусь. При большом количестве игроков начиналось знатное лагалово, и затыком становился именно клиент, причём проблема была не в отрисовке графики, а в обработке данных процессором и натягивании совы (Unreal engine) на глобус. Такое ощущение, что вместо нормальных коллекций и алгоритмов разработчики использовали простые алгоритмы с неоптимальной асимптотикой. И да, были утечки памяти: после нескольких часов работы клиента он начинал тормозить даже на простых сценах. Например, сервер частенько забывал отправить пакет, что объект пропал и его нужно удалить. В результате при многочасовой прокачки на споте в памяти клиента висели тысячи невидимых объектов, которые он был вынужден обрабатывать.
Я просто раньше занимался написанием бота-радара под Lineage II, видел всю дичь. Ещё я проводил стресс-нагрузку клиента: смотрел, что будет, если постоянно спавнить и удалять объекты. Нормальному клиенту было бы пофигу, но в родном клиенте начиналась утечка памяти.
Ещё как может. Почитайте про PAE: 32-битные Windows Server 2003 и 2008 поддерживают до 64 ГБ физической памяти.
Проще — не значит лучше. Хочется пользоваться одним и тем же инструментом на разных системах, а не двумя разными.
Проблема курицы и яйца. Нет смысла писать 64-битный софт, если им никто не пользуется, потому что все сидят на 32-битных система. Нет смысла ставить 64-битную систему, потому что нет софта.
Только когда возникла реальная необходимость в 64-битных системах (≥4 гигов памяти), тогда и пошли подвижки.
Проект far2l передаёт привет.
Так ценность вполне себе может быть выражена стоимостью. Есть как прямые материальные затраты, так и косвенные. Например, общество ценит детей, и потому требует от родителей определённых действий по воспитанию и содержанию. Родители вынуждены либо сами тратить время (которое вполне может выражаться в денежном эквиваленте), либо нанимать человека.
, требует от государства расходов на об
Можете пояснить, что вы имеете в виду? Серверная часть, клиент, какого года?
Это называется "экономия на спичках".
Вы как-то слишком упрощаете современные процессоры. О какой именно шине идёт речь?
И разработчики процессоров не дураки: доступ к 32-битным данным в них такой же эффективный, как и к 64-битным.
Медленный же доступ к 8- и 16-битным данным, но это связано с сохранением верхней части регистра.
Мне кажется, вы не очень знакомы с архитектурой современных процессоров. Да, есть архитектуры, где данные можно читать только 64-битными блокам. Но это не наш случай: и в x86-64, и aarch64 процессоры умеют эффективно работать и с 32-битными, и с 64-битными данными. Чуть менее эффективно — с 8- и 16-битными (поэтому лучше не использовать типы с размером меньше int без веских аргументов).
А вот что эти процессоры умеют не очень хорошо, так это в невыровненный доступ. Некоторые процессоры обрабатывают такие данные медленнее, некоторые же поднимают лапки и бросают исключение. И чтобы такого не было, данные надо выравнивать: значения типа int32 должны иметь адрес, кратный 4 (и на 32-битных, и на 64-битных архитектурах) а значения типа int64 — адрес, кратный 8.
То есть массив из 10 int32 будет занимать 40 байт, но никак не 80. А вот массив из 10 экземпляров структуры, состоящей из int32 и int64, будет занимать 160 байт.
А ещё не только указатели, но и выравнивание структур до 8 байт, выравнивание стека (любой аргумент в стеке занимает минимум 8 байт).
Я помню, что в старые времена, когда у подавляющего большинства людей было не более 2 гигабайт памяти и когда 64-битные процессоры только входили в массовое обращение, утверждалось, что 64-битный код потребляет где-то на 25% больше памяти, чем 32-битный. И потому люди даже на 64-битных архитектурах ставили 32-битные системы.
Понятное дело, что 25% — грубая оценка. Те же графические ресурсы занимают одинаково. Но другой оценки у меня нет.
То есть размер указателей, по-вашему, одинаков и в 32-битной, и в 64-битной среде?
Ключевое слово "захотел". Часто бывает, что процесс закоммитил с десяток гигов, а реально пользуется только парой гигов, остальное — нулевые страницы. С другой стороны, в Windows нет overcommit, поэтому да, commit size — хороший способ изменения памяти.
Да, поэтому надо смотреть на "Private Bytes".
Итоговая сумма всегда будет выше. Просто с каждого последующего тугрика придётся отдавать бóльшую долю.
Видимо, поэтому нематериальные плюшки начинают иметь значение.
За последние 50 лет средняя площадь дома в США выросла почти в 2 раза, а количество проживающих в них снизилось на ~15%. Также вовлечение женщины в экономику подняло средний доход семьи, что потянуло вверх нормы потребления, включая стоимость жилья.
Но если сейчас жахнет мировой кризис и ипотечные ставки взлетят до 15% и выше, тогда спрос на ипотеку резко упадёт, и жильё снова станет доступным.
Вот именно. Поэтому я считаю абсолютно нормальным, если человек посидит в ТикТоке в рабочее время.
Вот только повышение эффективности труда сейчас приводит не к сокращению рабочего дня, как ожидал Маркс, а к увеличению нормы выработки.
Прогресс и автоматизация разгружает человека от типовой работы, зато увеличивает количество нетиповой. А это очень сильно утомляет человека. Оптимальный рабочий паттерн — немного нетиповой работы, разбавленной большим количеством типовой, за время которой мозг отдыхает.
Кстати, да. Захотел я поставить утилитку — pandoc, так она с собой весь хаскель потащила. В итоге люди вот так извращаются:
https://aur.archlinux.org/packages/pandoc-bin