> Почему-то тот же Hotspot (а это ведь фактически rocket science на
> ниве compiler construction) написан именно в стиле С-with-classes, без особой метамагии…
Потому что те, кто его писал, не умеют писать на С++. Во многих местах метамагию можно было бы применить довольно по делу.
Есть также мнение, что метамагия не применялась по религиозным (политическим) соображениям.
;)
Это зависит от того, насколько сотрудник лоялен компании. Он мог бы запросто снижать свою производительность примерно пропорционально штрафам, а то и больше, а в конце концов уволился бы.
Да понятно что и на винде проблем куча может возникнуть.
Тут дело в том, что если что-то не работает в винде — то это либо баг в софте, либо неправильная настройка среды выполнения.
Если что-то не работает после сборки из исходников — то это ещё может быть и неправильная настройка среды сборки.
Моё мнение заключается в том, что в большинстве среда сборки требует гораздо более тщательной настройки, чем среда исполнения. Поэтому всё-таки нужно уходить от распространения софта только в виде исходников.
Ну этим пользователем был я. Чисто по случайности я оказался ещё и программистом, поэтому причину определил просмотром исходников и чтением документации по sys_call.
Откуда взялись левые заголовки ядра я не знаю. Машиной пользовался не я один, возможно кто-то установил более новые. Возможно более новые заголовки потребовались ещё для какой-нибудь прилады.
Проблема тут не в том кто виноват, а как сделать чтобы работало. Диагностика проблемы крайне сложна для пользователя.
Ключевое слово здесь «обычно». Конечно, и в винде возникают проблемы (бывают такие что и гугление не помогает), но в винде это «обычно» более обычно, чем в Linux.
Может быть это конечно и преувеличение, но иногда приходится попотеть даже программистам.
Вот вам пример: программа собралась, а при запуске разваливается или говорит «ERROR: not supported». Что делать пользователю? Как он поймёт что проблема например в том, что установлены kernel headers версии, отличной от используемого ядра?
>% make install <на этом шаге установится нужная программа>
На этом шаге нужная программа _попытается_ собраться из исходников и установиться. Ещё ладно если всё развалится из-за того, что какой-то файл не найден (либа). А если при компиляции выдаются ошибки, то что делать пользователю? Единственный вариант — усиленно гуглить и спрашивать по всяким форумам, что вообще говоря и не каждому то виндовому пользователю под силу.
Неужели действительно кто-то считает что в Debian не используются самые свежие ядра, потому что они не успевают их быстро включить в дистриб?
Использование самых свежих ядер противоречит идеологии Debian. У них вообще почти весь софт не самый свежий, потому что процесс тестирования (нахождения в состоянии testing) длится довольно долго, чтобы обеспечить бОльшую надёжность.
Так что на самом деле здесь как раз и есть взаимоисключающие требования: стабильность и свежесть.
Компилятор может генерировать более эффективный код именно потому, что он железка, и ему всё равно, какого размера получится код функцийй — 200 инструкций или 2000 инструкций.
Конечно железяка не сравнится с человеком, но чтобы написать код более эффективно, чем это делает компилятор, требуется потратить много усилий. Человек может позволить себе это для нескольких мест в программе, но на то чтобы сделать это со всей программой просто не хватит времени и сил, а код в результате получится неподдерживаемым.
Примеры банальны: Как часто вы на ассемблере делаете:
1) Открытую подстановку (инлайн), вместе с протяжкой констант, удалением неиспользуемого кода и вычислением константных выражений и после этого ещё и новым перераспределением регистров? Как обстоят дела с поддержкой такого кода?
2) Часто ли вы делаете раскрутку циклов более сложных, чем пара инструкций (например инструкций 15)?
Смысла использовать float на FPU вообще нету. Но всё зависит от архитектуры, на которой работает JVM. При использовании float например на x86 можно лучше сделать векторизацию (выполнить больше операций за раз), а например на ARM разместить на регистрах в два раза больше переменных.
> а) он таки кончится, а приложение (surprise!!) не
> масштабируемое, потому что «лучше один большой
> сервер с C++, чем много маленьких с perl/ruby/erlang»
Производительности какого из компонентов железа по-Вашему может не хватить?
Каким образом вы предлагаете производить обмен данными между «маленькими серверами с „perl/ruby/erlang“?
Через базу? Тогда как вы гарантируете, что „не кончится“ сервер под базу? Масштабирование с помощью Partitioning/replication? Использовать memcached? Как решать проблему актуальности кэша при изменении данных в базе?
Если не через базу, то как вы будете осуществлять обмен данными между серверами? Как обеспечить синхронизацию одновременно между несколькими серерами?
Понимаете, всё зависит от типа задачи. Если у вас „сайт вроде Хабра“, где запросов на чтение сильно больше запросов на запись, и нет интерактивности в реальном времени, то возможно большинство из прелестей синхронизации вам удастся избежать. Если же вам требуется болше интерактивности, то это может стать серьёзной проблемой. Представьте себе банальный чат на нескольких серверах без использования базы.
Вот и делается попытка избежать всех этих прелестей, попытавшись уместить всё в одном срервере. Гораздо проще масштабировать по количеству ядер/объёму памяти, чем по количеству серверов.
Да, согласен, если база является узким местом, то оптимизировать надо именно её.
Но тут речь идёт о том, чтобы свести обращения к базе к минимуму. И хочется обеспечить одновременную обработку как можно большего количества запросов. Тут уже сказывается не скорость выполнения кода, а архитектура сервера. Вы считаете, что какой-нибудь обычный Java APP-сервер сможет держать нагрузку сравнимую с асинхронным приложением (хотя бы на той же Java)?
> ниве compiler construction) написан именно в стиле С-with-classes, без особой метамагии…
Потому что те, кто его писал, не умеют писать на С++. Во многих местах метамагию можно было бы применить довольно по делу.
Есть также мнение, что метамагия не применялась по религиозным (политическим) соображениям.
;)
www.google.com/support/forum/p/Talk/thread?tid=089ae52d97176669&hl=en — в топике ровно один пост, в котором содержится dump траффика s2s. Никакой ссылки не обнаружил.
Я правильно понял смысл поста по ссылке?
Тут дело в том, что если что-то не работает в винде — то это либо баг в софте, либо неправильная настройка среды выполнения.
Если что-то не работает после сборки из исходников — то это ещё может быть и неправильная настройка среды сборки.
Моё мнение заключается в том, что в большинстве среда сборки требует гораздо более тщательной настройки, чем среда исполнения. Поэтому всё-таки нужно уходить от распространения софта только в виде исходников.
Откуда взялись левые заголовки ядра я не знаю. Машиной пользовался не я один, возможно кто-то установил более новые. Возможно более новые заголовки потребовались ещё для какой-нибудь прилады.
Проблема тут не в том кто виноват, а как сделать чтобы работало. Диагностика проблемы крайне сложна для пользователя.
Да, согласен, конечно ситуации бывают маразматические. Но это никак не отменяет противоречивости идеологи Debian и RedHat.
Вот вам пример: программа собралась, а при запуске разваливается или говорит «ERROR: not supported». Что делать пользователю? Как он поймёт что проблема например в том, что установлены kernel headers версии, отличной от используемого ядра?
>% make install <на этом шаге установится нужная программа>
На этом шаге нужная программа _попытается_ собраться из исходников и установиться. Ещё ладно если всё развалится из-за того, что какой-то файл не найден (либа). А если при компиляции выдаются ошибки, то что делать пользователю? Единственный вариант — усиленно гуглить и спрашивать по всяким форумам, что вообще говоря и не каждому то виндовому пользователю под силу.
Использование самых свежих ядер противоречит идеологии Debian. У них вообще почти весь софт не самый свежий, потому что процесс тестирования (нахождения в состоянии testing) длится довольно долго, чтобы обеспечить бОльшую надёжность.
Так что на самом деле здесь как раз и есть взаимоисключающие требования: стабильность и свежесть.
Конечно железяка не сравнится с человеком, но чтобы написать код более эффективно, чем это делает компилятор, требуется потратить много усилий. Человек может позволить себе это для нескольких мест в программе, но на то чтобы сделать это со всей программой просто не хватит времени и сил, а код в результате получится неподдерживаемым.
Примеры банальны: Как часто вы на ассемблере делаете:
1) Открытую подстановку (инлайн), вместе с протяжкой констант, удалением неиспользуемого кода и вычислением константных выражений и после этого ещё и новым перераспределением регистров? Как обстоят дела с поддержкой такого кода?
2) Часто ли вы делаете раскрутку циклов более сложных, чем пара инструкций (например инструкций 15)?
> масштабируемое, потому что «лучше один большой
> сервер с C++, чем много маленьких с perl/ruby/erlang»
Производительности какого из компонентов железа по-Вашему может не хватить?
Каким образом вы предлагаете производить обмен данными между «маленькими серверами с „perl/ruby/erlang“?
Через базу? Тогда как вы гарантируете, что „не кончится“ сервер под базу? Масштабирование с помощью Partitioning/replication? Использовать memcached? Как решать проблему актуальности кэша при изменении данных в базе?
Если не через базу, то как вы будете осуществлять обмен данными между серверами? Как обеспечить синхронизацию одновременно между несколькими серерами?
Понимаете, всё зависит от типа задачи. Если у вас „сайт вроде Хабра“, где запросов на чтение сильно больше запросов на запись, и нет интерактивности в реальном времени, то возможно большинство из прелестей синхронизации вам удастся избежать. Если же вам требуется болше интерактивности, то это может стать серьёзной проблемой. Представьте себе банальный чат на нескольких серверах без использования базы.
Вот и делается попытка избежать всех этих прелестей, попытавшись уместить всё в одном срервере. Гораздо проще масштабировать по количеству ядер/объёму памяти, чем по количеству серверов.
Но тут речь идёт о том, чтобы свести обращения к базе к минимуму. И хочется обеспечить одновременную обработку как можно большего количества запросов. Тут уже сказывается не скорость выполнения кода, а архитектура сервера. Вы считаете, что какой-нибудь обычный Java APP-сервер сможет держать нагрузку сравнимую с асинхронным приложением (хотя бы на той же Java)?
То, что C++, Java и C# при использовании схожей архитектуры будут показывать сравнимую производительность, по-моему очевидно.