> Разогнали шины и множители, что даёт эффект на больших порциях данных (aka bloatware).

То-есть если я бэкап жму - это bloatware, оказывается? Да и фоточки разрешением 640х480 не втыкают.

> А реальные «железные» скорости не разогнались особо, потому что там физика.

Сильнее всего в те поры физика упиралась в нормы техпроцессов и результирующее оттуда потребление и тепловыделение. По мере уменьшения элементов схем тепловыделение уменьшалось, довольно круто. Пропорционально 3...4 степени.

Кроме того - не умели делать компактное, массовое и эффективное охлаждение на подобные мощности (в серверах лучше, но звук!!!). А еще - преобразователи питания и управление питанием, DVFS и проч.

С тех пор как минимум...
- Многофазные схемы питания с регулируемым вольтажом. Которые не пасуют перед отгрузкой 1V 100A в проц. Ну вот такой вот трамвайчик.
- Полимерные lowESR кондеры, которые и не вскипают от нагрева своим же ESR.
- DVFS, power & clock gating - позволили схемам быть быстрым в пике но не жрать как трамвай на холостых режимах.
- Частоты стали выше в разы. Глобально, везде.
- Вентиляторами научились управлять с регулировкой оборотов.
- Сами технологии охлаждения здорово прокачали (на десктопах, в лаптопах, а теперь и в мобильных устройствах).
- Шины - усовершенствовали и довольно радикально сменили парадигмы местами. Это была эпоха начала конца параллельных шин.
- Оператива сейчас напрямую к процу, а не чипсету. Минус латенси гейтовки CPU FSB <-> RAM чипсетом.

> Если сильно разгонять, начнёшь радио слушать чипом.

В железном ящике? :) А так слив по transmission line и антеннам засчитан. Да, это пришлось узнать не только RF engineer'ам, но и цифровикам c энного момента. Как раз поэтому.

Как ты думаешь, почему в IDE стало 80 проводов? :) Посотри на кабель SATA, особенно 6Gbps. Это не просто кусок провода. А дорожки на платах следуют хитрым паттернам и идут парами. Не просто так. Они все стали низковольтными, дифференциальными, более последовательными и менее синхронными в отличие от наивных первобытных шин сделанных "в лоб".

А так у цифры фронты крутые - даже в "низкоскоростной" схеме уровня ардуины по этому поводу можно выкусить. Спроси у Зенкова какой спектр у прямоугольника с его фронтами.

> Интела обеспечить всем коммунизм^W по 10 ГГц в каждый дом?

Таки интел лоханулся именно по линии частот и тепловыделения. Загнать кремний на 10ГГц как таковой можно. Но не миллиардом транзисторов, в этом случае он умрет по перегреву.

Вести 10ГГц по плате так себе идея. Реально по FR4 разводят до примерно 5. Кто не верит - смотрит домашние роутеры. Хотя в спутникаовых штуках и 10 вроде делают, но выглядит специфично.

Собственно опытом RFщиков пользуются. Когда надо, излучает. Когда не надо - не излучает. Правда теперь цифровики реально мыслят как СВЧшники наполовину. Даже не только из-за мегагерцев, но и из-за наносекундных фронтов, которые разлетаются независимо от периодичности. Если кто не понял - возможны странные методы синтеза сигнала, когда периодики с энным периодом как таковой может и не быть. Какой период у wideband сигналов?

> Как ты думаешь, почему оперативную память делают по «морально устаревшим» техпроцессам,
> и почему внутренняя скорость чипов памяти не растёт?

А потому что смысла нет. Если сделать DRAM меньше по размеру элемента, конденсаторы DRAM начнут жутко утекать, вместо счастья случится EPIC FAIL. Этот эффект очень сильно долбит на мелких техпроцессах. И там где потребление важно, борьбе с этим посвящен целый раздел технологий power management. Потребление ничего не делающего тонкого чипа довольно сильно состоит из утечек. А когда так DRAM делает - она еще и склерозом становится. И чем жарче - тем лучше. Любители тырить пароли из ребутнутого компа - уважают жидкий азот :)

> Нету там внутри никакой «более приличной частоты».

Да все там есть. Хотя самые высокие частоты синтезируют прямо в чипах, чтобы не тащить по плате. Man PLL.

> Только ширина шины больше.

А теперь посмотри в вике что означает "DDR" - одно это делает шину вдвое быстрее на той же частоте. Даже если забить на прочие оптимизации и ощутимый пересмотр "электрики" в сторону дружественности высоким скоростям.

> И накладные расходы на её обслуживание, ха-ха-ха. Старую память контроллеру обойти
> было быстро не только потому, что её было мало. :)

Старая память была тормозной аки трактор, неоптимальной по циклам шины, дурной по физике, тормозной по частотам. И работала с непотребной скоростью. Пеньку с EDO, да даже и с SDR SDRAM - воткнет даже 20-баксовая MIPSовая мыльница с DDR'ом.

> Ты пойми: бесплатный сыр бывает только в мышеловке.

Бывает эволюция технологий. Физику нельзя обмануть. Но можно взять на свою сторону. Там где мы хотим излучать - антенна. Не хотим - делаем transmission line (wave guide). Это просто делается по разному. С явным осмыслением. Да, это уже не просто протяжка дорожек наобум и требует странные скиллы. И не всегда выходит с первого раза даже с крутейшими CAD и симуляторами.

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

> Я уже видел, как по стратегии «займём всю память, она же не
> должна простаивать» постоянно приходится пинать ОС вручную,

Кому приходится - тот пусть этим и страдает. А я в моей ОС не занимаюсь ручным менеджментом память по счастью.

> такое виртуальная память и что такое неймановская архитектура. Слова умные вроде
> знаешь, и даже складывать их в предложения умеешь, а смысла никакого из них не рождается.

Таки понимаю. Это ты не понимаешь что в обозримом будущем возможно вообще вся память в системе станет адресуемой напрямую. Без такого понятия как стораж. NVDIMM тому первый звоночек, но ни разу не последний. Вообще идея пропихать NAND через SATA - изврат. И даже через PCI-E. Он логичнее смотрится замапленым напрямую в адреса, с тонким и быстрым слоем трансляции.

MRAM/FRAM - и подавно. Упомянутых кстати уже промышленно делают. Ramtron так по жизни для индустриалов делает "вечные EEPROM", Ti слегка это лицензировал для своих МК.

> Представь, что ОЗУ — это быстрый кэш, не более того.

Скоро, похоже, сторажи станут "медленным RAM", как мне кажется. Периферия уже стала, она вся сплошь "memory mapped". Это удобно. И сишникам с точки зрения програмизма, и виртуалкам, достаточно очевидный IOMMU позволяет отрезать железку в VM. Делая то же что MMU, но с другой стороны.

> буфер между медленной долговременной памятью (диском) и процессором, то быстро ехать
> уже не получится даже при всём желании.

Плохо стыкуется с примером 300Мпикс картинки и процессинга ее пикселей. Вгрузить ее с диска 1 раз, к тому же сжатую. Декомпресс и любая возня с пикселями будут намного лучше, если попадут в хотя-бы RAM, без насилия над диском вообще. На линейных операциях характерных для обсчета картинок к тому же неплох даже обычный RAM. Хотя GDDR или HBM в GPU лучше. Но их меньше, потому что они дорогие и не апгрейдабельные.

> буферную память максимально свободной, ибо иначе придётся постоянно лезть на диск
> за каждым ссаным байтом, пока ОЗУ будет занято тем, что «может
> пригодиться, ведь его только что недавно закрыли».

И тем не менее, по моему опыту, жирный дисковый буфер - делает работу с ОС намного приятнее. По сути превращая медленный стораж в подобие быстрого рамдиска. Спору нет, если все забить приложениями - эта иллюзия отвалится. Поэтому забивать память под завязку приложениями все же не стоит.

...но если картинка весила допустим 5 гигз, в системе было 16, то у меня еще 11 гигз на все такое прочее. А обсчитать картинку как просто массив в оперативе явно быстрее чем таскать ее расжатую версию из свопа с диска и чего там еще. Вот отлить несколько гигз на диск - это не быстро по хоть каким стандартам. И поэтому фотожоп с 300Мпикс картинке на первом пне - не упадет, но скорость его работы - заманает в край. В отличие от скорости работы любого редактора на машине с 16 гигз.

> лучше подождать дополнительных 100 мс при каждом запуске приложения, а не
> постоянно доставать всё нужное из свопа.

У меня нет свопа. Как максимум у меня есть zram, типа-своп в сжатом рамдиске. Если оперативы хронически не хватило - холодные данные можно попробовать закомпрессить, в надежде что вот так ее все же хватит. Если и так не хватит - и нафиг. Камасутра с 5-м фотошопом на пентиуме и 300 мпикс картинкой - не ко мне.

> Бджд, для высокой производительности программ надо всего лишь писать производительный
> код на максимально близком к железу уровне, вот и всё.

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

А так то да, дрова в досе и даже 95 писали на асме. Было круто и быстро. Но работало только на x86. А нтя таки с дровами на си уже была. Поэтому и была неповоротливой, зато таки портированной на кучу архитектур. Этот тренд и в остальных системах продолжился.

> А не превращать всё в «интерпретатор языка высокого уровня».

Как бы интерпретаторы никогда не были быстрыми. Еще со времен бэйсика.

> Почему-то у хорошей сисясто-ассемблерной программы обычно нет проблем
> с производительностью даже на старом железе и скудной памяти, а у модно-прогрессивных
> аппликух постоянно нехватка ресурсов, «надо докупить ещё, память нынче стоит копейки».

И все же, даже если ты запустишь чисто сишный вариант допустим современного крипто на чем-то 32-битном а потом на сравнимом 64-битном, разница будет довольно убедительной. Так же с мультимедийным добром и прочей тяжелой математикой. А где еще производительность собственно нужна? Ну наверное не в туповэйтинге юзерского ввода.

> Внутренние скорости работы чипов и прочего железа — гугл ит, плиз, энд рид ит.

Хотите об этом поговорить? :) Я как бы в курсе ПСП шин.

И так для понимания...
- ПСП шины памяти на K6-2 (даже покруче первого пентиума) около 600Мб/сек была.
- ПСП DDR3 у моего десктопа около 20 Гб/сек.
- ПСП GPU GDDR5 под 180Гб/сек.

Это более-менее линейный доступ. Первые 2 измерены мемтестами, последнее opencl'ными бенчами похожими по смыслу. И как угодно но при прочих равных линейный доступ к оперативе, типовой для обсчета картинки, воткнет той штуке эпохи пентиумов в 33 раза на типовых паттернах характерных для обсчета картинок. Но еще лучше будет если это влезет в GPU и туда придет opencl фильтр, который мало того что массово SIMDшный как черти что, так еще и ПСП эвон какой. И он таки реально в разы быстрее основного cpu сжует это. Поэтому и GPU, собственно - хорошо с графикой работает.

> Нет, товарищ комсорг, не так всё было. Никто ничего не оптимизировал,

Посмотри на эволюцию крипто и не тупи. Симметричные алгоритмы и хэширование.

Salsa, chacha, sha-3, да даже AES... их лучше на 64-бит проце крутить. Больше за 1 такт обсчитывается. И вот так было везде где скорость счета кого-то колыхала. Будь то графические фильтры или мультимедийные кодеки или что там еще.

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

Да ну ерунда, не все же - вебмакаки. Есть и алгоритмисты. И они таки тоже на 32 бита забили.

А как я это узнал? Блин попробовал найти алгоритмов под 32 битный микроконтроллер. И обчертыхался. Таки да, 64-бит математика там есть, и даже работает, но таки из 32-бит регистров она получается медленнее. И код жирнее, чем если нативный юнит с которым оперировали был бы 32 бита. А на 64 бит проце оно конечно же офигенно раскладывается.