>>ассемблере - маленькие куски кода (к тому же код, написанный вручную
>>на ассемблере может быть быстрее кода на всеми так любимом C).
>Если _хорошо_ уметь программировать на ассемблере. Иначе - далеко не факт. Ну на самом деле сгорбить на ассемблере так как это порой делает сишный компилер еще суметь надо.Хотя если асм видеть впервые в жизни - всякое возможно.Ну тогда если на сях писать будет чайник он тоже может наворотить такого что легко оптимизируется по скорости раз в 10.Если же взять пример из реальной жизни - чисто сишный вариант XVID сливает asm-оптимизированному варианту в РАЗЫ.Просто потому что критичные к скорости куски написаны на асме и это тот случай когда лишние микросекунды запросто могут вырасти в лишние ЧАСЫ.
>уметь программировать на асме хорошо - совсем не тоже, что просто
>уметь программировать. Я вот умею, но не хорошо. Поэтому напишу на
>C.
На самом деле - программировать на ассемблере большой проект глупо.Если программа в 2Кб - да, вы легко натянете любой компилер более оптимально выделяя регистры и прочая.А вот если программа будет уже 500Кб кода - вы запутаетесь в кучах переменных и нифига не сможете уже эффективно выделять регистры и в глобальном плане компилятор может обделать вас по общей оптимальности кода.Ему то пофиг сколько переменных и кода - он железный.Посему асм уместен в совсем маленьких программах где надо выжать максимум (скажем, программирование однокристаллок с крохотной RAM и Flash на борту) или пишут на сях а то и сях++ а на асме только реально критичные к скорости фрагменты (см например как написаны XVID, X264 и прочая).Тогда можно получить и скорость "почти как на асме" и общие трудозатраты лишь чуть больше чем если все вообще писано на си.
>>а на производительность практически никак не повлияет.
>Как бы это помягче сказать... Вы не правы, вот.
Ишь размечтались то.Еще как повлияет.Все что связано с быстрым выводом графики очень чувствительно к лищним действиям.MS вон вообще когда делал NT 3.51 сперва сделал графику в user режиме.Вышло тормознуто и система провалилась с треском.Пришлось в кернель засунуть.Хоть и ценой стабильности.В итоге от NT4 до Висты графика живет в ядре.Большой такой кусок GDI снесен в ядро (драйвер ядра "win32k.sys").
>(а вот их пойди ещё обнаружь). Или вы считаете компиляторы (особенно
>GCC) непогрешимыми?
Ну да, непогрешим он, черта с два... в любом компилере баги есть.И msvc с internal error падает, и gcc глючный код сгенерить могет особенно с -O более чем 2.Особенно меня прут предложения писать на D.А, потом, простите вы представляете себе получившийся глюкодром и что потом с ним делать?!Да, лет через ...цать когда все критичные глюки в компилере D и в коде будут отловлены оно может и будет замечательно(правда тут же накопается еще вагон глюков).Только вот к тому времени иксы пожалуй будут ничем не хуже.
>C++ - ОЧЕНЬ сложный язык. На нём можно написать что угодно, но
>это вовсе не значит, что на нём стоит что угодно писать.
Написание чего-то типа иксов на сях++ приведет к распуханию системы.Работа графической подсистемы станет еще тормознее (при том что иксы никогда и не были чемпионом по скорости) и оперативки они еще больше жрать станут (а они и так скромностью не страдают - в top посмотрите если не верите).
>А D надо бы для начала самореализоваться,
А потом еще отладиться и обезглючиться.
>>Так что незначительное (а чаще незаметное) увеличение производительности,
То что относится к графической подсистеме НЕ МОЖЕТ быть незначительным и незаметным.От скорости работы этой подсистемы зависит скорость работы графики в системе.Если допустить что производительность просядет скажем всего на 20%, допустим мы смотрим HD киноху.И допустим что в идеале производительности хватает на показ всех кадров.Теперь представляете себе что 20% кадров дропнулось.Смотреть киноху станет тошновато.
Аналогично - скажем побегать в "кваку".Есть разница между 10-12 и скажем 15-20 fps.Да и compiz при тормозах как-то не очень.Более того, и интель и амд за 20% производительности - УДАВЯТСЯ.А вы предлагаете просто взять и просрать... вот только если в средне-типичной апликухе которая 99% времени ждет реакции юзера а 1% времени работает разницу на 20% юзер не особо заметит, то в случае с иксами юзер будет видеть эту разницу везде и постоянно.
>Опыт показывает, что багов меньше там, где, во-первых, лучше квалификация работников, а
>во-вторых, где используются наиболее простые схемы. C++ - это НЕ просто.
По-моему, монструозность иксов и так зашкаливает за разумные пределы.Потому и баги.Быстрые и стабильные программы без багов - простые.Потому и... .А так - ну вон aMule есть.Писан на сях++.И что, там нет багов?Да их там до**я.При том гораздо более до**я чем в писаной на гольных сях transmission.
>И ему не место в массовом X-сервере, кроме как (допускаю) в
>прикладных программах, типа xeyes.
+100!
>>нуждаются в оптимизации, могут быть выявлены при помощи профилировщика).
Ну допустим выявили вы их, а дальше то что?
>витаете в облаках.
Во-во.Такие фрукты уже в Сименсах меню на яве сделали.Получилось ттооррммооззнноо.И юзеров это бесило.Ну а где теперь siemens mobile вместе со своими концепциями - все мы знаем.
P.S. других идиотов делающих менюху телефона с хилым процессором на Java я не видел.
>за эту мощность приходится платить. Я люблю C++, это мой второй
>любимый язык после C# - но одно дело язык, а другое
>дело его реализация.
С++ и C# - хороши для программера, но вот получившийся результат если использовать не в меру и не к месту только для программера и будет хорош.А по мнению остальных - это будет поделка для маргиналов.Ну, примерно как микроядерные системы сейчас.То есть вроде идея и ничего но вот тормозные системы в которых ядро нихрена не умеет все-таки почему-то никому не нужны.
>А кто вам сказал, что программирование - это гонка за скоростью?
Ну, если не гоняться за скоростью - будете как MS с вистой пытаться найти идиотов которые бы это согласились использовать.
>Качество кода зависит от качества реализации языка и используемых библиотек и от
>качества мозгов того, кто собственно пишет код (а так же ставит
>задачи).
Золотые слова.Снимаю шляпу.
