Продолжение benchmarks Linux vs. Windows от IBM

Хух-хух - ибээмер автор. Ясное дело, ибэмэ отсосала с осью. Дала себя оттрахать и теперь пытается отомстить. Нехрен было кидать OS/2 и ее пользователей, а теперь изображать оскорбленную невинность. Сама пришла, сама дала.

Радует, что на 2.4.4 работа с памятью быстрее, чем на 2.2.16.

Понравилась сторочка:

Both the older version of Linux and the newer version seem much faster in memory transfers than Windows 2000. It is not clear what is going on here. Further investigation is required.

Дальнейшее исследование? Да кому оно нужно:))

Как всегда нагрянет невозмутимый Irsi и начнет опровергать р-ты:)) Только не надо гнать, что все дело в компиляторе. Может еще лучьше было бы тесты на пне 4 проводить, тогда бы мы посмотрели "поддержку и оптимизацию" Майрософтовского компилера под этот "революционный" проц.

АХТУНГ!!! W2k опять на подсосе =)

Да глупые тесты опять. на сайтах где любят Win кричат как Win крута а тут все наоборот. Каждый сочиняет ля себя сказки и сам их и слушает. Скорее всего винды медленнее линукса но это не главный показатель для операциоки. Есть еще понятие как поддержка железа, как стабильность производителя и наконец просто удобство и распространенность и по всем этим показатеолям винды круче.

2anonimous "... наконец просто удобство ... " хммм.... "The Windows 2000 and Linux "mechanisms" for determining that information are: Windows 2000 navigation path to MHz: Start/ Settings/ Control Panel/ Administrative Tools/ Computer Management/ System Tools/ System Information/ System Summary Linux command to display MHz: cat /proc/cpuinfo " И что удобнее? :))))

Вместо Start/ Settings/ Control Panel/ Administrative Tools/ Computer Management можно RightClick по My Computer и там уже Computer Management. ;-)

"RightClick по My Computer" ? а если надо, чтобы эту информацию получил скрипт??

Win был отстоем им и останется.

У меня на athlon'e вот такая цифирь получилась:

# ./memxfer5b -p -s -csv 16m 8 0 1 2 3 4 5 6
memxfer5b -s -p -csv 16777216 8 Linux
"memcpy",16777216,134217728, 0.550, 243.922
"char *",16777216,134217728, 1.168, 114.953
"short *",16777216,134217728, 0.870, 154.338
"int *",16777216,134217728, 0.572, 234.627
"long *",16777216,134217728, 0.559, 239.983
"__int64 *",16777216,134217728, 0.564, 238.039
"double *",16777216,134217728, 0.486, 276.009

Это был линукс

IMHO, нехватает сарвнения с другими популярными и полу-популярными
интелевскими осями.
С другой стороны, продемонстрированный рейтинг, всего лишь
кости -- ламерский алгоритм испоганит любую производительность.
Такие пузомерки я писал еще лет 7-10 назад. Тогда со
стороны win32 выступал nt3.51 -- он работал чуток побыстрее (а
мой первый slackware 1.2(?).* (извините не помню), возможно, чуть
помедленее.
Можно долго и красиво говорить о "ненаучном подходе" и "заказных
тестах" -- Все равно, сомнения тают даже у апологетов win32 -- по
производительности linux вполне пригоден для любых
проектов, где можно ставить intel. По надежности -- лично мне
напильник и долото для отрубания неужного и слабого еще нужны.
Не за горами новое ядро (по крайней мере, в этом тысячилетии :))
-- там много заточек под большие DBMS (все-таки спонсоры). Вот тогда
можно будет и селекты потестировать.

ха, чувак, какой ламерский алгоритм может быть при копировании блоков памяти (тем более что на всех осях один и тот же алгоритм юзался, даже если его оптимизировать под x86, индекс скорости поднимется везде, и все останется на своих местах)?? или ты придумал алгоритм BlackRabbita, который в десять раз быстрее под windows работает?

sergey_volosat (*) (2001-06-25 09:56:23.0)
Нет, к тестам притензий нет, просто пообщался в выходные со
знакомыми.
Волосы дыбом стояли от того как и что пишут. Выдумывают свою (!)
пузырьковую сортировку (мне кажется, что это не выдумка, а теневое
воспоминание олекциях первого-второго курса) и хотят ее применять к массивам порядка 1е6-1е9. Но тестирую на массиве 1000. Там все, разумеется хорошо.
Еще раз повторяю к тестам притензий нет, хотя лично мне интереснее
файловые операции -- последние 5 лет работаю с БД и файлами, которые
много больше адресного пространства R32.

У M$ вообще проблемы с производительностью менеджера памяти по жизни были. Потому тесты закономерные. Вспоминается история с портированием непомню какой игрушки (давно это было) SEGA на PC. Так сеговцам пришлось бедным свои менеджер памяти писать, чтоб тормозов ужасных не было. Переписали почти все системные вызовы по работе с памятью из WinAPI! Кому интересно: на www.sources.ru в разделе Delphi лежит соответствующий код. Когда я им пользовался, скорость обращения к памяти в моих программах возрастала раза в 1,5-2 (архиваторы пописывал под вынью). Что для меня неожиданно, так это то, что в W2k, похоже, та же шняга!

У меня вообще подозрения, что в одно время работала одна хорошая команда и нагенерировала несколько хороших идей, а счас остались те, кто хочет лишь получить деньги но сделать уже ни чего не могут. Вот и получается такая байда. Может это команда из IBM была ?

Игорь.

2 онанимус: насчет поддержки железа, то в 2000 винтузе не все так круто, как кажеться. Дофига кривых драйверов. У друга стоит сканер Mustek, так уже полгода не может драйвер поставить, грит не сертифицирован Майрософтом( что-то типа такого, я сам не знаю), и ниче не сделаешь, может ты посоветуешь?;)) Идем дальше: отвратительный драйвер под MX300, нету драйверов под Mpeg-2 плату от Creative ( сам на днях буду пробовать прикручивать ее к RH7.0 ), я уже не говорю о том, что на LX чипсете ваш Винтуз просто не ставиться и т.д.

Кроме реализации TCP/IP от FreeBSD в Винтузе, Майрософт могла бы наверное еще кое-чему поучиться у той же Фрюхи...

2IRON: Я воще на w2k ещё не переходил, потому ответить не могу. Ждёмс... До третьего сервиспака... До третьего сервиспака... Сервиспак генералу Суворову! ;-) Народная примета: до 3-го обновления все версии ОС Windows считать беттами! ;)

Про MX300 сам офигеваю - Diamond, любимый, почему так с тобой? Если был бы жив, там написали бы драйвера нормальные. Драйвер mx300 написать, кстати, не самая простейшая задача. Сколько его под линух делали? Больше года точно. Для линуха хоть недавно умельцы свояли нормальные драйвера под MX300. А то для прослушивания mp3 я винду грузил :-( XMMS рулез форева!

2IRON Не сертифицирован != не работает.

2 онанимус: if ( $driver eq "Не сертифицирован") { die "Гуляй Вася" } Так?:))

Интересно, если я напишу соберу один и тот же код на асме, корирующий блоки памяти, как может тут влиять операционка на производительность? Ф-ии ОС вызываться-то не будут.

sergey_volosat: "ха, чувак, какой ламерский алгоритм может быть при копировании блоков памяти (тем более что на всех осях один и тот же алгоритм юзался, даже если его оптимизировать под x86, индекс скорости поднимется везде, и все останется на своих местах)?? или ты придумал алгоритм BlackRabbita, который в десять раз быстрее под windows работает?"

Сереж, только не смейся. Есть алгоритмы копирования, которые на порядок быстрее обыкновенного. Так что разница в полтора раза это еще маленькая разница.

Теоретически.

Если ОС с вытесняющей мультизадачностью (NT, Linux), то кроме тестовой задачи ещё будут вызываться функции синхронизации процессов ядра ОС. Происходит это потому, что вышеназванные сисетмы никогда (по теории), не должны выделять все ресурсы (читай процессорное время) одной задаче. Замечание: ядро считаю тоже задачей.

Практически.

Реальная разница будет 1-2%, не более. Если, конечно, полностью на асме писать. Но больше синтетический тест, далекий от реальности. В большую часть прог ДиспЗад на асме не суют.

> Сереж, только не смейся. Есть алгоритмы копирования, которые на порядок быстрее обыкновенного. Так что разница в полтора раза это еще маленькая разница.

Точно! Но я тогда только начинал кодить на Вынь, потому и 1.5-2

Кстати, ppm2 (аналог bzip2 под win) есть в двух вариантах: быстрый (со своим менеджером памяти) и обычный. Разница получается действительно нехилая: 8-12 раз. Я пока сам не попробывал - не поверил.

Вопрос в другом: если такой менеджер поставить на Вынь, то работать это будет не более минуты. ;-) Потом хана. Быстрый, не значит стабильный. Хотя, для узких задач этот метод ускорения работает на ура. В прогах я его использую часто. Данные так можно хранить! Работает стабильно.

С менеджером памяти Линуха я только недавно начал разбираться. Похоже - там тоже есть кое-что из дёгтя...

-SeRGi-

> Интересно, если я напишу соберу один и тот же код на асме,
> корирующий блоки памяти, как может тут влиять операционка на
> производительность? Ф-ии ОС вызываться-то не будут.

А куда они денутся? Система многозадачная, шедулер всяко свое отожрет. Опять же, память надо сначала выделить, а как она реально выделяется - еще вопрос, может - по обращению к странице. Вон линуксовый malloc(), сколько у него не попроси - NULL не выдаст, а потом при записи обломаешься, если память кончилась.

А является ли самым быстрым копирование movsqw , repn (короче копирование 4 байтных слов на архитектуре intel 32bit ?)
А то я как-то давно слышал про копирование через регистры сопроцессора, мол быстрее это - но что-то не совсем понимаю реальность этого.

Игорь.

Интересно, я слепой или там действительно не указано с каким приоритетом пускалась данная прога под w2k?

Шедулер больше 2% загрузки проца не берёт. (i386 я в расчет не беру!). Потому на асме и разница небольшая будет. Вся проблема в том, что вызовы ядра, тот же malloc(), под вынь использует перестраховочные методы работы с памятью (читай - меделенные). Иначе все ядро полетит к чертям ... Большая часть проблем у MS от этого. Ни много, ни мало ;-)

-SeRGi-

2Игорь: double - 64 бита, соответственно, идейно должен быть в два раза быстрее. Но там еще достаточно хитростей, а я не очень большой знаток архитектуры Интела, сорри.

2 Irsi: врядли тестовая система была настолько загружена, чтобы приоритеты еще ставить...

2Irsi: Если других задач не было, то приоритет ни на чего не влияет. Другое дело, что список процессов (исключая обычные системые) автору надо было бы привести для галочки. А то, может, действительно тестовая машина была сервером СУБД ;-)

2ZhekaSmith: Ага.
Я вообще сморосил - "4 байтных слов " Короче четностью в разрядность архитектуры. 32 бита то бишь.

Игорь.

2Игорь: разрядность архитектуры это несколько абстрактное понятие (как правило имеется ввиду разрядность целых регистров общего назначения), доступ к кэшу для сопроцессора может вполне быть 64-битным, а сама шина работы с памятью 128 битной. Поэтому копирование через сопроцессор может быть быстрее...

Не в тему конечно... но все же: когда будут новые голосования на ЛОР??
А то про тему вайт2 уже по-моему с зимы тут...

Личный опыт говорит об обратном - приоритеты влияют и довольно сильно, даже на незагруженной системе. Впрочем чтоб не быть голословным и не устраивать пустой флейм, я обязательно на днях это проверю и сообщу результаты...

2Irsi: "Личный опыт говорит об обратном - приоритеты влияют и довольно сильно, даже на незагруженной системе."

Это, надеюсь, про Win? Какой ужас.

По цифрам создается впечатление что используются разные алгоритмы, чтобы они там не говорили. Gcc дает стабильный результат в мегабайтах, что характерно для быстрого копирования, MS VC дает сильно разный результат в мегабайтах для типов char и int, что характерно для более простых алгоритмов копирования.

2ZhekaSmith: То есть.

память-> регистр FPU
регистр FPU -> память
inc blablabla
loop по смыслу

Быстрей будет чем специализированное

загрузка регистров
movsq ; копировани 4 байт за раз aka данные = разрядностью процессора
reps ;

Или я не понимаю чего-то.

Игорь.

2ZhekaSmith: понимаешь ли в "ненагруженных" виндах все равно существует некоторое кол-во сервисов... И почему-то в линуксе всех которых можно демонов перед тестированием гасить не забывают, а виндах сервисы - забывают... Неоднократно замечал при глубинных раскопках методик тестирования такую особенность...

2Игорь: Не все так просто. Вот здесь лучше написано:

http://now.cs.berkeley.edu/Td/bcopy.html

Можешь потестировать на своей системе и посмотреть как оно.

В данном случае Irsi прав.

Мои тесты на дифуре с частными произвозными на массиве 1000 gcc vs cl 8.0 vs bcc32 на win98 и BlackCat 5.2 для одной и той-же проги (консоль) показывали незначительное различие gcc, cl, bcc32 соответственно первый, второй, третий. Разницa ( на память) порядка 0.5%, а то и меньше. Под Win резльтат зависил от состояния системы. Под Linux крутились X-ы.(из xterma) Два варианта проги на C и на С++.

2Irsi: Когда будешь тесты делать. Сделай тест с меньшими размерами блоков. Т.к. копирование 16мег из одного места в памяти в другое, довольно странное занятие для реального приложения.
2IRON: "if ( $driver eq "Не сертифицирован") { die "Гуляй Вася" } Так?:))"
Просто нажать на кнопку, "Да я хочу поставить этот драйвер. А если что-то сломается потом, то мы Вас предупредили" и ни каких проблем.

2Anonimous:

Решение дифуров - это тест скорее не памяти, а FPU. Потому, от особенностей ОС зависит меньше (тем более на маленком массиве). Тестирование-то проводилось именно по подсистеме работы с памятью: ахилесовой пяте M$.

2Irsi: !!! Это и пытается доказать автор теста: > One possibility for the differences in memory copy performance is that Windows does more work in the background than Linux. > In fact, the Linux loop contained two more instructions than the Windows generated loop.

Сервисы только тут не причем.

Просто ВыньДос более жирная ОС по сравнению с Linux (в отношении качества и компактности кода, разумеется).

ЗЫ. Я даже слышал не раз, что при написании последних версий Windows активно применяются макро-языки (которые в конце концов преобразуются в СИ, разумеется).

Windows2003 на основе VisualBASIC ;-)

Зато быстро и дешево. Тенденция,понимаешь...

2Irsi,Ogr:

***** Параграф *7* Вы почти уже стали федиком, не останавливайтесь на достигнутом,слушайте: *****

Пункт 1.

Если вы сеpьезно и кpyто имеете несколько эх, помните в сyтках лишь 24 часа,не пишите одновpеменно, что вы спите и видете отсоснонаные сны 12 часов в день, сидите в инете 8, администpите юникс и вмс-кy еще 10, занимаетесь боевой магией еще 3 часа, 12 часов кpядy игpаете в квакy, вечеpом 4 часа в кольчyге и с заточенной отвеpткой гоняете всю шпанy в микpоpайоне, за ночь имеете тpех подpyг, котоpых запикапили в течении 3-х часов вечеpней пpогyлки, а кpоме того yхитpяетесь еженедельно апгpейд. комп и заpабатывать сеpьезные бабки кpyтым пpогpаммиpованием или в сеpьезном бизнесе,и пpи всем этом активно пишите в 53 эхи, и читаете и пописываете еще в сто однy...... Всегда найдется мyдак котоpый yмеет считать до 24 четыpех...

Это почти смеpтельный yдаp.

2anonymous (*) (2001-06-25 21:30:16.0): "Всегда найдется мyдак котоpый yмеет считать до 24 четыpех..."
Только ты не учел одной вещи мне не надо трахатся с компом как это делаешь ты anonymous (*) (2001-06-25 21:25:49.0). :) Вот уж где смертельный удар :)

Не стоит безумно беспокоиться за жизнь других. Так можно прожить свою не насладившись ей.

2BlackRabbit: ну тогда я против тебя ничего не имею ;)

онанимус, ????????? говорищь? :) Павлины гришь? А все дело в том, что мы, как верно заметил Org, не трахаемся со своим компом и со своими серверема - они у нас просто работают... А мы за это (за то что сервера работают без проблем) денюжку получам, да еще время на развлечения остается, чтоб сюда писать в том числе...:)

2Irsi,Ogr: Дурака бесит не ответ, а отсутствие внимания.

2SeRGi: ты прав...:) но у меня есть свои соображения...:)