Подробнее
■1»23SI "WE MANAGED TO COMPRESS THIS FULLY POLYGONAL 3D GAME COMPLETE WITH TEXTURES AND AUDIO TO 1 MB SO THAT IT CAN BE RUN ON THIS 20 MHZ MACHINE WITH 128 KB OF RAM."
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор
Еще на тему
Ворд тормозит из-за сотни слоев абстракции, кома-хуема, синхронизаций и еще какой-нибудь хуйни. Каких-то прям тяжких вычислений там не много.
2) Вы предлагаете все писать на ассемблере, вместо компилятора? Еще вручную для кучи разных архитектур и семейств?
В микрооптимизации нет смысла тягаться с компилятором, кроме очень специфичных кейсов. Человек должен выполнять оптимизацию более высокого порядка. Высосанный из пальца пример. Какой-то долбоеб, не знающий алгоритмов и структур данных, в какой-то задаче вместо того, чтобы использовать сортированную кучу, каждый раз ищет максимальный элемент вручную за O(N). Компилятор может быть там что-то наоптимизирует слегка, так, но применение правильной стурктуры данных даст выигрыш существенно больший. Если вы об этом - я полностью согласен.
P.S.
Абстракции это нормально, даже хорошо. Абстракция это как модель, отражает только нужные нам качества чего-то. Их ограниченное количество и все нужные, и это дает настоящий контроль. Если вы управляете автомобилем то вы управляете с помощью руля и педалей. Где-то там работает двигатель по своему циклу карно, что-то подсчитывает и контролирует бортовой компьютер, и где-то датчик в бензобаке ждет своего часа. Вы смотрите на панель и крутите руль, а не контролируете каждое колесо отдельным рычагом, наблюдая работу двигателя через прозрачный кожух в прозрачных цилиндрах и периодически на ходу опускаете щуп в бензобак.
Вам все это не нужно, да это даст больший контроль (на самом деле нет), но это не нужный в данный момент контроль, он только мешает, забирает время, отвлекает, размывает фокус, и котролируя каждое колесо вы меньше внимания сможете потратить на дорогу. Контроль потребуется когда вы услышите странный стук а потом машина заглохнет. Вот тогда вы откроете капот. Или потащите автомобиль в автосервис.
Да мы пользователи. Пользователи процессора, файловой системы, пользователи библиотек и third-party закрытых инструментов, пользователи API внешних сервисов. Мы пользователи черных ящиков. Эти ящики вокруг нас. При разработке мы фокусируемся на том что нам нужно сделать, при этом «пользуясь» кучей инструментов о которых мы знаем крайне мало, только то что нам нужно. И если мы будем заглядывать постоянно к каждой машине под капот, просто чтобы сохранить имитацию (да именно имитацию) контроля — мы не сможем заниматься основной задачей. Мы заглядываем под капот, вскрываем ящик только тогда когда понимаем что проблема именно в этом ящике. Или не вскрываем а меняем. И это нормально. Потому что мы знаем что вот этот черный ящик с надписью «процессор» выполняет то-то и то-то, мы знаем что он делает, нам не нужно знать как, и тогда черный ящик можно спокойно заменить на другой с тем же набором свойств. Сервис на другой. Библиотеку обновить. Это отлично, это дает гибкость и стабильность. И все благодаря абстракциям.
А полноценно контролировали и софт и железо только в 50-е, когда еще и разделения толком не было и софт писался под конретный экземпляр компьютера. Вот там контроль. Вот там постоянно открытый капот. Вот там заточка кода под железо а железа под код. Вот там знание компьютера до каждого резистора и понимание каждого байта и каждого сигнала. Вот только это совсем не эффективно и не надежно, и замена «винчестера» (не говоря уже о «процессоре») могла превратить весь софт в ненужный хлам.
Но тут две вещи.
1) Всему есть предел, баланс между абстрактностью и гибкостью/производительностью/жирностью.
2) Все абстракции текут. Этот термин обозначает, что абстракция не полностью скрывает нижележащее, есть косвенные эффекты, которые нельзя игнорировать в определенных случаях.
Можно делать все как и раньше, только тогда бы индустрия сейчас бы в развитии оставала от современного уровня лет на 10.
Оптимизация это сложный затратный процесс который очень плохо конвертируется в прибыль и для большинства компаний невозможен.
Что характерно, вертолеты колосса поднять не могут, и он так и шагает на своих ножках.
Так и живем, разраб говнософта для пизнеса на фреймфорках((0((0(0(((
Ну и уровень софта немного поменялся. Раньше сайт был просто наобором статей, а теперь в нем триллионы всевозможных интеграций (чтобы можно зайти по своему гугловому акканту, а не регистрироваться на каждом сайте отдельно), финтишлюшек (ajax-подгрузка данных без обновления страницы), всякие пуши/нотификаторы, ну и прочая дребедень, которая давно воспринимается как должное. Все это жрет кило, а иногда и мегабайты. И лишние полсекунды на загрузку страницы обычно стоят того, что можно переключиться в другую вкладку, а потом подсветится "ваш комментарий на джое обосрали. Хотите перекинуться с обидчиком?".
> ajax-подгрузка данных без обновления страницы
И вот тут мы вступаем на скользкую тропу. Где-то надо, где-то не надо, а где-то надо в ограниченном объеме. Пример - хабр. Добавление комментария происходит с помощью ajax, и это правильно. Все, это почти весь ajax-функционал, который там нужен. А потом эти уебки сломали мобильную версию, которая теперь SPA. Вместо того, чтобы просто загрузить страницу, сначала загружается пустая страница, потом подгружаются статьи, потом подгружается информация из аккаунта, если ты вошел, и статьям проставляется количество новых комментариев и появляется кнопка "по подписке". Нажимаешь на нее, и снова идет ебаная подгрузка. Вот скажите, это было настолько охуенно важно, что теперь статьи грузятся без перезагрузки страницы, подтягивая даные ajax'ом?
Мы видим ту же самую петрушку что и на ПК - на консолях по настоящему хорошую оптимизацию могут позволить только гиганты типа рокстар (рдр2 смотрится просто охуенно), эксклюзивы от сони (анч4 в картинке так же великолепен), а остальные предоставляют то или иное мыльцо разной степени паршивости.
Близзард дает хорошую оптимизацию, овервоч хорошо летает даже на калькуляторах. И по большому счету список можно заканчивать, 95% индустрии делает ее условно паршиво. Не потому что им в падлу, а просто это не выгодно и слишком ресурсозатратно. Добавлять еще полгода разработки и ничего за это не заработать это такое себе.
Но говоря об оптимизации - игры оптимизирует и та же Юбисофт (Far Cry 4 выглядит вполне прилично даже на PS3/X360, за AC: BF ничего не скажу, не играл, но past/current gen используют один и тот же движок). А ещё Infinity Ward и Treyarch и многие другие. И один и тот же движок оказывается весьма хорошо масштабируемым. Т.е. проблемы не в "окупаемости", а в тупой рукожопости разработчиков. Те же Naughty Dogs создавая свои игры много чего из инструментов разработки создавали сами с нуля. И они одни из первых в индустрии реализовали хитрожопые костыли, благодаря которым персонаж Анчартеда СНЯЛ с себя костюм прямо в кадре.
Просто у кого-то руки под кривой хуй заточены, да и с тем плохо справляются, а кто-то и из старого железа умудряется выжать ещё пару процентов потенциала.
Вряд ли можно заметить артефакты в игре, в которую никто не играет
> Но игры работали.
у меня так старкрафт второй на 8600gt 256mb ram "работал". Смотреть без слез на геймлей в 15фпс с просадками до 5 сейчас нельзя. А в 2010 играл, альтернатив особо не было.
Что касается вопроса, объяснение с потолка: в консоли обычно идут процессоры от АМД, тогда как в десктопах почти всегда интелы. Дальше, хотя процессоры и обещают "х86", по факту у них разные множества команд, которые совпадают только в том, что описанно в стандарте. Это значит, что все "улучшайзеры" у каждой фирмы свои. Например, SSE4.1 vs SSE4a, или например AVX команда, которая занимает 2 такта на АМДшном проце, и 1 на интеловском. Если игра разрабатывается под амд, то от AVX в таком случае будет выгоднее отказаться, а на интеловском это даст соответствующую просадку относительно решения "делать на avx". Часть инструкций вообще может быть не реализована, тогда будет выполняться программный фоллбек. Как это влияет на производительность можно посмотреть на примере итаниума и х86 кода.
Это примеры с потолка, но примерно объясняют потенциальные причины. Ну и банальные зарезали графон. В сказки что "да на пк тот же графон" я не верю без пруфов, картинка идентичная натуральной это хорошо, но на натуральную тратится больше ресурсов.
8600GT не далеко ускакала от 7600GT из минимальных системных требований для второго старкрафта. При этом стоит помнить, что "минимальные системные требования" это характеристики, при которых игра гарантированно запустится при минимальных графических графических настройках и минимальном поддерживаемом разрешении. При этом даже 30 ФПС никто не гарантирует - кое-как работает и заебись. Что у тебя и получилось.
Второй момент "в консоли идут процессора от АМД" - это касается только PS4/XONE. В предыдущем поколении (PS3/X360/Wii) рулили PowerPC камни, которые вообще RISC.
Третий момент - системные требования для той же Андромеды - для ПКшки требуется Intel Core i5 3570 или AMD FX-6350 (та-да-а-а-а, разработчики ПК версии учитывают особенности АДМшных процессоров и для ПК версии игры^_^) для минималочек и NVIDIA GTX 660 2GB или AMD Radeon 7850 2GB в качестве видюхи. PS4 отсасывает у этой конфигурации со заглотом. Но Андромеда работает на PS4 весьма прилично. Парадокс? Или чудеса оптимизации?
Покажи мне место в моих постах, где я утверждал, что графика на консолях и на ПК идентичны по качеству? Я русским по-белому написал, цитирую, "игры ведут себя сравнительно хорошо на приставках". Это и рядом не валяется с "охуенностью ПК-мастер-рейс".
> Второй момент "в консоли идут процессора от АМД" - это касается только PS4/XONE. В предыдущем поколении (PS3/X360/Wii) рулили PowerPC камни, которые вообще RISC.
Это вряд ли очко в твою пользу, потому что отличия RISC от CISC еще больше, и значит резко растет вероятность всяких программных эмуляций про которые я говорил.
> AMD FX-6350 (та-да-а-а-а, разработчики ПК версии учитывают особенности АДМшных процессоров и для ПК версии игры^_^)
То что они указали её в системных требованиях не означает, что они под нее затачивали. Вариант "эй, джон, глянь там, что у амуды за проц на уровне 3570 и впиши в доку".
верните мне веб 1.0!
А что тогда есть "научились более эффективно использовать новые мощности", как оптимизация? Ну или криво сформулированная фраза, я не понял.
Я на работу брал себе недавно ноут за 11к на авито, просто какой то говеный старый АМД проц на 2ггц, какой то бюджетный ссд и те же 8гб памяти, так вин10 там летает.
> Скоро для запуска Chroma нужен будет комп 16 ядрами и 64 Гб оперативки а он всеравно будет тупить и долго запускаться
Это к товарищам фронтендерам с их модными "всё есть JS". Я возможно кого-то удивлю. но сейчас большинство устанавливаемого софта ставит с собой маленький хром. Дискорд например, или слак, или скайп, и еще 100500 софтин, которые в прямом смысле ставят хром вместе с собой. Причем каждый будет ставить свой собственный, использовать взрослый хром или какую-то общую инсталляцию сделать они не могут.
О том, куда катится современный софт, о том, что оптимизация не окупается, ну и всё такое прочее.
Довольно интересное чтение.
VirtualDOM позволяет расчитать diff между текущим деревом и тем, которое будет создано. Часть операций могут обрабатываться многопоточно (хотя модель многопоточности в js - говно).
Имеем коллоса на глиняных ногах.
такого, что все это в памяти. Перерисовывать всю страницу на охуенно быстром С++ все же медленнее, чем рассчитать дифф в памяти. Ну и вообще идея чистых функций и иммутабельного стейта позволяет очень хорошо все оптимизировать. Настолько, что в браузеры это скоро затащат на нативном уровне (гуглить shadow dom), и тогда будет побыстрее.
А вообще основная проблема всех этих реакт-хуяктов к том, что все эти технологии нихуя не дружат с кэшированием. Десятки лет люди придумывали, как бы нам лишнего не качать. Придумывали, как серверу кэшировать часть HTML странички и отдавать кусочками на 100мс быстрее. Но пришли JSеры и сказали "хуй клали на ваши кэши", сделали собственный рендер, навернули собственных кэшей (которые тоже на ЖС), ну и получилось что получилось. И теперь сервачок кэширует килобайт страницы, в котором написанно только и радуется, что он может переиспользовать один и тот же овтет для всех клиентов. А вот клиенты охуевают, потому что после как бы "скачанной страницы" начинают грузиться мегабайты скриптов, которые призваны ускорить работу. Такие дела.
https://ru.wikipedia.org/wiki/.kkrieger
Вообще, про это можно было бы накатать пост, если этого ещё нету.
И как бонус, приглашение на одну из выставок (это демка).