Еще раз о программировании Windows vs. UNIX

[Big Cheese]

(Навеяно дискуссией о сервере для Привета)

Еще раз о пресловутой разнице в программировании "для Window" vs. "для UNIX" (ну, там, threads vs. processes, далее везде...) Понятно, что Юниксов разных много, но стиль программирования там вроде как один и тот же, и он (стиль) весьма отличается от Windows API, так что на мой взгляд такое сравнение не должно быть сильно надуманым.

Неужели эта разница настолько принципиальна, что не позволяет с приемлимыми издержками на написание/покупку некой platform abstraction lib собирать из единой codebase сравнимые по производительности версии продукта для win и для *nix?

Ибо создается впечатление, что если некий "серверный" программный продукт разрабатывается (изначально) на Unix, то от его Windows версии ничего хорошего в плане производительности ждать не приходится. Например, смотрю я на BerkeleyDB - вроде неплохая система: удобная, многоплатформенная, но после просмотра их реализации "мьютекса" для win32 возникает стойкое убеждение, что автор(ы) просто не удосужились прочитать online help на CreateEvent из MSDN. Из других примеров можно привести, например, Apache, MySQL, и, наверно, Tomcat.

Есть ли в природе примеры удачной реализации многоплатформенных продуктов loosely defined as "server applications", одинаково хорошо работающих под UNIX и Windows?

Интересуют мнения с обоих сторон баррикад

PS: помнится, tengiz когда-то давно интересовался сравнением Uniх API c Win32 API on NT platform, но тот топик куда-то пропал (или я не смог найти). Интересно было бы посмотреть, чем там дело закончилось.

[YellowMan]

Оракл ? MS Office, MS Internet Explorer ?
Или речь только про бесплатные поделки ?

[Arte]

Ну вот самое простое - возьми Апач. Он и на выне32 быстрее работает (версия больше 2.0) чем местный ИИС. Про Unix/Linux молчу... тама ИИС нетути.

[Dmitry67]

Рассказывали мне про Oracle
На Win он почему то читает через кеш Windows
КРоме того он использует threads вместо процессов, поэтому лимитирован 2Gb

[Vovka]

Ну вот самое простое - возьми Апач. Он и на выне32 быстрее работает (версия больше 2.0) чем местный ИИС.

А здесь можно поподробней?
Какая конфигурация, что за задача, как тестировали и производительность меряли?

[Arte]

А здесь можно поподробней?
Какая конфигурация, что за задача, как тестировали и производительность меряли?

Конечно можно. Ищите в Гугле, или на самом сайте Апача. Линк дать? www.apache.org

[Michael Popov]

... но после просмотра их реализации "мьютекса" для win32 возникает стойкое убеждение, что автор(ы) просто не удосужились прочитать online help на CreateEvent из MSDN.

вот в том-то и дело.
А платформенные баррикады, они как и разруха - в голове.
По большому счету нет никакой разницы на какой платформе писать. Есть только привычки, наработанный опыт, знание библиотек и инструментов. Все это сугубо субьективное.

По поводу много-платформенных библиотек. Это еще один уровень абстракции. Надо разбираться с еще одним набором тараканов. В результате, если есть необходимость писать много-платформенный сервер, то команда нарабатывает свою библиотеку: проще, дешевле, надежнее и под контролем.

[шпиён]

Есть ли в природе примеры удачной реализации многоплатформенных продуктов loosely defined as "server applications", одинаково хорошо работающих под UNIX и Windows?

Да. Наш софт прекрасно работает и на Win, и на нескольких юниксах (если там компиляторы не начинают пургу гнать, вроде GCC, сошедшего с ума от ::delete на указатель на базовый класс (с виртуальным деструктором, не волнуйтесь). Как раз в одной из библиотек "platform abstraction layer", BTW.

[шпиён]

По поводу много-платформенных библиотек. Это еще один уровень абстракции. Надо разбираться с еще одним набором тараканов. В результате, если есть необходимость писать много-платформенный сервер, то команда нарабатывает свою библиотеку: проще, дешевле, надежнее и под контролем.

Не могу согласиться на 100%. Т.е. свой PAL все равно писать надо, но, если речь идет о C++, сейчас уже (год как, с выходом VC7.1) имеет смысл начинать с boost, IMHO. Не полного boost - но тем не менее.

[Michael Popov]

По поводу много-платформенных библиотек. Это еще один уровень абстракции. Надо разбираться с еще одним набором тараканов. В результате, если есть необходимость писать много-платформенный сервер, то команда нарабатывает свою библиотеку: проще, дешевле, надежнее и под контролем.

Не могу согласиться на 100%. Т.е. свой PAL все равно писать надо, но, если речь идет о C++, сейчас уже (год как, с выходом VC7.1) имеет смысл начинать с boost, IMHO. Не полного boost - но тем не менее.

Kaк всегда: it depends Сотни влияющих факторов. Диапазон выбора: от ANSI C (Win32/POSIX) до JavaEE/.NET. Mне в основном приходится сталкиваться с задачами, для которых левая часть диапазона больше подходит.

Kроме того, если не ошибаюсь boost существенно отличается от 3rd party библиотек вроде RogueWave and others.

[Big Cheese]

По поводу много-платформенных библиотек. Это еще один уровень абстракции. Надо разбираться с еще одним набором тараканов. В результате, если есть необходимость писать много-платформенный сервер, то команда нарабатывает свою библиотеку: проще, дешевле, надежнее и под контролем.

А как же разделение труда, специализация и прочий технический прогресс? Или PAL - вещь настолько интимная, что одна мысль об использовании сторонней библиотеки кажется кощунственной?

[Michael Popov]

По поводу много-платформенных библиотек. Это еще один уровень абстракции. Надо разбираться с еще одним набором тараканов. В результате, если есть необходимость писать много-платформенный сервер, то команда нарабатывает свою библиотеку: проще, дешевле, надежнее и под контролем.

А как же разделение труда, специализация и прочий технический прогресс? Или PAL - вещь настолько интимная, что одна мысль об использовании сторонней библиотеки кажется кощунственной?

Нет. Ты же знаешь, "ничего святого"
Просто зачастую overhead связанный с необходимостью сделать библиотеку generic enough вырастает до неприемлимых размеров. Авторам библиотеки нужно угодить и мне, и Васе Пупкину и еще сотням потенциальных пользователей. А мне нужно решить мою задачу с заданными параметрами эффективности и к определенному сроку. Так что собственный код выигрывает по сравнению с библиотекой.

Disclaimer: я говорю о библиотеках имплементирующих system concepts (mutexes, threads, memory, sockets). Библиотеки имплементирующие domain knowledge незаменимы.

[Big Cheese]

Оракл ? MS Office, MS Internet Explorer ?
Или речь только про бесплатные поделки ?

Насчет Оракла я не уверен - помнится, несколько лет назад считалось, что Оракл (у нас была версия 7.3) под NT не блещет, в частности из-за того, что не использует особенности fle I/O платформы типа FILE_FLAG_NO_BUFFERING, overlapped I/O и т.п. Может, они это исправили в новых версиях.

MS Office и IE - это все-таки не серверные продукты, для них платформозависимые вещи не настолько критичны. Могу ошибаться, но мне всегда казалось, что не-Виндовс версии Майкрософтовских продуктов (Office, IE) обычно медленнее, отстают по функциональности - одним словом - weak sisters.

[Big Cheese]

Нет. Ты же знаешь, "ничего святого"
Просто зачастую overhead связанный с необходимостью сделать библиотеку generic enough вырастает до неприемлимых размеров. Авторам библиотеки нужно угодить и мне, и Васе Пупкину и еще сотням потенциальных пользователей. А мне нужно решить мою задачу с заданными параметрами эффективности и к определенному сроку. Так что собственный код выигрывает по сравнению с библиотекой.

Выигрывает, но при условии, что ты одинаково хорошо понимаешь особенности архитектуры / узкие места и т.п. _всех_ target platforms, иначе - проигрывает. Примеры тому - многие бесплатные и не очень бесплатные продукты...

[Palych]

Могу ошибаться, но мне всегда казалось, что не-Виндовс версии Майкрософтовских продуктов (Office, IE) обычно медленнее, отстают по функциональности - одним словом - weak sisters.

Dlya Mac OS X - tak ono i est'.