Просмотр полной версии : HugoRandomBenchmark
Читал статью про KVM (http://popey.com/Compiling_kvm_Under_Ubuntu_Edgy_i386) и натолкнулся на забавный бенчмарк ;)
http://www.hants.lug.org.uk/cgi-bin/wiki.pl?HugoRandomBenchmark
Предлагаю внести лепту - пополнить результаты. :)
Кто желает, запустите бенчмарк
for i in `seq 1 5`; do time perl -e 'for($i=0;$i<1e8;$i++) { }' ;done
Свой процессор
cat /proc/cpuinfo | egrep '(model name|MHz)'
и лучший из 5 замеров (где время будет наименьшее) публикуйте в тэге SP :) Потом внесу их в вики по ссылке выше.
Сделал.
model name : AMD Athlon(tm) 64 Processor 3200+
cpu MHz : 2009.268
real 0m19.512s
user 0m19.345s
sys 0m0.088s
Но это с зарущенными иксами и всякими другими приложениями, можно было вырубить иксы и большинство процессов; поднять частоту процессора.
Doctor_Zlo
29.05.2007, 22:25
Вот что у меня вышло.
model name : Intel(R) Celeron(R) M processor 1.40GHz
cpu MHz : 1400.145
real 0m16.471s
user 0m15.993s
sys 0m0.012s
Мои пять копеек
model name : Intel(R) Pentium(R) 4 CPU 2.40GHz
cpu MHz : 2411.886
real 0m21.084s
user 0m21.078s
sys 0m0.002s
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3600+
cpu MHz : 2004.483
real 0m20.205s
user 0m19.697s
sys 0m0.000s
model name : Celeron (Coppermine)
cpu MHz : 952.175
real 0m38.170s
user 0m38.102s
sys 0m0.068s
model name : Pentium II (Klamath)
cpu MHz : 233.898
real 162.89
user 160.87
sys 0.12
model name : Intel(R) Pentium(R) 4 CPU 3.06GHz
cpu MHz : 3066.915
real 0m12.086s
user 0m12.017s
sys 0m0.036s
Пока что самая длинная <censored> у Frosty... :)
tmp0000, дык неудивительно. :) В этом тесте мегагерцы решают, а у Frosty их больше всех.
На батле их больше, но постоянную нагрузку, искажающую результаты, не снять. Так что и бенчмарк не прогнать. :D
Там на сайте, кстати, есть более крутой <censored>омер - UNIXBench (http://www.hants.lug.org.uk/cgi-bin/wiki.pl?ByteUNIXBenchmark) :]
Только что прогнал
BYTE UNIX Benchmarks (Version 4.1-wht.1)
System -- Linux ubuntu-box 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux
/dev/sda4 35666008 9592340 24261940 29% /
Start Benchmark Run: Срд Май 30 01:11:41 MSD 2007
01:11:41 up 27 min, 5 users, load average: 0.26, 0.27, 0.21
End Benchmark Run: Срд Май 30 01:23:02 MSD 2007
01:23:02 up 39 min, 5 users, load average: 18.13, 7.46, 3.39
INDEX VALUES
TEST BASELINE RESULT INDEX
Dhrystone 2 using register variables 376783.7 5931209.6 157.4
Double-Precision Whetstone 83.1 1648.2 198.3
Execl Throughput 188.3 3413.3 181.3
File Copy 1024 bufsize 2000 maxblocks 2672.0 64696.0 242.1
File Copy 256 bufsize 500 maxblocks 1077.0 18330.0 170.2
File Read 4096 bufsize 8000 maxblocks 15382.0 379726.0 246.9
Pipe-based Context Switching 15448.6 203900.9 132.0
Pipe Throughput 111814.6 603070.6 53.9
Process Creation 569.3 9916.1 174.2
Shell Scripts (8 concurrent) 44.8 350.8 78.3
System Call Overhead 114433.5 1409761.5 123.2
=========
FINAL SCORE 146.9
Сергей Копылов
30.05.2007, 14:30
model name : AMD Athlon(tm) XP 2200+
cpu MHz : 1808.518
real 0m21.776s
user 0m21.381s
sys 0m0.096s
model name : AMD Sempron(tm)
cpu MHz : 2003.574
real 0m19.609s
user 0m19.309s
sys 0m0.136s
и на закуску ;)
model name : Celeron (Mendocino)
cpu MHz : 400.942
real 1m30.494s
user 1m28.486s
sys 0m0.024s
а вообще бенчмарк довольно странный и результат вроде не зависит от размера кеша.
Добавлено через 50 минут
забыл ещё про пару железок... впрочем они далеко не мои :rolleyes:
model name : Intel(R) Xeon(TM) CPU 2.80GHz
cpu MHz : 2794.219
real 0m13.839s
user 0m13.445s
sys 0m0.017s
processor : 0
cpu : POWER5 (gr)
clock : 1654.344000MHz
revision : 2.1
processor : 1
cpu : POWER5 (gr)
clock : 1654.344000MHz
revision : 2.1
processor : 2
cpu : POWER5 (gr)
clock : 1654.344000MHz
revision : 2.1
processor : 3
cpu : POWER5 (gr)
clock : 1654.344000MHz
revision : 2.1
processor : 4
cpu : POWER5 (gr)
clock : 1654.344000MHz
revision : 2.1
processor : 5
cpu : POWER5 (gr)
clock : 1654.344000MHz
revision : 2.1
processor : 6
cpu : POWER5 (gr)
clock : 1654.344000MHz
revision : 2.1
processor : 7
cpu : POWER5 (gr)
clock : 1654.344000MHz
revision : 2.1
timebase : 207051000
machine : CHRP IBM,9124-720
real 0m37.559s
user 0m37.549s
sys 0m0.004s
последняя штучка очень быстрая, но т.к. тут один поток, то и выполняется он на одном процессоре :)
model name : AMD Athlon(tm) 64 Processor 3000+
cpu MHz : 1809.305 (указанный выше алгоритм даёт ошибочный результат, поэтому для определения характеристики использовал hwinfo)
real 0m19.250s
user 0m19.221s
sys 0m0.004s
Также из hwinfo.log:
Processor Info: #4
Socket: "Socket 939"
Socket Type: 0x12 (Other)
Socket Status: Populated
Type: 0x03 (CPU)
Family: 0x1d (Athlon)
Manufacturer: "AMD"
Version: "AMD Athlon(tm) 64 Processor 3000+"
Processor ID: 0x078bfbff00020ff0
Status: 0x01 (Enabled)
Voltage: 1.7 V
External Clock: 200 MHz
Max. Speed: 3000 MHz
Current Speed: 1800 MHz
L1 Cache: #10
L2 Cache: #11
...
Cache Info: #10
Designation: "Internal Cache"
Level: L1
State: Enabled
Mode: 0x01 (Write Back)
Location: 0x00 (Internal, Not Socketed)
ECC: 0x02 (Unknown)
Type: 0x02 (Unknown)
Associativity: 0x02 (Unknown)
Max. Size: 128 kB
Current Size: 128 kB
Supported SRAM Types: 0x0020 (Synchronous)
Current SRAM Type: 0x0020 (Synchronous)
Cache Info: #11
Designation: "External Cache"
Level: L2
State: Enabled
Mode: 0x01 (Write Back)
Location: 0x00 (Internal, Not Socketed)
ECC: 0x02 (Unknown)
Type: 0x02 (Unknown)
Associativity: 0x02 (Unknown)
Max. Size: 512 kB
Current Size: 512 kB
Supported SRAM Types: 0x0020 (Synchronous)
Current SRAM Type: 0x0020 (Synchronous)
П.С. Может разогнать чуток?
П.С. Может разогнать чуток?
эти процессоры обычно хорошо гонятся, раза в 1.5, если mb и память позволит.
какие тут могут быть вопросы? ;)
MaXx, как бы не спалить... :unsure:
ArcFi, :D что не спалить? ;)
Читал статью про KVM и натолкнулся на забавный бенчмарк
Ага, мне он тоже показался очень забавным. Такое ощущение - он измеряет площадь поверхности "сферического коня в вакууме". Вы тут всё измеряете, да измеряете, а хоть кто-то разобрался что этот тест измеряет? И главное, какие факторы больше всего влияют на результат?
P.S. Я пока лишь обаружил, что он меряет тормоза perl на не лучшей для него задаче.
Metallist
04.06.2007, 12:26
запустил на kappa.cs.karelia.ru
model name : Pentium III (Coppermine)
cpu MHz : 935.481
real 1m18.985s
user 0m38.998s
sys 0m0.100s
XeNoN, это бенчмарк. Очень условный, но тем не менее, имеющий право на существование. Какая разница, на Perl он или на том же Си? :] Соотношения между результатами все равно будут одинаковыми независимо от того, на чем этот цикл прогоняют.
Metallist, запускать скрипт на загруженной машине вроде каппы бесполезно, результат будет искажен в любом случае.
запускать скрипт на загруженной машине вроде каппы бесполезно
Да, бедная каппа, ее многие имеют даже по ночам...
rmn, ну если на то пошло, то компилятор си бадяжит код прямиком в бинарный вид(да и вообще без особых проблем можно узнать что бадяжит и как) а в случае перла совсем не так. Поэтому и возникает ощущение, что меряются тормоза перла, а никак не частоты процов. Да и за примером далеко ходить не надо(если сравнивать с Си=) ) на сихе такой цикл меньше чем за секунду выполнится, а на Perl'е как видно совсем иннная ситуация, вот тут и возникает вопрос, что он там делает, как?
Очень условный, но тем не менее, имеющий право на существование.
Право на существование никто отменять и не собирается, это как у Маяковского - значит даже такой непонятный benchmark кому-то нужен.:)
Какая разница, на Perl он или на том же Си? :] Соотношения между результатами все равно будут одинаковыми независимо от того, на чем этот цикл прогоняют.
Соотношения между результатами Си и Perl будут разными. На это greiv дал прекрасный ответ.
rmn, поэтому собственно и возникает вопрос, что он там меряет и от каких факторов зависит результат. На этот вопрос я так и не нашёл ответа, поэтому и спрашиваю, что же вы все тут измеряете? С вашим предположением о том что основным фактором является частота процессора я наполовину согласен. Я считаю частоту важным фактором, но далеко не определяющим, иначе как объяснить, что P-III 900MHz показывает схожие результаты с Celeron 1715MHz. Известно правда, что у P-III числодробилка мощнее чем у P-IV. Но неизвестно (ну мне неизвестно, а собирать perl в отладочном режиме лень), что там делает perl при выполнении данного кода. Пока не станет ясно какие факторы определяют результат придётся записывать этот benchmark в ряд обычных "пиписькомеров" (о чём собственно и было упомянуто в названии темы), наряду со сравнением производительности ФС путём разархивирования линукс ядра (это вообще из разряда "для ламеров", настоящие мужики так не меряют).;)
Право на существование никто отменять и не собирается, это как у Маяковского - значит даже такой непонятный benchmark кому-то нужен.:)
:) Бенчмарк как бенчмарк. Задача, по времени исполнения которой можно расставить относительные оценки.
rmn, поэтому собственно и возникает вопрос, что он там меряет и от каких факторов зависит результат. На этот вопрос я так и не нашёл ответа, поэтому и спрашиваю, что же вы все тут измеряете?
Измеряем время исполнения конкретной задачи. Разве не так?
С вашим предположением о том что основным фактором является частота процессора я наполовину согласен. Я считаю частоту важным фактором, но далеко не определяющим, иначе как объяснить, что P-III 900MHz показывает схожие результаты с Celeron 1715MHz.
Да нет, тактовая частота - определяющий фактор, иначе бы смысла в бенчмарке не было совсем.
Про "схожие" результаты, собственно, где они?
Известно правда, что у P-III числодробилка мощнее чем у P-IV. Но неизвестно (ну мне неизвестно, а собирать perl в отладочном режиме лень), что там делает perl при выполнении данного кода. Пока не станет ясно какие факторы определяют результат придётся записывать этот benchmark в ряд обычных "пиписькомеров" (о чём собственно и было упомянуто в названии темы)
А не логично ли было выбрать список рассылки / irc-канал / форум / etc с концентрацией Perl-гуру в разы большей, чем тут, и задать вопрос там, если так интересуют технические детали работы perl? :)
наряду со сравнением производительности ФС путём разархивирования линукс ядра (это вообще из разряда "для ламеров", настоящие мужики так не меряют).;)
нормальное сравнение на реальных задачах (правда, тут не только в производительности ФС дело). ;] Не все же вам bonnie++ подавай. :D
Бенчмарк как бенчмарк. Задача, по времени исполнения которой можно расставить относительные оценки.
Нет, не можем, т.к мы не знаем отчего наши оценки зависят. Иначе необходимо было бы указывать полностью программно-аппаратную конфигурацию и оценивать её целиком, а не только процессор.
Измеряем время исполнения конкретной задачи.Разве не так?
Если конкретика заключается во времени исполнения данного кода perl, то да. Иначе - меряем чтобы мерять.
Да нет, тактовая частота - определяющий фактор, иначе бы смысла в бенчмарке не было совсем.
Почему нет, а какже узнать сколько времени исполняется неизвестно что? И померять как что-то загадочное на это влияет? :D
Про "схожие" результаты, собственно, где они?
CPU: Intel(R) Celeron(R) CPU 1.70GHz (1715.89-MHz 686-class CPU)
35.357u 0.007s 0:40.43 87.4% 10+368k 0+0io 0pf+0w
model name : Pentium III (Coppermine)
stepping : 6
cpu MHz : 935.481
cache size : 256 KB
Total time : 0:39.14m
Time spent in user mode (CPU seconds) : 38.970s
Time spent in kernel mode (CPU seconds) : 0.028s
CPU utilisation (percentage) : 99.6%
P-III - это капповская машина. Как объяснить?
нормальное сравнение на реальных задачах (правда, тут не только в производительности ФС дело). ;] Не все же вам bonnie++ подавай.
Что? Постоянно разархивируете ядро линукса?:D bonnie++ мне не нужен, но мир бы стал ярче и лучше если бы во всех тестах было бы понятно какие факторы влияют на результат. А ярче он бы стал потому что меньше криков было бы по типу: "Наша Генту быстрее вашей Убунту, т.к. CD-диски с ней дальше кинуть можно" Или как некоторые сравнивают производительность ФС так, что у них нет разницы при синхронной записи и ассинхронной - это как раз на вашей "реальной" задаче по разархивированию ядра. (зачем придумали журналирование в ФС надо объяснять?)
P.S. rmn, цель моих постов была не "обосрать" данный benchmark, а привлечь внимание к проблеме тестирования. Примеры нормальных замеров производительности я могу привести.
Нет, не можем, т.к мы не знаем отчего наши оценки зависят. Иначе необходимо было бы указывать полностью программно-аппаратную конфигурацию и оценивать её целиком, а не только процессор.
Если конкретика заключается во времени исполнения данного кода perl, то да. Иначе - меряем чтобы мерять.
Пусть будет так. :]
Почему нет, а какже узнать сколько времени исполняется неизвестно что? И померять как что-то загадочное на это влияет? :D
Так я предложил выше, как можно разобраться. Понятно, что "тормоза" Perl - это от природы. Природу бы знающие люди и объяснили.
P-III - это капповская машина. Как объяснить?
а какая загрузка у этой машины? load average в uptime до и после работы скрипта какой? И какая она у celeron?
P.S. rmn, цель моих постов была не "обосрать" данный benchmark, а привлечь внимание к проблеме тестирования.
Проблему тестирования увидит любой, кто знает что такое Perl и кому приходилось на нем хоть что-либо значительное писать. Другое дело - дать техническое объяснение этих самых "тормозов". Тут уже нужна совсем другая квалификация.
Примеры нормальных замеров производительности я могу привести.
ok. я всё внимание. :)
Так я предложил выше, как можно разобраться. Понятно, что "тормоза" Perl - это от природы. Природу бы знающие люди и объяснили.
Так я тоже предложил - надо собрать perl с опциями -pg и всё станет ясно. Но я считаю, что создатели данного теста и люди предлагающие им воспользоваться, должны были это сделать сами и всё описать.
а какая загрузка у этой машины? load average в uptime до и после работы скрипта какой? И какая она у celeron?
------------------------------------------------------------------------------
P-III
------------------------------------------------------------------------------
user:~ > uptime
10:40am ####### 31 #### 11:01, 10 #############, ####### #############: 0,00,
0,02, 0,05
user:~ > time perl -e 'for($i=0;$i<1e8;$i++){}'
Total time : 0:39.27m
Time spent in user mode (CPU seconds) : 38.910s
Time spent in kernel mode (CPU seconds) : 0.028s
CPU utilisation (percentage) : 99.1%
Times the process was swapped : 0
The number of input operations : 0
The number of output operations : 0
The number of system calls performed :
The total space used in Kbytes : 0
The maximum memory the process had
in use at any time in Kbytes : 0
user:~ > uptime
10:42am ####### 31 #### 11:02, 10 #############, ####### #############: 0,62,
0,18, 0,10
user:~ >
------------------------------------------------------------------------------
Celeron 1.7 GHz
------------------------------------------------------------------------------
[XeNoN:~]# uptime
10:34 up 10 mins, 3 users, load averages: 0,16 0,14 0,09
[XeNoN:~]# time perl -e 'for($i=0;$i<=1e8;$i++){}'
35.304u 0.022s 0:37.34 94.5% 10+365k 14+0io 21pf+0w
[XeNoN:~]# uptime
10:35 up 11 mins, 3 users, load averages: 0,48 0,22 0,12
[XeNoN:~]#
Проблему тестирования увидит любой, кто знает что такое Perl и кому приходилось на нем хоть что-либо значительное писать. Другое дело - дать техническое объяснение этих самых "тормозов". Тут уже нужна совсем другая квалификация.
Ничерта не понял, как проблемы тестирования связаны с perl? Помоему это некая общая проблема.
Вы с экспериментальной физикой знакомы?
ok. я всё внимание.
Ну раз "всё", то вечером расскажу.:)
Вы с экспериментальной физикой знакомы?
Какой четкий вопрос задал XeNoN(блин, опередил). Я как раз хотел написать про тест и физический эксперимент. В том смысле, что по сути создать тест, это значит соблюсти все теже условия для постановки физ. эксперимента(даже хотел превести пример из своей курсовой=) ). Иначе же получается, что здесь меряют ради того, чтобы мерят. Получается так, что народ сидит в своей "песочницы", что там меряет и радаются(типа) мол какой проц у меня мощный, комп быстрый, а тех кто пытается до них достучаться мол вы хоть сами-то понимаете чем занимаеетесь, отвечают - пшел вон, ненадо рушить наш мирок, нам и так хорошо... грустно что тут скажешь
Получается так, что народ сидит в своей "песочницы", что там меряет и радаются(типа) мол какой проц у меня мощный, комп быстрый, а тех кто пытается до них достучаться мол вы хоть сами-то понимаете чем занимаеетесь, отвечают - пшел вон, ненадо рушить наш мирок, нам и так хорошо... грустно что тут скажешь
меня всегда удивляет, почему люди всегда, ну или почти всегда, считают, что они лучше знают, что для других хорошо, а что плохо ;)
я к тому, что создали люди мирок, рады этому - зачем им мешать, если их всё устраивает и им в нём очень даже хорошо? радоваться за них надо, что у них всё без проблем и они живут счастливой жизнью.
ну это меня уже понесло... :)
Ну раз "всё", то вечером расскажу.
Рассказываю.
Во-первых примеры нормальных тестов можно посмотреть на сайтах Intel, AMD, Sun, IBM, и т. д. и т. п. Все эти фирмы делали тесты-числодробилки, тесты ФС (у Sun ZFS присутствует целый набор различных стресс-тестов и тестов производительности). Можно поглядеть тесты входящие в MySQL. Также множество методов тестирования рассмотрены в публикациях различных университетов.
Во-вторых для нормального процесса измерения/тестирования минимум необходимо:
1. Понимание процессов происходящих в измеряемой системе.
2. Учёт и определение степени влияния различных факторов на измеряемую величину.
3. Средства измерения.
4. Построение схемы измерения, позволяющей с достаточной точностью провести эксперимент.
5. Чёткое понимание того, зачем всё это делается.
Естественно, что всё вышеприведённое - это мой краткий пересказ, не на что не притендующий. На этот счёт разработана целая теория, с которой можно ознакомиться в различной литературе.
Большинство "пиписькометров" отпадают по всем пунктам.
Вот это:
time perl -e 'for($i=0;$i<=1e8;$i++){}'
в большей степени противоречит пунктам 2 и 5. Потому как никто в данной теме не знает зачем нужен этот тест (вернее использует не по назначению), непонимает какие факторы влияют на его результат (все приводят как определяющий фактор процессор).
В сравнении производительности ФС по времени разархивирования ядра Linux не учитывается время работы архиватора(это самое долгое что здесь вполняется) и время работы дисковой подсистемы. Но утверждают почему-то что основную работу делает ФС.
(Чаще кстати измеряют не время выполнения чего-то, а количество выполненых операций за некоторое время)
Примеры нормальных тестов и их правильного использования:
1. Тесты MySQL. С их помощью например исследовалось поведения нового планировщика FreeBSD - ULE2 на SMP системе в сравнении с предыдущими версиями - ULE, 4BSD и планировщиком Linux. В результате новый планировщик показал лучшие результаты чем предыдущие, а также чем планировщик Linux. Таким образом разработчики FreeBSD - убедились в правильности выбора направления развития, а разработчики Linux смогли выявить и устранить проблему в своем планировщике. (А что ваш тест показал? Что Intel впустую потратили столько сил на увеличение частоты своих процессоров?)
2. При разработке UFS2 была разработана альтернативная к журналированию и COW система поддержания согласованного состояния дискового хранилища - Soft Updates (SU). Необходимо было оценить её производительность. В качестве худшего по производительности варианта взяли синхронный режим записи (S) на диск, а режим асинхронного (A) как самый производительный. Был написан набор тестов:
-> 1-й тест состоял из 1000 запусков контрольной задачи Эндрю: 1000 копирований и удалений /etc со случайно выбранными паузами от 0 до 60 секунд между каждым удалением и копированием и 500 исполнений утилиты find / со случайно выбранными паузами в 100 сек. между каждым запуском. Измерялось количество синхронных и асинхронных записей на диск и время прогона. Время прогона для ФС в режиме S - 27ч. 54мин. , для A - 19ч. 43мин., а для SU - 19ч. 50мин.
-> 2-й тест состоит из построения и инсталяции FreeBSD. Т.е задача является практически примером среды разработки программ. В результате время прогона и соотношение синхронных записей к асинхронным для S - 2ч. 12мин. 162410 к 39924, для A - 1ч. 44мин. 0 к 38262, для SU - 1ч. 44мин. 1124 к 48850
-> 3-й тест сравнивает производительность основного почтового сервера BSDI, запущенного с SU и S (МакКузик говорит, что там админ испугался в асинхронном режиме запускать:) ). Статистика была собрана путём усреднения результатов операций за 30!!! рабочих дней в каждом режиме. Результаты: S - 1877794 к 1613465, SU - 118102 к 946519. Вывод: для этого практического приложения SU требуют на 70 процентов меньше записей, что утраивает способность машины к обработке почты.
Так же неплохая методика тестирования описана на сайте SGI про тестирование XFS.
Вобщем надеюсь суть ясна, что измерение/тестирование требует подключение дополнительных возможностей мозга к тем, которые требуются для поиска в google и щёлканья по ссылкам. Особенно важно понимать зачем оно вообще нужно. Лично для меня это не "пиписькомер", а метод/средство позволяющее лучше понять зависимость между различными вещами и выявить узкие участки. В benchmark'е с которого началась данная темя я таких возможностей без доп. исследования не заметил. Но всё равно "спасибо" rmn за убитое свободное время, которое я провёл с различными эксперементами на разных языках, на разных машинах и может всё-таки соберу perl в отладочном режиме и попробую понять чё он там делает этот benchmark.:D
я к тому, что создали люди мирок, рады этому - зачем им мешать, если их всё устраивает и им в нём очень даже хорошо? радоваться за них надо, что у них всё без проблем и они живут счастливой жизнью.
Вот это и напрягает, что живут без проблем, счастливой жизнью. Такое бывает? Да и мирок-то получается навязанный со стороны, ложный, т.е. люди неконтролируют ситуацию, какое тут счатье...
Приминительно к теме. Вот щапривиду пример тех за счет кого строятся счастливые мирки=). Есть такой пользователь юникс-подобных систем со стажем! как X(не буду писать его фамилю) много статей написал про линукс и фряху. Решил как-то протестировать производительность UFS2(фс во фряхе). Значит, что он сделал взял исходники фряхи разархивировал с асинхронной записью на диск и с синхорнной. И о чудо(ну он подумал нихера себе чудо). Результаты получаются одни и теже, что с асинхоронной, что с синхронной. Оболдеть тестер нашелся, блин даже не смешно, лучше бы писал и дальше свои статейки как mc раскрасить, консоль руссифицировать и т.д. А ведь народ-то поверить, как же так такой уважаемый автор не мог нам соврать. Другой пример. челс решил измерить производительность фряхи и нетбсд на многопроцессорных тачках. Взял скомпилил исходники нетбсд(с соотвествующими опциями для многопроцессорной байды) сначала на нетбсд, а затем ее же исходники на фряхе и оказалось, нетбсд производительней!!!(хотя с SMP у нетбсдяшников ) Я чуть не слег после такого теста... Я думаю, говорить о том что каждый уважаемый себе линуксойд тестить фс разархивированием линукс ядра вообще излишне. Вот такие вот личности создают счастливые мирки. Если вас устраивать, то живите наздоровье=)
vBulletin® v3.8.4, Copyright ©2000-2024, Jelsoft Enterprises Ltd. Перевод: zCarot