>> Разогнали шины и множители, что даёт эффект на больших порциях данных (aka bloatware).
> То-есть если я бэкап жму - это bloatware, оказывается? Да и фоточки
> разрешением 640х480 не втыкают.Не в кассу. Будьте добры высказывать ваши тезисы по существу, тов. комсорг.
>> А реальные «железные» скорости не разогнались особо, потому что там физика.
> Сильнее всего в те поры физика упиралась в нормы техпроцессов и результирующее
> оттуда потребление и тепловыделение. По мере уменьшения элементов схем тепловыделение
> уменьшалось, довольно круто. Пропорционально 3...4 степени.
Техпроцессы считают по производственному оборудованию, ёпт, а не по транзисторам. :)
Тепловыделение делают настолько высоким, сколько можно остудить за приемлемую стоимость без стремительной деградации кристалла. А можно сделать любым, да. В том числе таким, что печка i9 будет работать при комнатной температуре вообще без радиатора. Но будет немножко не так быстро. И в этом месте любому здравомыслящему человеку должно стать понятно, что прогрессивные современные процессоры уже с завода разогнаны. Самую малость, ага, чуть-чуть. И ещё это трезвомыслящим людям повод для размышлений о том, насколько велики на самом деле внутри архитектурные изменения в сравнении с Pentium Pro. Если мысленно отрезать, эксперимента ради, весь кэш, то останется из внутренних отделов… ой, какое всё знакомое! Что ж ты делаешь, Интел!
> Кроме того - не умели делать компактное, массовое и эффективное охлаждение на
> подобные мощности (в серверах лучше, но звук!!!). А еще - преобразователи
> питания и управление питанием, DVFS и проч.
С чего ты взял, что не умели? Или речь про теплотрубки? Ну да, на писяках этого когда-то не было.
А схемы питания с каких пор стали рокетсаенсом? Просто не гнали первопни до тепловыделения под 300—500 Вт, как гонят i9. П-ц, натуральный же утюг.
>[оверквотинг удален]
> - DVFS, power & clock gating - позволили схемам быть быстрым в
> пике но не жрать как трамвай на холостых режимах.
> - Частоты стали выше в разы. Глобально, везде.
> - Вентиляторами научились управлять с регулировкой оборотов.
> - Сами технологии охлаждения здорово прокачали (на десктопах, в лаптопах, а теперь
> и в мобильных устройствах).
> - Шины - усовершенствовали и довольно радикально сменили парадигмы местами. Это была
> эпоха начала конца параллельных шин.
> - Оператива сейчас напрямую к процу, а не чипсету. Минус латенси гейтовки
> CPU FSB <-> RAM чипсетом.
Некоторые элементы значительно улучшены, верно, и появилось чуть нового. Но всё остальное, ты уж извини, это не рокетсаенс. И не надо тут людям вешать на уши про управление оборотами вентиляторов, смешно же читать. :)
А шины просто расширили, по сути. Никаких научно-технических прорывов не было.
Касательно ОЗУ — ты хоть сам себе честно ответь на вопрос: CL 2 и CL 20 — это сколько разницы в абсолютной скорости на уровне ячеек, и на уровне шины, и на уровне контроллера? Про эффективность так про эффективность! ;-)
>[оверквотинг удален]
> засчитан. Да, это пришлось узнать не только RF engineer'ам, но и
> цифровикам c энного момента. Как раз поэтому.
> Как ты думаешь, почему в IDE стало 80 проводов? :) Посотри на
> кабель SATA, особенно 6Gbps. Это не просто кусок провода. А дорожки
> на платах следуют хитрым паттернам и идут парами. Не просто так.
> Они все стали низковольтными, дифференциальными, более последовательными и менее синхронными
> в отличие от наивных первобытных шин сделанных "в лоб".
> А так у цифры фронты крутые - даже в "низкоскоростной" схеме уровня
> ардуины по этому поводу можно выкусить. Спроси у Зенкова какой спектр
> у прямоугольника с его фронтами.
Вот и пришлось менять параллельные шины на последовательные. Чтоб на высоких скоростях не слушать сплошное радио всеми внутренними потрохами и внешними устройствами. Радио не буквально, разумеется, а в виде помех и наводок, ибо местами на несколькогигагерцовых частотах мелкие проводники сами начинают излучать. Таки да, внутри железного ящика. :)
>> Интела обеспечить всем коммунизм^W по 10 ГГц в каждый дом?
> Таки интел лоханулся именно по линии частот и тепловыделения. Загнать кремний на
> 10ГГц как таковой можно. Но не миллиардом транзисторов, в этом случае
> он умрет по перегреву.
Загнать-то можно. Ещё в какие годы Межделмаш сделал транзистор, переключающийся на 100+ ГГц. Только с этого нет пользы, ибо на высоких частотах появляются новые факторы из-за новых физических явлений, а не только тепловое излучение.
>> Как ты думаешь, почему оперативную память делают по «морально устаревшим» техпроцессам,
>> и почему внутренняя скорость чипов памяти не растёт?
> А потому что смысла нет. Если сделать DRAM меньше по размеру элемента,
> конденсаторы DRAM начнут жутко утекать, вместо счастья случится EPIC FAIL. Этот
> эффект очень сильно долбит на мелких техпроцессах. И там где потребление
> важно, борьбе с этим посвящен целый раздел технологий power management. Потребление
> ничего не делающего тонкого чипа довольно сильно состоит из утечек. А
> когда так DRAM делает - она еще и склерозом становится. И
> чем жарче - тем лучше. Любители тырить пароли из ребутнутого компа
> - уважают жидкий азот :)
Ну вот, вроде как человек в теме и в курсе всех проблем. А за системду топит. Непостижимо. Заплатили? Скажи хоть сколько. Может и я начну писать за деньги агитпродукт за системду.
>> И накладные расходы на её обслуживание, ха-ха-ха. Старую память контроллеру обойти
>> было быстро не только потому, что её было мало. :)
> Старая память была тормозной аки трактор, неоптимальной по циклам шины, дурной по
> физике, тормозной по частотам. И работала с непотребной скоростью. Пеньку с
> EDO, да даже и с SDR SDRAM - воткнет даже 20-баксовая
> MIPSовая мыльница с DDR'ом.
Ну я не про аж такую старую. Берём 20-летней давности SDRAM типа PC-100, например.
> Таки понимаю. Это ты не понимаешь что в обозримом будущем возможно вообще
> вся память в системе станет адресуемой напрямую. Без такого понятия как
> стораж. NVDIMM тому первый звоночек, но ни разу не последний. Вообще
> идея пропихать NAND через SATA - изврат. И даже через PCI-E.
> Он логичнее смотрится замапленым напрямую в адреса, с тонким и быстрым
> слоем трансляции.
Сомневаюсь в скором наступлении этого светлого будущего. Это неэффективно с точки зрения накладных расходов для большинства применений. То есть сделать-то можно, но мало кому это на самом деле нужно. А кому нужно, те не удовлетворятся ширпотребом.
Жадные производители настолько зажрались, что распаивают на материнках лишние слоты с расшаренными линиями. Зато всё в разноцветных огнях светодидов, разукрашено в цвета китайского дракона и так далее.
> MRAM/FRAM - и подавно. Упомянутых кстати уже промышленно делают. Ramtron так по
> жизни для индустриалов делает "вечные EEPROM", Ti слегка это лицензировал для
> своих МК.
Ну, я думаю, что излишне напоминать, сколько мы читаем о «завтраках» на эту тему. А воз и ныне там. Я уже забил ждать. :)
>> Представь, что ОЗУ — это быстрый кэш, не более того.
> Скоро, похоже, сторажи станут "медленным RAM", как мне кажется. Периферия уже стала,
> она вся сплошь "memory mapped". Это удобно. И сишникам с точки
> зрения програмизма, и виртуалкам, достаточно очевидный IOMMU позволяет отрезать железку
> в VM. Делая то же что MMU, но с другой стороны.
Идея очень хорошая и плодотворная, но не с теми ячейками, которые пихают в SSD.
>> буфер между медленной долговременной памятью (диском) и процессором, то быстро ехать
>> уже не получится даже при всём желании.
> Плохо стыкуется с примером 300Мпикс картинки и процессинга ее пикселей. Вгрузить ее
> с диска 1 раз, к тому же сжатую. Декомпресс и любая
> возня с пикселями будут намного лучше, если попадут в хотя-бы RAM,
> без насилия над диском вообще. На линейных операциях характерных для обсчета
> картинок к тому же неплох даже обычный RAM. Хотя GDDR или
> HBM в GPU лучше. Но их меньше, потому что они дорогие
> и не апгрейдабельные.
В теоретической неймановской модели вся память условно одинакова и равноценна. Почему бы не править только те куски файла, которые надо, через окошко, не дёргая весь файл? Экономия налицо, причём при любых условиях. Ну понятно, что на актуальном железе память на самом деле не одинакова, не однородна, и ещё в ней есть медленные диски, а файло на них ещё и упаковано. :)
>> буферную память максимально свободной, ибо иначе придётся постоянно лезть на диск
>> за каждым ссаным байтом, пока ОЗУ будет занято тем, что «может
>> пригодиться, ведь его только что недавно закрыли».
> И тем не менее, по моему опыту, жирный дисковый буфер - делает
> работу с ОС намного приятнее. По сути превращая медленный стораж в
> подобие быстрого рамдиска. Спору нет, если все забить приложениями - эта
> иллюзия отвалится. Поэтому забивать память под завязку приложениями все же не
> стоит.
Я имел в виду всё-таки ОЗУ.
> ...но если картинка весила допустим 5 гигз, в системе было 16, то
> у меня еще 11 гигз на все такое прочее. А обсчитать
> картинку как просто массив в оперативе явно быстрее чем таскать ее
> расжатую версию из свопа с диска и чего там еще. Вот
> отлить несколько гигз на диск - это не быстро по хоть
> каким стандартам. И поэтому фотожоп с 300Мпикс картинке на первом пне
> - не упадет, но скорость его работы - заманает в край.
> В отличие от скорости работы любого редактора на машине с 16
> гигз.
Не. Не всё так просто. Руконогие эту картинку будут («а чо? память дивошая!») кэшировать и перекэшировать многократно и на каждую отмену сделанных операций и ещё на массу факторов. Поэтому всё равно памяти всегда будет мало. Простое увеличение объёма ОЗУ никак не решает проблему неэффективных алгоритмов и рук, выросших из низа спины.
Возможно, что создателям эффективных графических редакторов и файловых форматов пригодились бы знания разработчиков файловых систем, но эти ребята как-то не пересекаются между собой по роду деятельности.
>> лучше подождать дополнительных 100 мс при каждом запуске приложения, а не
>> постоянно доставать всё нужное из свопа.
> У меня нет свопа. Как максимум у меня есть zram, типа-своп в
> сжатом рамдиске. Если оперативы хронически не хватило - холодные данные можно
> попробовать закомпрессить, в надежде что вот так ее все же хватит.
> Если и так не хватит - и нафиг. Камасутра с 5-м
> фотошопом на пентиуме и 300 мпикс картинкой - не ко мне.
Идея свопа в ОЗУ спорна, но обсуждать её лень.
>> Бджд, для высокой производительности программ надо всего лишь писать производительный
>> код на максимально близком к железу уровне, вот и всё.
> С современным железом это легче сказать чем сделать. Начиная с того что
> реально код не имеет дело с блоками выполнения. Он попадает в
> uCode ROM и тот разваливает его на микрооперации, а что случится
> дальше, а также сколько и каких блоков фактически есть в том
> или ином камне - известно лишь крайне приблизительно. Кроме того -
> при чрезмерном увлечении код получается не портабельным или обладает хреновой производительностью
> на других архитектурах, если там сделано иначе.
Ну это уже вопросы, выходящие даже за те рамки, что мы тут расширяем и углубляем. :)
Пока Си и ассемблеры работают для того железа, которое сейчас у нас есть, можно принять как соглашение, что это железо внутри не изменилось со времён первых x86.
> А так то да, дрова в досе и даже 95 писали на
> асме. Было круто и быстро. Но работало только на x86. А
> нтя таки с дровами на си уже была. Поэтому и была
> неповоротливой, зато таки портированной на кучу архитектур. Этот тренд и в
> остальных системах продолжился.
А нам точно-точно надо, чтоб работало где-то ещё? Кроссплатформенность — это непродуктивная идея, с точки потребителя. Нативный софт всегда работает лучше и быстрее.
> И так для понимания...
> - ПСП шины памяти на K6-2 (даже покруче первого пентиума) около 600Мб/сек
> была.
> - ПСП DDR3 у моего десктопа около 20 Гб/сек.
> - ПСП GPU GDDR5 под 180Гб/сек.
Согласен. А теперь ответь на мой любимый простой вопрос: почему при таком впечатляющем прогрессе новый Ворд тормозит на самом новом железе так же, как тогдашний Ворд на тогдашнем железе.
>> Нет, товарищ комсорг, не так всё было. Никто ничего не оптимизировал,
> Посмотри на эволюцию крипто и не тупи. Симметричные алгоритмы и хэширование.
> Salsa, chacha, sha-3, да даже AES... их лучше на 64-бит проце крутить.
> Больше за 1 такт обсчитывается. И вот так было везде где
> скорость счета кого-то колыхала. Будь то графические фильтры или мультимедийные кодеки
> или что там еще.
Мне до крипто никакого дела, мне есть дело только до браузеров, фотошопов и вордов.
>> ибо оптимизацию ваши товарищи по комсомолу и партии возложили на трудящихся в
>> формате регулярного похода в магазин за новым железом.
> Да ну ерунда, не все же - вебмакаки. Есть и алгоритмисты. И
> они таки тоже на 32 бита забили.
Да ладно, не по сеньке эта шапка. Забили производители железа. Как я уже говорил, фактически ADM64 это та же PAE, только «наоборот». Это не настоящая 64-битная архитектура.
Сорри, я не всё комментирую, а кусочками, нет времени.
