>> а у меня вот всё вовсе не в диск упирается. 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-х бит? ;-)
