На сайте IBM появилась статья, посвященная сравнительному анализу реализаций технологии потоков Linux vs Windows.
Там же приведены исходники тестовых примеров и графики производительности.
А как тогда stream переводить? Опять же ведь как "поток" обычно
переводят?
Offtopic: в свое время на ВМК в меня вбили так: thread -- нить,
pipe -- канал, stream -- поток, branch -- ветвь.
А статья оставила двоякое впечатление. Такой разницы не ожидал. И если
win2000 хоть "слабое подобие Линукса" по скорости, то XP... Мда. С
другой стороны, видать, каналы (pipes) в win не так уж нужны, что
так отвратительно работают...
А кажущееся неудобным ограничение Линукса в 4К на блок на деле может
и плюсом обернуться: программист больше будет головой думать
(вспомните, к чему привела попытка автора засунуть 256М в виндовый
канал. Стандартная реакция: "да не вопрос, давай, не подавлюсь!". Ага.
Завис).
P.S. Я не фанат ни Линукса, ни *BSD, ни win*. Давайте без ненужного
флейма.
хммм... вроде как линукс тоже unnamed pipes поддерживает?
или я что то не так понял?:
"Windows pipes are more complicated than Linux pipes. Windows supports named and unnamed pipes"
Идеология Виндоуз совершенно иная, отличная от аскетичного Unix Way. Там заместо трубочек (о как настоящие индейцы "pipes" переводят!) всякие COM-ы юзаются. Заместо кучи мелких приложений, базарящих через stream-ы, в трубочки закаатнные, там большие и жирные компоненты, связи промеж которых совершенно неочевидны.
А вопрос у меня такой
кто может дать пример,
где ну очень нужно прокачивать больше 45 mb/s?
Даже с учетом 45 енто сумарная цифра для нескольких разных applications.
Производительность производительностью, а функциональность у pipes под win32 и Linux разная. Под win32 pipes поддерживают асинхронный ввод-вывод и транзакции. :p
2 Spy: Этого паренька даже на slashdot обосрали с ног до головы. Дело в том, что у XP на стримах висят ACL и они могут быть шифрованные. Он к тому же использовал named pipes, unnamed быстрее, гонял все на ноутбуке, на неизвестной версии XP, в неизвестных условиях, и "забыл" о том, что pipes - нерекомендуемый в windows IPC механизм.
О, блин, как архаровцы зашевелились.
Для людей которые интересуются делом, а не 3.14-жом, скажу, что года два назад в fido ru.qnx был аналогичный проект сравнения QNX и линуха. Линух оказался шустрее.
Что до механизма IPC в виндовс - его почти нет. Те механизмы, которые аналогичны линуху по производительности закрыты от программера так, что непонятно, как они работают.
Конечно, Герб Шилд когда-то восторгался многозадачностью в тогда еще Вынь 95, но сегодня я думаю, дым уже развеялся. IPC в виндовс куда менее прозрачно, чем в unix-like системах, а следовательно, способствует написанию ненадежного кода. (Для флеймеров) спорить не буду, можете писать все что угодно. Я обращаюсь к тем, кто головой а не жопой думает.
Реализация pipes в линухе - одна из самых эффективных. Это было заметно еше на ядре 2.0. Замечу, что чувак проводивший тест, явно не использовал ряд разработок ATT Labs и IBM в этой области. При их применении дисперсия результатов была бы меньше, а характер зависимостей был бы ближе к линейному.
Но меня очень интересует механизм сообщений. Очень бы хотелось взглянуть на стороннее тестирование. В основном сравнение с QNX и подобными, Вынь меня мало волнует. Если кто видел, поделитесь знанием pls!
2 rivares:
>Что до механизма IPC в виндовс - его почти нет. Те механизмы,
>которые аналогичны линуху по производительности закрыты от
>программера так, что непонятно, как они работают.
Ну перечисли, плиз.
Пайпы, RPC, шаренная память, sockets есть. COM, как надстройка над RPC. Mожет что-то забыл, напомни.
На сайте IBM мужик из Samba team сказал, что сравнивали apples and oranges
Табличка из MSDN, насчет того, где что поддерживается:
IPC Mechanism Win2000 WinNT Win9x Win32s(1) Win16(2) MS-DOS(2) POSIX OS/2
------------- ----- ----- ------ -------- -------- -------- ----- -----
DDE YES YES YES YES YES NO NO NO
OLE 1.0 YES YES YES YES YES NO NO NO
OLE 2.0 YES YES YES YES YES NO NO NO
NetBIOS YES YES YES YES YES YES NO YES
Named pipes YES YES YES(3) YES(3) YES(3) YES(3) YES(4) YES
Windows sockets YES(5) YES(5) YES YES YES(5) NO NO(6) NO
Mailslots YES YES YES YES(3) NO NO NO YES
Semaphores YES YES YES NO NO NO YES YES
RPC YES YES YES(7) YES(8) YES YES NO NO
Mem-Mapped File YES YES YES YES NO NO NO NO
WM_COPYDATA YES YES YES YES(9) YES NO NO NO
А какого х.я windows sockets?
Хочу BSD sockets!
:))))))))))))))))))))))))))))))))))))))))))))))))))))
А вообще - IMHO, под виндой много чего можно напрограммировать... Но очень легко сделать конкретное Г..о :(((((
Попробовали на Athlon 1000/DDR + Win2k Pro, получили где-то 85 Mb/sec
с командой -x 4096 4096 4096
Попробовали на P-II-400 с RedHat Linux 7.1, kernel 2.4.3 - 202 Mb/Sec
Нам стало обидно за Windows и сели мы этот исходник (с 2 тредами) править.
Собственно заменили именованые каналы на неименованые а-ля *nix.
Там тоже также 2 описателя, как в Linux: для чтения и записи.
Так справедливее по отоношению к винде.
Получили вместо 85 - 179 Mb/Sec
Конечно, Linux уходит вперед с гигантским отрывом, но все же производительность Windows более чем в 2 раза занизили в этой демонстрашке, используя неадекватные Linux вызовы.
А то ведь позиксные ОС обязаны и mem-mapped, и семафоры, и Sun RPC,
и сокеты поддерживать. А вообще, в смысле IPC все отдыхают
по сравнению с QNX. Ну, равзе что ещё HURD на общем сером фоне выделяется...
Звонит девушка на радио и просит поставить для своего парня песню Аллы
Пугачевой про женщину у которой зависли винды... Диджей удивляется:
- Это какую?
- Ну... там...
- Слова-то какие?
- "Кликну - а в ответ тишина, снова я осталась одна, сильная женщина
плачет у ОКНА"
Про QNX подробнее pls. И с фактами какие IPC (семафоры, сообщения, разделяемая память, сигналы, трубы) где отдыхают и как. И не забудь указать, о каком QNX говоришь - v4 или RtP. Желательно результаты тестов в студию.
Для фанатов Windows - покажите серьезный проект, который использует pipe или сигналы. ИМХО все работают с COM. Я не спорю, COM использует IPC, но как оно это делает ведомо только Биллу Гейтсу. Для офиса это конечно сойдет, а вот для промышленного применения - не очень.
Не даром SCADA с Win на верхнем уровне стоят приличных бабок. Да и работать с ними - удовольствие еще то.
rivares:
Для фанатов Windows - покажите серьезный проект, который использует pipe или сигналы. ИМХО все работают с COM.
Приезжай - покажу. Систему управления электросталеплавильной печью емкостью в 100 тонн :) Полный автомат, управление трансформаторами, дозаторами и т.д. - все из программ, работающих на 3 компах с Windows 2000 Advanced Server + 1 комп с Windows NT 4.0 SP6a.
1 - база данных Oracle 8i
2 и 3 - сервера приложений
4 - сервер сбора информации (масса плат аналогового и дискретного ввода)
Все - без всяких сторонних SCADA, pure C++ ;) Проги обмениваются данными через Windows Named Pipes. Все работает весьма надежно уже около года.
Кстати, умеет Linux через пайпы обмениваться между разными компьютерами, как это легко осуществляется в Windows?
Какие тесты? Я не про производительность говорю, а про удобство использования. Message passing - штука рульная... Особенно когда она на уровне ядра реализована.
P.S. А что, тебе так страшно даже написать слово "Антихрист"? Хрюшка позорный...
Кто мешает закатать пайп через простенький враппер поверх ssh, к примеру?
Я всегда так делал... Сетевая прозрачность - главное достоинство пайпов
и стримов в сравнении с более сложными IPC.
Под юниксом обмен данными через tcp сокеты и пайпы реализуем через read/write - посему можно использовать tcp как средство общения между компами.
Винду для управления такой системой использовать - оригинально..
Может и оригинально, но работает весьма неплохо. В промэксплуатации уже полгода, проблем никаких :)
К тому же несмотря на бесплатность Linux, система, сделанная на Windows 2000, обошлась нам дешевле:
1) Не нужно было искать платы аналогового и дискретного ввода/вывода, которые Linux поддерживает, а можно брать их согласно требованиям к точности и надежности.
2) Не нужно было переучивать программистов. Это значительно сократило сроки работы и уберегло от ошибок, которые всегда допускаешь, начиная работать с новой для тебя системой.
3) Проще разработка ввиду наличия под Win32 отличных отладчиков и сред программирования. К тому же по Win32 море документации, где расписано буквально все. Один msdn.microsoft.com чего стоит! Под Linux же приходится пользоваться либо Unix'овыми книжками, где не все совпадает с линуксовой реальностью, либо рыться в чужих исходниках.
Про QNX я вообще молчу. Там стоимость ОС и необходимого ПО просто фантастическая. К тому же пришлось бы отказаться от нашей любимой базы Oracle, так как под QNX нет Oracle client.
Будущее OpenVMS, на которой до этого у нас было сделано несколько систем управления, крайне неопределенно... Да и AlphaServer - очень дорогое удовольствие...
Куда приезжать? Это во-первых.
Где можно получить подробную информацию (структура системы, решаемые задачи, если возможно, почитать ТЗ) перед тем как ехать.