> Ну если тебе только в булочную, типа старта vim и тетриса, а
> в другой город совсем никак и никогда - ок, тогда даа ещё типа всяких компиляторов, например.
впрочем, всякие невменяемости типа файрфоксов не собираю, конечно.
> Сдох ваш бобик. На серверах - давно.
рад за сервера. только меня это не волнует — ну, разве ты мне толстый красивый сервер подаришь.
> ибо объем памяти на типовом десктопнике и даже многих ноутах уж
> давно перевалил за 4Гб.
а на многих — нет.
> Те же криптографы
дорогой. ты так говоришь, как будто у тебя на x86 криптография 140% CPU сжирает. у меня вон cjd, где сплошное шифрование, даже процента не может. в 32-х битах.
> Как по мне все это х32 - страдание фигней.
а как по мне, так страдание фигнёй — 64-битные указатели там, где они нафиг не упёрлись (то есть, в подавляющем большинстве «десктопного» софта).
> Вообще, нагревать себя на плюсы 64 битов,
> коли они уж есть - дурь несусветная.
ну да, неиспользованная половина указателя — это плюс. без сомнения.
> еще например memory-mapped файлы
(напряг память) упс. что-то за последние пять лет не могу вспомнить случая, когда мне надо было замапить десятигиговый файл.
>> а на указатель всё равно будь любезен потратить 64 бита.
> За счет относительной адресации - ряд сущностей вполне можно адресовать относительным смещением
это всё здорово, ты это компилятору расскажи. пусть он «адресует относительно», когда в структурах указатели лежат, угу. я хочу это видеть: как поможет относительная адресация в таком случае?
> А когда программа не может адресовать всю доступную
> память по человечески - это defective by design, извините.
ещё раз: подавляющему большинству «десктопного» софта это нафиг не надо. а оверхэд на размер указателя пихают всем.
> Ну как бы соотношение efforts/results должно быть разумное. Основной объем памяти в
> системах обычно занят отнюдь не указателями, так что экономия плюс-минус пары
> метров на всю систему
угу-угу. у тебя там что, одно ядро и init запущены, что ли?
> На самом деле, 64-битные программы кушают не сильно больше 32-битных.
ровно до тех пор, пока там не появляются разлапистые структуры со сложными связями.
> А я вот тут активно пересобираю линевый кернель и осознал все плюсы
> хренадцати гигз.
а мне и моих хватает. шесть минут — и всё собрано.
> Более-менее разлапистый конфиг
но зачем? один раз настроил под своё железо — и всё.
> Хз, знаю энное количество игроделов и на моей памяти никто из них
> не высказывал никаких особых претензий к х86-64.
я про игроделов, а не про клепателей говна на юнитях и анрылах. впрочем, таких действительно очень мало осталось.
> Да, да, расскажи нам как любители mmaped файлов относятся к идее обрубить
> виртуальное пространство. Слушаю с нетерпением.
расскажи мне, зачем на «десктопе» ворочать такие файлы?
>> классно тебе. и раздувания структур данных тоже не заметишь.
> Ну да, как-то так. Просто потому что указатели явно не занимают существенный
> процент памяти системы.
как вылезешь из контроллеров и попадёшь в мир, где динамические структуры и сборки мусора — твоё мнение может сильно поменяться.
> А mmaped файлы там тоже обрублены до 2^32, да?
и что? тебе что, видео процессить? так это уже не «десктоп», пардон.
> Ну или как адресовать больше при 32-битных указателях?
как и раньше — обрабатывая файл чанками. правда, не ясно, зачем.
> Регистры мусорятся, но еще, знаешь ли, старые результаты вычислений иногда перестают быть
> нужными. И тогда регистры можно реюзать без сохранения и перезагрузки, просто
> снеся содержимое которое больше нигде использоваться не будет.
таки да. прикинь, для x86 тоже так можно.
> И чем регистров
> больше - тем чаще можно будет все обтяпать в этих регистрах,
> не занимаясь их перегрузкой.
интересно было бы посмотреть на статистику: сколько в среднем регистров на выражение идёт в том же gcc и как часто он их сохраняет на x86. эмпирически я подозреваю, что совсем нечасто. но плугин делать лень.
алсо, я не против того, чтобы регистров было больше. я против того, чтобы вместе с этим и указатели раздувались, например. да, я активно использую динамические структуры. да, мне лишние байты — это cache misses.
>> ага. умные современные компиляторы тоже не занимаются таким: они просто выделяют стековый
>> фрэйм и запихивают туда данные при помощи mov.
> А это кто как.
сказано для си на стеке — значит, на стеке. оптимизировать сие можно только если функции в одном модуле, приватные и межпроцедурная оптимизация включена. иначе обломинго.
возможно, ещё LTO может помочь — но опять же: не для библиотек, которые в основном собраны без LTO-секций. да и делать это при сборке, теряя 100500 времени и выигрывая аж десяток миллисекунд на исполнении…
> Да и при программировании вручную как-то удобнее просто реализовать алгоритм чем мудoxaться
> с техническими перегрузками по причине "регистров не хватило".
а ещё лучше пнуть компилятор, пусть он этим занимается. всё равно есть нехилая вероятность, что компилятор лучше код соптимизирует для современных мультикоровых кисков.
> кучей регистров - от х86 будет тошнить и это не лечится.
да разве ж я говорю, что у x86 хорошая система команд? я ещё лет 15 назад говорил, что x86 надо закопать и охрану поставить, чтобы назад лопатой загонять, если попытается выбраться.
> Ну, блин, приди и покажи этим лохам как надо процы делать.
армовцы уже, собственно. хотя и они со своими тумбочками в опасном направлении идут.
