>> а ещё типа всяких компиляторов, например.
> А вот компилятор при работе с механическим диском (протереть дырку в SSD
> за неделю в мои планы не входит) как-то бурно радуется cache
> hit на больших иерархиях.а у меня вот всё вовсе не в диск упирается. disk i/o там какие-то доли процента от общего времени.
> А линевый кернель как по твоей классификации, например?
а смотря какой. если «универсальный конфиг» — то тоже невменяемый монстр. everything but the kitchen sink, и 90% из этого никогда не понадобится.
> Ну а у меня и десктоп давно перевалил за 4Гб,
извини, но у тебя не «десктоп». у тебя как минимум «девелоперская станция» — это уже совсем другой класс. и дальше — я поскипаю, потому что ты ведёшь речь про «девелоперскую станцию», но называешь её «десктоп». я понимаю, что чётких определений у этих терминов нет, так что ты в своём праве. но мы таким образом никогда не договоримся, потому что про разные вещи говорим как про одну.
> Нынче не так уж мало программ использует те же mmaped-файлы, например.
и очень мало — размерами в кучу гигабайт. «десктоп», эй. «фкантактег», «фэйсбук», «ютуб», «твиттер», «джастинбибер», «фонтриергений», «какиесиськи!»
>> ну да, неиспользованная половина указателя — это плюс. без сомнения.
> Все должно быть в меру.
именно. бессмысленное раздувание указателей — не в меру.
> Тебе - возможно. А с чего ты взял что мир заканчивается на
> тебе и твоих задачах?
потому что даже мой нетипичный «десктоп» в этом не нуждается. более типичный «десктоп» — тем более.
>> поможет относительная адресация в таком случае?
> А никак. Почему ты думаешь что все оптимизации должны работать во всех
> 100% случаев?
ну, это же ты начал речь про относительную адресацию. вот я и пытаюсь понять, к чему ты это сказал: просто так, или с каким умыслом тайным.
>> ровно до тех пор, пока там не появляются разлапистые структуры со сложными
>> связями.
> В большинстве виденных программ на практике разница не превышала 20-30%.
это *много*. очень много.
> Ну я собираю много и часто. И не такие обрубочные конфигурации как
> у тебя, видимо (хотя зависит от того для чего это ядро).
лично у меня — для работы. вот оно, самосборное — прямо сейчас трудится, помогает мне ответ писать.
>> но зачем? один раз настроил под своё железо — и всё.
> Во первых, для меня нормальная практика раскидать результат компила на несколко машин
> - весьма зависит от того что и по какому поводу собиралось.
и они все настолько разные, что уменьшить ядро никак. ага. и отчего я не удивлён, что тебе на ресурсы плевать?
> Во вторых меня не прет идея пересобирать все когда я воткнул в
> usb энный девайс. а для него драйвера не оказалось, etc. Если
> машина в фоне попашет лишние 5 минут - фиг с ним.
> А если жареный петух укусит когда надо прицепить "вот этот девайс"
> и придется 5 минут заниматься тyповэйтингом - это уже булшит.
причём ситуация такая наверняка случается от силы раз в месяцев пять-шесть, за которые ты кучу раз ядра пересобираешь. то есть, снова куча бесполезной работы. почему я опять не удивлён?
слушай, а ты это… может, ты питонистам просто завидуешь, потому что они ещё круче умеют ресурсы разбазаривать?
>> на «десктопе»
>нежатое видео на 30Гб для тестов кодеков
типично «десктопная» задача, угу. каждый день вижу пользователей, которые это делают. регулярно, утром и вечером.
>> интересно было бы посмотреть на статистику: сколько в среднем регистров на выражение
>> идёт в том же gcc и как часто он их сохраняет на x86.
> Ну я так, грубо прикинул, на основе смотрения в ассемблерный коды из
> иды в свое время, х86 программы какие-то наиболее пуш-попистые из того
> что мне попадалось.
с тех пор оптимизаторы научились разным гитикам. я, кстати, push/pop в коде вижу весьма редко, в основном там, где тупой кодогенератор напрямую преобразовывает стековую VM. так такой на любом процессоре одинаково нагенерит.
> Еще LTO может чуть ли не четверть кода в большом проекте у...ть.
или линкер, как происходит у меня. надо бы, конечно, как-нибудь разобраться, что там не так собрано, но лень.
> Так что если кто др... на TLB и прочее - ему должно понравиться :).
указатели из структур оно всё равно не выметет, потому что права не имеет.
> От кода сильно зависит. Почему-то писаный человеками хардкорный MMXно-SSEшный ASM в всяких
> там видеокодеках делает по скорости тот шит который генерит компилер буквально
> в разы.
ну да, мы же гордые, мы же компилятору помочь симдовыми интринсиками не хотим, потому что «непортабельно». асм зато офигеть портабельный в итоге получается.
> бенчи
ну, ты понял, да?
> Внимание, вопрос: почему 64-битная версия LZ4 делает 32-битную в абсолютно всех бенчмарках?
потому что какой-то дятел запускал её в 64-битном окружении?
> единственное отличие в -m32 для сборки 32-битной версии.
хоть бы ради приличия на 32-битной системе проверял. ну, и с -march=native, -mtune=native хотя бы.
> А чего не так с тумбочками? Если это про thumb. Вроде thumb2
> получился очень симпатично - сэкономили прилично битов в потоке команд на
> условном выполнении, не потеряв его а лишь сделав чуть менее гибким
проблема в том, что когда люди начинают уродовать систему команд — они обычно уже не могут остановиться. это помимо того, что дополнительный режим усложняет всё остальное. ты сам можешь найти железо и аппараты, где тумбочки или вообще нельзя было использовать из-за багов, или приходилось делать workaround-ы. один такой аппарат у тебя точно есть.
