N>Скорость и память компиляции — фактор обычно очень мало значимый.
Скорость неважна, если проект маленький. Вот у нас проект — компилируется около 4 часов + регрессионные тесты. Если скорость будет меньше раза, то за ночь не будет билд полностью склеиваться. Это неприятно.
Здравствуйте, netch80, Вы писали:
N>Я заранее соглашусь. Ну пусть проигрывает? И что с того?
А ничего.
N>Скорость и память компиляции — фактор обычно очень мало значимый. Значительно важнее, например, то, что работа по переносу gcc на доселе неизвестную платформу — один человеко-месяц. А как с VC? Под что он умеет компилировать кроме x86? Меня вот сейчас PPC интересует.
Здравствуйте, Константин Б., Вы писали:
КБ>Здравствуйте, netch80, Вы писали:
N>>Я заранее соглашусь. Ну пусть проигрывает? И что с того?
КБ>А ничего.
Ну вот именно. Дали бы MSVC под Linux под основные платформы — я бы посмотрел на него. Сейчас же выбор состоит из GCC всех версий, ICC, Clang и ещё пары полудохлых проектов типа TenDRA.
N>>Скорость и память компиляции — фактор обычно очень мало значимый. Значительно важнее, например, то, что работа по переносу gcc на доселе неизвестную платформу — один человеко-месяц. А как с VC? Под что он умеет компилировать кроме x86? Меня вот сейчас PPC интересует.
КБ>Отличный выбор, мсье :up: :)
Ничуть не отличный. Причина в Cell'ах кластерного разлива, с которыми надо что-то делать. GCC есть, но сравнивать его с самим собой как-то надоело.
The God is real, unless declared integer.
Re[13]: Why Desktop Linux Sucks, And What We Can Do About It
Здравствуйте, Vamp, Вы писали:
S>>Выяснение вот этого "может оказаться, а может и не оказаться" может оказаться дороже, чем потенциальная прибыль с линуксоидов. V>Прелесть в том, что расходов-то ноль. Не надо самому писать драйверы — открыть исходники виндовых, и сами все напишут.
После того, как написали, надо еще тестировать и поддерживать. Опенсорц этим заниматься не будет.
Здравствуйте, netch80, Вы писали: N>А как с VC? Под что он умеет компилировать кроме x86? Меня вот сейчас PPC интересует.
Хм... в xbox360 ppc внутри же. Чем, интересно, под него компилируют?
Re[14]: Why Desktop Linux Sucks, And What We Can Do About It
S>После того, как написали, надо еще тестировать и поддерживать. Опенсорц этим заниматься не будет.
Будет конечно. Мало что ли опенсорсных проектов тестируют и поддерживают? Никто не требует на эти драйвера ставить печать аппрувед бай сони. Вполне можно скромно написать в уголке — Linux OS support provided through third-party drivers. И ссылку дать на.
Да здравствует мыло душистое и веревка пушистая.
Re[15]: Why Desktop Linux Sucks, And What We Can Do About It
Здравствуйте, Vamp, Вы писали:
S>>После того, как написали, надо еще тестировать и поддерживать. Опенсорц этим заниматься не будет. V>Будет конечно. Мало что ли опенсорсных проектов тестируют и поддерживают? Никто не требует на эти драйвера ставить печать аппрувед бай сони. Вполне можно скромно написать в уголке — Linux OS support provided through third-party drivers. И ссылку дать на.
"ссылку на" это круто
но вот какое отношение поддерживаемых/заброшенных ОSS проектов?
и как ты себе представляешь — открыли виндовые дрова, их спортировали на линух, потом вышла новая железка, опять всё сначала? как быстро новые фичи будут перетаскиваться из виндовых дров производителя в левые дрова? и что делать производителю — ждать, когда перетащат и потом "ставить ссылку на"?
да и по поводу "секретных алгоритмов" — в дровах вполне может быть информация о железе (в том числе и будущем), которую по каким-то соображениям производитель не хочет делать общедоступной. с этим-то как быть?
Re[16]: Why Desktop Linux Sucks, And What We Can Do About It
A>"ссылку на" это круто
Вообще-то это очень распространенная практика.
A>но вот какое отношение поддерживаемых/заброшенных ОSS проектов?
Почему это должно кого-то волновать? Если железка популярная, то никто ее драйвера не забросит. Надоест одному — сделает другой.
A>и как ты себе представляешь — открыли виндовые дрова, их спортировали на линух, потом вышла новая железка, опять всё сначала?
Ну да, а чего такого-то?
A>как быстро новые фичи будут перетаскиваться из виндовых дров производителя в левые дрова?
Быстрее, чем ты можешь подумать. Я уж не говорю о том, что я как-то теряюсь, а каких таких мегафичах драйвера для mp3 плеера, в обязанности которого входит ровно одно дело — обновление кататалога музыки на устройстве — ты говоришь.
A>и что делать производителю — ждать, когда перетащат и потом "ставить ссылку на"?
Ссылку можно давать сразу.
A>да и по поводу "секретных алгоритмов" — в дровах вполне может быть информация о железе (в том числе и будущем),
Это например какая там может быть секретная информация о будущем железе в контексте обсуждаемого устройства?
A>с этим-то как быть?
Выключить машину времени. Драйвер под несуществующее железо — это утопия.
Да здравствует мыло душистое и веревка пушистая.
Re[17]: Why Desktop Linux Sucks, And What We Can Do About It
Здравствуйте, Vamp, Вы писали:
A>>но вот какое отношение поддерживаемых/заброшенных ОSS проектов? V>Почему это должно кого-то волновать? Если железка популярная, то никто ее драйвера не забросит. Надоест одному — сделает другой.
это как минимум должно волновать того, кто поставит ссылку на это безобразие. ну типа проверять, а не сдохло ли оно.
A>>как быстро новые фичи будут перетаскиваться из виндовых дров производителя в левые дрова? V>Быстрее, чем ты можешь подумать. Я уж не говорю о том, что я как-то теряюсь, а каких таких мегафичах драйвера для mp3 плеера, в обязанности которого входит ровно одно дело — обновление кататалога музыки на устройстве — ты говоришь.
глянул по ветке вверх — началось с
Интересно а почему ни один дистр не опознает мой сканер на sony sz?
Ну конечно же виновата сони выпускающая кривое железо, которое почему то прекрасно в винде работает
как там mp3 плеер нарисовался, не знаю
A>>и что делать производителю — ждать, когда перетащат и потом "ставить ссылку на"? V>Ссылку можно давать сразу.
о как. то есть драйвер на несуществующее железо — это утопия, а ссылка на нерабочий драйвер — в порядке вещей?
и нафига производителю портить себе карму, давай ссылку заранее, не имея никаких гарантий что оно вообще будет сделано?
A>>да и по поводу "секретных алгоритмов" — в дровах вполне может быть информация о железе (в том числе и будущем), V>Это например какая там может быть секретная информация о будущем железе в контексте обсуждаемого устройства?
хоть ты и подменил контекст, но как минимум — id будущих моделей. по их наличию можно например сделать вывод, что линейка устройств будет развиваться, и заодно узнать, что они уже в разработке (но пока не выпущены)
A>>с этим-то как быть? V>Выключить машину времени. Драйвер под несуществующее железо — это утопия.
несуществующее != пока еще не засвеченное на рынке
Re[18]: Why Desktop Linux Sucks, And What We Can Do About It
A>это как минимум должно волновать того, кто поставит ссылку на это безобразие. ну типа проверять, а не сдохло ли оно.
Ссылок можно сделать много. Ну и можно проверить раз в год, жива ли ссылка. Это не сильно большой напряг. Можно даже автоматизировать.
A>
A>Интересно а почему ни один дистр не опознает мой сканер на sony sz?
A>Ну конечно же виновата сони выпускающая кривое железо, которое почему то прекрасно в винде работает
A>как там mp3 плеер нарисовался, не знаю
Я изначально говорил об mp3 плеере, и отвечал Шароварщик на мое сообщение об mp3 плеере, где четко указана железка. Так что не надо сейчас.
A>о как. то есть драйвер на несуществующее железо — это утопия, а ссылка на нерабочий драйвер — в порядке вещей?
Конечно. Можно вообще много ссылок сделать. Можно позволитьб любому желающему добавить ссылку на свой проект. Можно сослаться на страницу поиска по SF по ключевым словам.
A>и нафига производителю портить себе карму, давай ссылку заранее, не имея никаких гарантий что оно вообще будет сделано?
Можно подождать, когда появится — через месяц примерно после выхода популярной железки. И поставить ссылку потом.
A>хоть ты и подменил контекст, но как минимум — id будущих моделей. по их наличию можно например сделать вывод, что линейка устройств будет развиваться, и заодно узнать, что они уже в разработке (но пока не выпущены)
Зачем в драйвере ID будущих моделей???
И кроме того, ничего в этом секретного нет. Если враг хочет посмотреть ID будущих моделей, по какой-то причине вкоряченных в драйвер, он может это сделать, дизассемблировав исполняемые драйверы под виндоус.
Да здравствует мыло душистое и веревка пушистая.
Re[15]: Why Desktop Linux Sucks, And What We Can Do About It
Здравствуйте, Vamp, Вы писали:
S>>После того, как написали, надо еще тестировать и поддерживать. Опенсорц этим заниматься не будет. V>Будет конечно. Мало что ли опенсорсных проектов тестируют и поддерживают?
Поддерживают — точно мало, плавно переходящее в очень мало.
V>Никто не требует на эти драйвера ставить печать аппрувед бай сони. Вполне можно скромно написать в уголке — Linux OS support provided through third-party drivers. И ссылку дать на.
Практически, по возможности стоит класть в коробку или печатать на ней то, что работает. Иначе с дерьмом смешают, не посмотрев на third party bullshit.
Re[18]: Why Desktop Linux Sucks, And What We Can Do About It
Здравствуйте, Antikrot, Вы писали:
A>глянул по ветке вверх — началось с A>
A>Интересно а почему ни один дистр не опознает мой сканер на sony sz?
A>Ну конечно же виновата сони выпускающая кривое железо, которое почему то прекрасно в винде работает
A>как там mp3 плеер нарисовался, не знаю
Видимо, не хотят связываться с Sony? С ним что ни делай — по-любому забрызгаешься и не отмоешься.
A>>>да и по поводу "секретных алгоритмов" — в дровах вполне может быть информация о железе (в том числе и будущем), V>>Это например какая там может быть секретная информация о будущем железе в контексте обсуждаемого устройства? A>хоть ты и подменил контекст, но как минимум — id будущих моделей. по их наличию можно например сделать вывод, что линейка устройств будет развиваться, и заодно узнать, что они уже в разработке (но пока не выпущены)
Это крайне несерьёзно. Обстановка меняется настолько быстро, что предполагать какие-то конкретные свойства каких-то моделей нереально. Гораздо проще дать диапазон возможных устройств этого класса в принципе и среди них дать общий интерфейс контроля возможностей.
К тому же в большинстве драйверных моделей (и в Windows, насколько мне известно) список поддерживаемых device ID — информация, которая принципиально не может быть засекречена, потому что вынимается из драйвера стандартным образом и передаётся в диспетчер устройств.
A>>>с этим-то как быть? V>>Выключить машину времени. Драйвер под несуществующее железо — это утопия. A>несуществующее != пока еще не засвеченное на рынке
И кто так делает? Большинство, наоборот, за год анонсы в жёлтую прессу даёт, задолго до драйверов.
The God is real, unless declared integer.
Re[16]: Why Desktop Linux Sucks, And What We Can Do About It
Здравствуйте, Antikrot, Вы писали:
A>но вот какое отношение поддерживаемых/заброшенных ОSS проектов?
У тех, которые вышли за рамки "по нажатию на кнопку показывает фотку и время нажатия пишет в mysql'ную базу" — очень хорошее соотношение. Точные цифры надо у свежего мяса спрашивать.
A>и как ты себе представляешь — открыли виндовые дрова, их спортировали на линух, потом вышла новая железка, опять всё сначала? как быстро новые фичи будут перетаскиваться из виндовых дров производителя в левые дрова? и что делать производителю — ждать, когда перетащат и потом "ставить ссылку на"?
Ну вообще-то лучше пусть делает сам.
Наиболее грамотные производители сами отдают дрова, проверенные и вычищенные ими. В области сетевух, например, это Intel. Могут отдавать только спеки — 3Com, Tulip (DEC). В принципе, дрова могут быть сделаны максимально независимыми от ОС, только подложку менять надо (сдохший проект iBCS2 этим занимался, и если бы не убили — и сейчас имели бы результат).
A>да и по поводу "секретных алгоритмов" — в дровах вполне может быть информация о железе (в том числе и будущем), которую по каким-то соображениям производитель не хочет делать общедоступной. с этим-то как быть?
Если подход виндового стиля, драйвер поступает вместе с железякой. Так можно делать и для свободных ОС, примеры есть. С другой стороны, если хочется обеспечить доступность заранее, тут уже давно не до того, чтобы секретить общеизвестное.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, netch80, Вы писали: N>>А как с VC? Под что он умеет компилировать кроме x86? Меня вот сейчас PPC интересует. MC>Хм... в xbox360 ppc внутри же. Чем, интересно, под него компилируют?
Купленным у IBM. (Слухи, так что зуб не дам, самому нужен)
The God is real, unless declared integer.
Re[17]: Why Desktop Linux Sucks, And What We Can Do About It
Здравствуйте, netch80, Вы писали:
A>>и как ты себе представляешь — открыли виндовые дрова, их спортировали на линух, потом вышла новая железка, опять всё сначала? как быстро новые фичи будут перетаскиваться из виндовых дров производителя в левые дрова? и что делать производителю — ждать, когда перетащат и потом "ставить ссылку на"? N>Ну вообще-то лучше пусть делает сам.
конечно лучше — но это уже не "нулевые расходы"
N>Наиболее грамотные производители сами отдают дрова, проверенные и вычищенные ими. В области сетевух, например, это Intel. Могут отдавать только спеки — 3Com, Tulip (DEC).
как думаешь, почему это сделано для сетевух, и не сделано для скажем hiend видюх?
A>>да и по поводу "секретных алгоритмов" — в дровах вполне может быть информация о железе (в том числе и будущем), которую по каким-то соображениям производитель не хочет делать общедоступной. с этим-то как быть? N>Если подход виндового стиля, драйвер поступает вместе с железякой. Так можно делать и для свободных ОС, примеры есть.
совсем недавно была ссылка(на одного из мейнтейнеров, не последний человек в линухе):
You think you want a stable kernel interface, but you really do not, and
you don't even know it. What you want is a stable running driver, and
you get that only if your driver is in the main kernel tree. You also
get lots of other good benefits if your driver is in the main kernel
tree, all of which has made Linux into such a strong, stable, and mature
operating system which is the reason you are using it in the first
place.
видишь какое дело — несовместимость с идеологией...
Здравствуйте, Vamp, Вы писали:
J>>Ну вот, например: J>>Это 2009 год, т.е. вполне современная версия гцц. V>Гм. Интересно. В любом случае, сравнивать надо просто скорость компиляции, а не то, как что и где организованно. Может, эти списки дают нефиговый выигрыш в другом месте. Берем сотню-другую проектов, компилируем и смотрим — кто выходит на круг быстрее.
ну, то, что сложные шаблоны тормозят, вроде как общеизвестно
И тормозить они могут только из-за неоптимальности компилятора, потому что генерация инстанса шаблона не должна занимать больше времени, чем генерация обычного класса с тем же контентом, более того — должна занимать меньше времени, потому что определенные вещи можно подготовить заранее, а потом просто подставить нужные типы.
Просто компиляторы изначально не были заточены под быструю компиляцию шаблонов, ибо те воспринимались как экзотика, и теперь ее ускорить довольно сложно, нужно половину переписать.
Здравствуйте, netch80, Вы писали:
КБ>>>>А что там смотреть? Гцц проигрывает студийному и интеловскому компилятору по скорости и потребляемой памяти. N>Я заранее соглашусь. Ну пусть проигрывает? И что с того? N>Скорость и память компиляции — фактор обычно очень мало значимый. Значительно важнее, например, то, что работа по переносу gcc на доселе неизвестную платформу — один человеко-месяц. А как с VC? Под что он умеет компилировать кроме x86? Меня вот сейчас PPC интересует.
Это ты говоришь про back-end, а тормозит front-end, который ну никак не зависит от количества платформ, поддерживаемых back-end-ом.
На back-end никто и не нападает, вроде.
N>Если мне потребуется сборка быстро и дёшево по памяти в Linux/x86 — я лучше ICC возьму. MS VC мне в этом случае нафиг не сдался — ничего полезного не умеет.
Для AMD на наших тестах ICC генерил код хуже, чем GCC, кстати. Так что тут еще вопрос, что лучше.
Здравствуйте, Vamp, Вы писали:
КБ>>А что там смотреть? Гцц проигрывает студийному и интеловскому компилятору по скорости и потребляемой памяти. V>Возможно, так оно и есть. Но свое высказывание хорошо бы обосновать.
Ну вот сравнение с CLang, например: http://clang.llvm.org/features.html
Сравнивается именно скорость и потребление памяти фронт-энда.
V>Кстати, на расход компилятора по памяти (пока он остается таким, что программа в принципе компилируется) наплевать.
только он при превышении определенного значения приводит к дополнительным тормозам из-за постоянного свопа.
Приветствую, Vamp, вы писали:
V> Скорость неважна, если проект маленький. Вот у нас проект — компилируется около 4 часов
А на скольки машинах оно параллельно компилируется? Или просто ну ооооочень большой проект?
Здравствуйте, jazzer, Вы писали:
КБ>>>>>А что там смотреть? Гцц проигрывает студийному и интеловскому компилятору по скорости и потребляемой памяти. N>>Я заранее соглашусь. Ну пусть проигрывает? И что с того? N>>Скорость и память компиляции — фактор обычно очень мало значимый. Значительно важнее, например, то, что работа по переносу gcc на доселе неизвестную платформу — один человеко-месяц. А как с VC? Под что он умеет компилировать кроме x86? Меня вот сейчас PPC интересует.
J>Это ты говоришь про back-end, а тормозит front-end, который ну никак не зависит от количества платформ, поддерживаемых back-end-ом. J>На back-end никто и не нападает, вроде.
Ну, во-первых, мне странно разделять их в этом контекте. Они же не поставляются раздельно? Конечно, при определённых усилиях можно одну из этих частей заменить (как в гибриде gcc frontend + LLVM, на котором в основном испытывался LLVM). Но мало кто на сейчас так делает, и особенно мало — делает сам.
Во-вторых. Ты говоришь про те тормоза, которые ты упоминал, или абстрактные тормоза имени КБ? Твои — да, frontend. Но когда говорят что "gcc тормозит и жрёт" независимо от экстремальных ситуаций типа "дофига шаблонов", то речь уже AFAIU про уровень, когда прошла первичная кодогенерация и начинаются оптимизации. В зависимости от настроек там может очень много тратиться.
N>>Если мне потребуется сборка быстро и дёшево по памяти в Linux/x86 — я лучше ICC возьму. MS VC мне в этом случае нафиг не сдался — ничего полезного не умеет.:) J>Для AMD на наших тестах ICC генерил код хуже, чем GCC, кстати. Так что тут еще вопрос, что лучше.
Так я и не говорил про идеальный результат. Вообще GCC по качеству кода сейчас даже на Intel не сильно отстаёт от ICC. Но ценой за это является дороговизна промежуточного слоя.
Вообще, у меня лично основная претензия к GCC — отсутствие возможности ограничить оптимизацию собственно кода пределами одного оператора. При -O0 код часто представляет собой последовательности глупостей типа прогнать одно значение через 5 регистров и засунуть снова в память, а при -O1 уже начинаются прыжки команд вбок и отладчик перестаёт показывать действия соответственно коду. Есть среднеразумный набор ключей для минимизации проблем при -O0 (где-то так: -ftree-dce -ftree-ccp -ftree-copy-prop -ftree-fre). Практически все остальные компиляторы относятся к оптимизации по умолчанию более мягко — код без оптимизации далеко не идеален, но это просто последовательное переложение действий из исходника, а не каких-то внутренних расчётов, кто на ком стоял и почему.
Другие претензии у меня к нему фактически отсутствуют. Это уже моя специфика — C++ не использую, тем более в особо современном стиле; а вопросы типа "а что это за хрень и откуда она пришла" для сишного кода — возникают регулярно.
