> Бог его знает, я начинал свою историю в школе с БК 0010 с 32KB RAM, потом постарше появились Intel 286 512KB, и 70MB звучит адово, не смотря на то, что сейчас в домашнем компе 64GB RAM.Если тебе кажется, что тот софт был лучше, я рекомендую найти его и поработать с ним. В смысле, я знаю, что далёкие от программирования люди убеждены в том, что сегодня софт жрёт больше, потому что программисты разучились писать программы, но ты найди тот софт и попробуй им попользоваться. Ты прикинь, там в программу прошивали максимальный размер имени файла, и ежели программа сталкивалась с именем файла больше максимального, то в лучшем случае она отказывалась работать, в худшем она начинала творить какую-нибудь пургу. И это кажется фигнёй, но если мне надо выделить память под имя файла 8.3, то я сделаю sub sp, 13, и у меня на стеке будет место под строку и под терминатор. И тут, не ты обрати внимание: мне не нужна никакая куча, я на стеке выделю, не проблема, мне не нужен сложный код, который будет следить за прочитанными байтами имени файла, и дёргать realloc когда надо. Я даже могу поступить проще (и часто те программисты именно так и поступали), я могу завести глобальный буфер в виде статической переменной и прочитать имя файла туда. Тогда везде, где я буду работать с этой статической переменной, мне адрес этой переменной будет известен ещё до запуска программы (на этапе компоновки выяснится), и мне не надо передавать никаких аргументов в функции, и в результате, байтик там сэкономили, байтик здесь сэкономили, когда везде сэкономили по байтику, то программа потеряла какую бы то ни было гибкость, но зато ей теперь достаточно 32Kb оперативки.
Но сегодня ж, даже сообщения об ошибках вывести не удастся, полагаясь исключительно на статическую память: пользователю подавай локализацию, а это значит, что надо опираясь на значение переменной окружения $LANG выяснить язык/кодировку, из таблички извлечь сообщение на нужном языке, перегнать его в нужную кодировку, и только после этого выводить. Причём вывод-то у нас буферизованный, и тип буферизации тоже динамически определяемый (ты вполне можешь line-буфер в stderr заменить full-буфером или отсутствием буферизации), то мы тут получаем ещё кучу индирекции (и заодно десяток, а то и несколько, стековых фреймов, то есть под стек надо побольше памяти положить), и даже, возможно, выделения памяти в процессе. И там где в DOS'е было что-то в стиле "пару значений, известных в compile-time, положил по регистрам и сделал int 21h", здесь мы получаем целую подпрограмму, которая по сложности сравнима с не самыми простыми программами в DOS'е. Упс.
И дальше хуже: ты хочешь гуя? Ок, надо памяти. Ты хочешь чтобы на гуй натягивались темы без перекомпиляции? Ок, добавим индирекции, и все размеры, цвета и положения элементов интерфейса теперь будут не прошитыми в коде на этапе компиляции, а читаться из файла при запуске и складываться в специальную заморочную структуру данных, оптимизированную под скорость выполнения запросов к ней, а не под занимаемую ею память. А, и да, структуру гуя (в смысле то, что в веб-е называют DOM) тоже придётся делать динамической, а это значит, что дополнительная индирекция, дополнительные указатели, дополнительные стековые фреймы, дополнительные, дополнительные, дополнительные... И тут вдруг выходит, что на фоне всего этого 70Mb -- это очень скромные требования.
Люди не понимают сложности современного софта. Никто не понимает. В смысле вообще на земле нет ни одного человека, кто бы понимал, потому что сегодня самая маленькая программа написанная в соответствии с требованиями современного пользователя будет настолько огромной внутри, что ни один человек в мире не будет представлять себе, что именно там внутри есть. Даже разработчик этой программы. Даже если он провёл десять лет взаперти, пытаясь эту программу сделать максимально лёгкой, и избавлял её от всего, что не является необходимым. То есть, он может и напишет максимально лёгкую программу, но к тому моменту когда он закончит, он забудет 90% того, что он уже написал.
> 1920x1080x24bit с двойной буферизацией - это 8MB оперативки в худшем случае.
В худшем случае это ~64Mb, потому как в этом худшем случае каждый пиксел представляется как четыре четырёх-байтовых флоата (ибо rgbA). И работа с этими флоатами гораздо прельстивее, чем с целочисленными байтами, потому как float операции как минимум не медленнее целочисленных, и при этом с ними можно работать при помощи SSE или аналога, обрабатывая по четыре флоата за раз.
