> ну я же и говорю: или огромные страницы, или огромные таблицы страниц. Да вообще!!! А боингу для взлета надо 2 пилота + всяких там стюардесс. Еще толпа техников для обслуживания, несколько спецмашин и здоровенный ангар для хранения. А еще аэродром и персонал на нем. Вот ведь чертов оверхед. То ли дело деревенская телега - стоит в сарае, управляется 1 человеком, лошадь еду под ногами находит. Оверхеда минимум. Правда, почему-то из москвы в владивосток дольше едет, хотя на посадке час вроде сэкономили.
О чем это я? О том что если памяти много - ну да, придется потратиться на ее обслуживание. А в среднем по больнице добавление памяти в систему ... только улучшает ее свойства. Например, cache hit вместо обращения к тормозному накопителю - куда как улучшает отзывчивость системы и производительность дисковых операций.
Вообще, если задолбали тормоза, можно:
- Поставить SSD для системы.
- Поставить максимум оперативки на который на жаль денег или который технически возможен.
- Выключить на#$% своп и забыть про эмуляцию оперативки диском как страшный сон.
И, кстати, например линковка линевого ядра с механического диска может работать с вполне "SSDшной" скоростью. Если оперативы много - RAM-диски они быстрые, заразы. А чем больше кэшей, тем больше оно RAM-диск и меньше - механика.
> таблицы страниц тоже. а ещё не вредно вспомнить, что в кэш радостно
> лезут и прикладные софтины. и всем надо-надо-надо!
Тем не менее, на практике нарваться на сколь-нибудь ощутимые penalty - надо сильно постараться. Наверное есть какие-то краевые случаи где это заметно. Но в большинстве типовых задач добавление в систему кучи оперативки подвержено принципу "кашу маслом не испортишь". А хотя-бы чтобы своп навсегда выключить. Один дерг механического диска по времени займет на несколько порядков больше чем дополнительный лукап в оперативе. Тем более что 1 лукап в добавочной таблице в RAM при результате в 4К-блок в любом случае обеспечит неплохой "КПД".
> с тем, что там попытались немного починить систему команд (приделали инвалиду
> деревянную ногу — хотя не было у инвалида руки)
Ноги у инвалида тоже не было, как видим. Вообще, интел должен помереть жестокой смертью за то что система команд из 70-х годов прошлого века живет до сих пор. На момент разработки этого хлама оно такое было потому что каждый транзюк экономили. Но при миллиарде транзисторов на кристалле это уже просто маразм имени совместимости с древним гуано.
> бенчи вообще часто «иного мнения», потому что живут в своём параллельном мире.
Как ты понимаешь, я интересуюсь только их вариантами которые имеют какое-то отношение к моим сценариям использования и, соответственно, коррелируют с тем что я увижу. Могу сказать что я точно НЕ увижу: cache miss в TLB я совершенно точно на глаз никогда и нигде не замечу. Поэтому то что их может стать несколько больше - мне до фонаря! Зато cache hit в дисковый буфер сииииииильно улучшает работу системы. В заметном мне виде. Особенно с механическими дисками. И один cache hit в дисковый буфер - переплюнет добрый месяц работы с cache miss в TLB по выигрышу времени.
Знаешь песенку про мельника? Который истратил шиллинг, заработал грош? Вот это про TLB vs большая память ;).
> то ли дело стройный красивый x86_64 — ну совсем ни разу не костыли!
Костыли и полумеры, но - лучше чем то что было до этого. Стало хотя-бы отдаленно смахивать на более-менее приличные процессоры.
> тем, что вызывает библиотечные функции, которые ничего не делают, то это
> беда. но нужна ли такая программа?
В конечном итоге если программа не занимается каким-то хардкорным математическим счетом - она вызывает библиотечные функции. Это так странно? А даже если и занимается - тот же (аудио,видео)плеер, например - делает немало вызовов в библиотеки всех мастей. В том числе и для того чтобы прочесть, декодировать, а потом сбагрить декодированное на экран и/или в звуковуху. Еще бывают программы которые вообще ничего не делают, но sleep(100500) в чрезмерной оптимизации как-то и не нуждается...
>> могут получить параметры и отдать результат через регистры.
> эффективно убрав эти регистры из списка свободно используемых.
Это примерно как рекламировать ампутацию ног, с аргументом "не будут ботинки натирать". А у x86 даже и убрать нельзя - изначально нету.
> а если вдруг из функции другую (или эту же, хихикс) функцию понадобилось вызвать… ой,
> что это? push/pop? а-я-яй…
Так я не говорю что push и pop совсем не будет. Просто их будет меньше.
> да, кстати. куча регистров — это костыль. ты не знал? так знай:
> куча регистров — это просто такой дополнительный кэш памяти, только ним
> зачем-то приходится вручную управлять. тьфу, гадость.
Это не просто память, это "умная память" - с ними можно математические операции производить, на то и РОНы. Если уж на то пошло, тогда архитектуры с 1 или несколькими аккумуляторами, типа x86 - вообще гэ неимоверное, еще более костыльное.
В идеале, конечно, вся память должна обладать такими свойствами, но память работающая со скоростями проца получается только как SRAM. А это минимум 6 транзисторов на ячейку, даже без всякой математики. А если еще и математику с всеми ячейками захотеть... А у DRAM - 1 транзистор на ячейку. Ну вот и делают компромиссно.
Кстати, видал подобное: у одного из процов с которым я имел дело, регистры мапились в накристальный RAM и даже имели адреса в памяти. Очень кстати удобно: например полностью переключить контекст - 1 регистр-указатель переписать, и вот уже другой адрес = другое содержимое регистров. Можно сделать убер-эффективный аналог полного (или частичного) пуш-попа, щелкая 1 указателем вместо всей кипы регистров. Но, правда, накристальная память очень лимитирована по размеру, а возможность напрямую адресовать регистры проца позволила поиметь ... море лулзов. Прикольно вкатить новое значение регистров через buffer overrun, правда? :).
> у тебя функции в вакууме живут. если функция impure, то она вызывает
> другие функции, и всё равно вынуждена эти свои параметры и временные
> значения сначала совать в память, а потом из памяти доставать.
Можно и через регистры обмениваться. И пересылка между регистрами - просто и быстро, обращения в память намного дольше. Ибо, знаешь ли, не хватит на всех ячеек суперскоростной памяти, между которыми еще и математику можно делать. А обычный DRAM и даже кэши - тормознее. И без математики между ячейками.
> а если pure — то нормальный компилятор её просто заинлайнит и не
> будет ерундой заниматься.
Тем не менее, когда есть куча регистров, у компилятора больше возможностей для маневра. Сам по себе push + pop == NOP. Суммарный эффект равен нулю. Чисто технический костыль по поводу "не хватило регистров". Чем больше регистров - тем реже такая ситуация наступает. В предельном случае, если регистров бесконечно много, их хватает всегда :).
> а ты посмотри на мой текст выше.
Посмотрел. Не отменяет того что чем больше регистров - тем чаще в них влазит без тасования лишний раз.
> — уйди, мальчик, не мешай ликовать! ура-а-а-а!
Как-то так :)). Хотя-бы по поводу того что мега-у...ще стало просто у...щем. Улучшение, как ни крути :).
