>> а у меня вот всё вовсе не в диск упирается. disk i/o
>> там какие-то доли процента от общего времени.
> У тебя или очень крутые диски, или хилый проц.

старенький, да, корадвадуба на 3 ггц. я очень консервативен, и технику меняю с трудом. плюс — куча кода с шаблонной магией: основное время у компилятора уходит на раскрутку всяких шаблонов. нет, это не цпп. ;-)

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

ты меня не понял. различие между «десктопом» и «девелоперской станцией» не в том, какое там железо, а в том, какие задачи на технике крутит хозяин.

>> «фэйсбук», «ютуб», «твиттер», «джастинбибер»,
> Да, а ты попробуй в хроме каком-нибудь все это открыть.

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

> Ретроградство/тормозизм - вот это не в меру. Экономить 4 байта, нае... себя
> на возможность адресации всей памяти в системе - маразм.

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

кстати, если у разработчиков отобрать «меготехнику с кучей гигов рам», то софт станет сильно лучше. а то я несколько офигеваю, вспоминая, с какой скоростью работал «the bat» на древнем 800-м пне, и как сейчас когтемыл по десять секунд иногда открывает письмо. при том что свободной RAM в системе — почти два гигабайта, так что я не знаю, чем он там занимается. потому что i/o тоже не особо дёргает при этом.

>> это *много*. очень много.
> Ну вот кому это много - тот пусть и др@чится с работой
> с mmaped файлами кусочками и прочее.

зачем ты кормишь компилятор портянками на 20 гигабайт? ;-)

> Ну а вот я могу захотеть поработать с какой-нибудь железкой на USB
> и подрываться компилить драйверы "на соседний чип usb-uart" - мне как-то
> не с руки.

дел-то… два пинка и две минуты, тьфу. при этом один раз. а собираются бесполезные драйвера каждый. неееет, вас таки надо пересаживать назад на 16 бит. а лучше на 8.

> Да, Кэп, я занимаюсь оптимизациями лишь когда вижу в этом практический смысл.

то есть, никогда почти. «а чего, пусть лохи технику помощнее покупают». знаю-знаю, жава.

понимаешь, привычка класть на оптимизацию проявляется сама по себе. в итоге техника всё мощнее, а софт всё жирней и медленней. при этом никаких мегауберфич, которые бы оправдывали тормоза, он не приобретает. do not want.

> Пардон, на компил ядра время тратит машина

ну, если у тебя основное занятие — ядра собирать, тогда да. а мне, например, скучно наблюдать за сборкой, я в это время свой код попилить могу. зачем мне собирать уберядро с биотуалетом, если нужные модули я могу дособрать и позже, когда понадобятся?

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

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

так ядро пожалуется, что видит грушу, а скушать не может. и какую именно.

> Мало ли какая железка померла/заменена/заапгрейжена/... - мне
> чего, ядра пересобирать каждый раз? Я тебе что, гентушник?

ну да, у тебя же ядро по часу собирается. а у меня — пять минут. с нуля. поэтому ты панически боишься пересобрать ядро, если что-то изменилось, а я — нет.

> Не, я просто занимаюсь оптимизацией по ресурсам когда вижу в этом смысл.

вот и питонисты то же самое говорят. один-в-один. и чего ты их так не любишь-то? братья же практически.

>> вижу весьма редко,
> Да ты наверное код в асмовом представлении не сильно часто читаешь.

да, не каждый день. тем не менее, читаю. по необходимости, увы.

>> или линкер, как происходит у меня.
> LTO в фазе линковки и происходит...

об том я и говорю — что-то собрал не так. хотя, вроде бы, все опции задавал правильно.

впрочем, тут бы найти время (и желание, это важнее ;-), чтобы хоть поддержку динамического рантайма в gdc впилить… учитывая, что в последний раз я в потроха gcc лазил ещё во времена третьей версии, и что там происходит сейчас — представляю только в весьма общих чертах.

> Если уж всяко непортабельно - на асме по крайней мере получается максимально
> забористый и полностью предсказуемый (покомандно!) результат.

а если помочь компилятору интринсиками — то он будет в состоянии сгенерировать асм-код с использованием симда. «непортабельно» это потому, что «gcc-измы», видите ли.

> предмет простой - сказали эти команды, значит эти.

причём повторять это надо много раз, и радостно отлаживать кучу почти одинакового кода. ну нафиг.

> Просто потому что либы и так были 32-битные, а основное время
> оно проводит не в окружении а в своем коде как раз.

32-битные программы на 64-битной системе таки работают медленней, чем на чистой 32-битной. не так, чтобы сильно заметно, но. так и различие в бенче не ломающее.

> Использовались стандартные флаги от автора либы из его makefile. Дописал. Прикол -
> скорость ... просела. И в 32 и в 64 битной версии.

что ты сделал со своим компилятором, что он такой сумасшедший-то? O_O

ради интереса: а что говорит -Q --help=target в обоих вариантах? нет, сюда не надо, просто сам посмотри. любопытно же.

> Кэп, а это ведь не удивительно. Судя по всему - у автора
> система тоже 64-битная и автор

…нифига не оптимизировал код для 32-х бит на том же уровне, что и для 64-х бит? ;-)