FreeBSD VS NetBSD
Я про NetBSD слышал много хорошего, что в сумме можно выразить как научный подход.
Надо бы поставить где-нибудь поиграться.
Надо бы поставить где-нибудь поиграться.
Ты всегда внимательно читаешь почту от людей с адресом подобным: rustyyahoo.co.uk?
Готов поспорить, что тебе кто-то дал ссылку на этот пост. Потому что, если бы ты регулярно читал freebsd-current и freebsd-hackers, то заметил бы, что подобные тролли появляются с регулярностью в пару месяцев. И этот ничем особенным не отличается от других.
Готов поспорить, что тебе кто-то дал ссылку на этот пост. Потому что, если бы ты регулярно читал freebsd-current и freebsd-hackers, то заметил бы, что подобные тролли появляются с регулярностью в пару месяцев. И этот ничем особенным не отличается от других.
А тесты тоже тролль сделал? Письмо - это так, ерунда. Ты лучше тесты посмотри.
Как известно, в тестах всегда побеждает любимая ОС тестирующего.
выглядит песдато. только почемуто NetBSD очень мало где стоит
"Why use UNIX, when NT is more popular?"
Ну как тебе сказать. Цифры могут отличаться, но не зависимости. Заметь, в NetBSD почти все операции - O(1). Во FreeBSD - O(n).
не про то
PS: ты всегда можешь проверить сам:
The scalability benchmarks were supplied by F. von Leitner[2]. The threads benchmarks were provided by the Gelato project at the University of New South Wales, Australia (http://www.gelato.unsw.edu.au/IA64wiki/NPTLbenchmarks). The ``ping-pong'' benchmark was provided by Sun Microsystems[5]. Source code for the other benchmarks can be found at ftp://ftp.netbsd.org/pub/NetBSD/misc/gmcgarry/bench/.
The scalability benchmarks were supplied by F. von Leitner[2]. The threads benchmarks were provided by the Gelato project at the University of New South Wales, Australia (http://www.gelato.unsw.edu.au/IA64wiki/NPTLbenchmarks). The ``ping-pong'' benchmark was provided by Sun Microsystems[5]. Source code for the other benchmarks can be found at ftp://ftp.netbsd.org/pub/NetBSD/misc/gmcgarry/bench/.
FreeBSD 5.3 has made significant developments with its symmetric multiprocessor (SMP) architecture, particularly in the area of scalability with fine-grained locking. NetBSD 2.0 continues to use a single lock to serialize access to kernel mode.Кстати на однопроцессорной машине аналогично будет выглядеть сравнение FreeBSD 4.11 и 5.3. Логично, что fine grained locking дает больший оверхед, чем Giant. Т.к. оно не даёт видимых преимуществ на UP, то логично, что этот оверхед будет вот так вылазить.
> Цифры могут отличаться, но не зависимости.
Можно выбрать другой набор бенчмарков.
Заметим также, что сколько бы микробенчмарков мы ни проводили, сделать однозначный вывод о поведении реальных задач не получится.
Причины: кэш, разные фрагментации etc.
Можно выбрать другой набор бенчмарков.
Заметим также, что сколько бы микробенчмарков мы ни проводили, сделать однозначный вывод о поведении реальных задач не получится.
Причины: кэш, разные фрагментации etc.
> Кстати на однопроцессорной машине аналогично будет выглядеть сравнение FreeBSD 4.11 и 5.3. Логично, что fine grained locking дает больший оверхед, чем
> Giant. Т.к. оно не даёт видимых преимуществ на UP, то логично, что этот оверхед будет вот так вылазить.
А что, во FreeBSD при компиляции для UP локи не исчезают совсем?
> Giant. Т.к. оно не даёт видимых преимуществ на UP, то логично, что этот оверхед будет вот так вылазить.
А что, во FreeBSD при компиляции для UP локи не исчезают совсем?
Еще раз: конкретные цифры могут различаться. Но все эти причины не могут повлиять на оценки: O(1 O(n)... Это математика 
Я думаю это просто невозможно(?) Логика должна поменяться весьма сильно...
> Еще раз: конкретные цифры могут различаться. Но все эти причины не могут повлиять на оценки: O(1 O(n)... Это математика
Это не математика - правильность оценок не доказана, они лишь предполагаются, исходя из графиков.
Если берём другие бенчмарки, то зависимости будут другие. Правильный выбор бенчмарков позволит победить правильной системе.
Это не математика - правильность оценок не доказана, они лишь предполагаются, исходя из графиков.
Если берём другие бенчмарки, то зависимости будут другие. Правильный выбор бенчмарков позволит победить правильной системе.
Ну как сказать... Если говорится к примеру sheduler O(1 то предполагается что это доказано... Хотя ты МОЖЕШЬ быть прав, но мне в это не особо верится. Я пожалуй не буду спорить, а просто в свободное время посмотрю как там у них все сделано.
> Если говорится к примеру sheduler O(1 то предполагается что это доказано...
Ну да, pid_t у нас может принимать только конечное число значений.
Ну да, pid_t у нас может принимать только конечное число значений.
Смешно. 
Как будто это невозможно и без этого
Как будто это невозможно и без этого Верно ли, что поиск в хеш-таблице происходит за O(1)?
Раз уж речь пошла о производительности BSD-систем, что вы скажете про эту статейку?
Ты лучше читай посты на osnews.com и slashdot.org, тролли и все типа того начинаются не только в последнее время, а даже года два назад
Все будет хорошо, и ФриБСД, и НетБСД и ДрагонФлайБСД и ГНУ/Линукс и тд. - хорошие системы.
Все будет хорошо, и ФриБСД, и НетБСД и ДрагонФлайБСД и ГНУ/Линукс и тд. - хорошие системы.
> Верно ли, что поиск в хеш-таблице происходит за O(1)?
в идеале - да: при малом кол-ве искомых данных и при сравнительно больших затратах памяти.
в идеале - да: при малом кол-ве искомых данных и при сравнительно больших затратах памяти.
>> Верно ли, что поиск в хеш-таблице происходит за O(1)?
> в идеале - да: при малом кол-ве искомых данных и при сравнительно больших затратах памяти.
O - предел, пока не указано по какой базе он сходится, запись лишена смысла
в данном случае параметра два: размер таблицы и число ключей,
можно подобрать их соотношение в зависимости от желаемого результата
> в идеале - да: при малом кол-ве искомых данных и при сравнительно больших затратах памяти.
O - предел, пока не указано по какой базе он сходится, запись лишена смысла
в данном случае параметра два: размер таблицы и число ключей,
можно подобрать их соотношение в зависимости от желаемого результата
А что, во FreeBSD при компиляции для UP локи не исчезают совсем?Преемпцию тредов UP не запрещает.
> Преемпцию тредов UP не запрещает.
А какой оверхед по сравнению с NetBSD от этого?
А какой оверхед по сравнению с NetBSD от этого?
Про NetBSD не знаю, но сравнения 5.3 и 4.10 в инете есть.
Robert Watson rwatson at freebsd.org
Sat Jan 8 16:22:18 PST 2005
Previous message: Plans about GIANT-LOCK, SMP performance ...
Next message: Plans about GIANT-LOCK, SMP performance ...
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sat, 8 Jan 2005 dkouroun at cc.uoi.gr wrote:
> Does anybody know what are the plans, for locking mechanism like
> GIANT-LOCK in future 5.3 Releases? I have heard from many people that
> this GIANT-Locking mechanism is not the best thing to have! Some said
> that it may be replaced. Some also said that it won't.
>
> 1:) What are the plans about it?
>
> 2:) How does this affect performance?
>
> 3:) Which is version is best for an Opteron QUAD?
> 4.10 Release or > 5.X Release ?
One of the single largest projects associated with the FreeBSD 5.x release
line has been the elimination of the Giant lock from many of the kernel
code paths. FreeBSD 5.0 - 5.2 largely involved introducing the
infrastructure necessary to remove Giant from major subsystems, and while
Giant was removed in some of these releases from a number of important IPC
paths, etc, it was still present over the majority of device drivers, the
network subsystem, and the storage subsystem.
Sat Jan 8 16:22:18 PST 2005
Previous message: Plans about GIANT-LOCK, SMP performance ...
Next message: Plans about GIANT-LOCK, SMP performance ...
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sat, 8 Jan 2005 dkouroun at cc.uoi.gr wrote:
> Does anybody know what are the plans, for locking mechanism like
> GIANT-LOCK in future 5.3 Releases? I have heard from many people that
> this GIANT-Locking mechanism is not the best thing to have! Some said
> that it may be replaced. Some also said that it won't.
>
> 1:) What are the plans about it?
>
> 2:) How does this affect performance?
>
> 3:) Which is version is best for an Opteron QUAD?
> 4.10 Release or > 5.X Release ?
One of the single largest projects associated with the FreeBSD 5.x release
line has been the elimination of the Giant lock from many of the kernel
code paths. FreeBSD 5.0 - 5.2 largely involved introducing the
infrastructure necessary to remove Giant from major subsystems, and while
Giant was removed in some of these releases from a number of important IPC
paths, etc, it was still present over the majority of device drivers, the
network subsystem, and the storage subsystem.
Есть в инете - приводи ссылку, как сам других учишь 
Оставить комментарий
mirt1971
Сравнение производительности FreeBSD && NetBSD:http://www.feyrer.de/NetBSD/gmcgarry/
Ну и пост в freebsd-hackers:
From: Robert Ryan <rustyyahoo.co.uk>
Subject: Benchmark: NetBSD 2.0 beats FreeBSD 5.3
To: freebsd-hackers
Cc: freebsd-current
Date: Thu, 6 Jan 2005 11:57:26 +0000 (GMT)
X-Sent: 28 minutes, 10 seconds ago
Fellow FreeBSD developers,
I hate to say I told you but it was inevitable.
Check this out: http://www.feyrer.de/NetBSD/gmcgarry/
As I predicted more than a year ago FreeBSD 5.3 has
finally lost its only advantage: performance. NetBSD
2.0 shows that when you write code the right way and
end up with SOLUTIONS AND NOT HACKS you have a system
that works, and works well on all platforms.
This is the consequence of a series of mistakes made
by the FreeBSD developers, the most important being
too arrogant and selfish to listen to Matt Dillon, the
man that warned you all about this. What did he get
in return? An expulsion from your gentlemen club.
Poul-Henning Kamp has been using FreeBSD to push his
personal agenda, with completely useless features such
as GEOM and devfs, instead of concentrating on the
real
problem. The fact that your heavily mutexed system
doesn't work and never will.
Jeff Roberson's ULE is still broken but don't worry,
Matt Dillon will be hacking a much better scheduler
for DragonFly that you can later borrow.
Mike Smith warned you about committee-designed code
years ago, why don't you listen? Why do you insist on
this arrogant pose and on treating potential
contributors like pariahs?
Why do you tolerate assholes like Dag-Erling and
Poul-Henning?
I hope you can learn something from the NetBSD people
before it's too late for FreeBSD. They managed to do
much more with less resources. You should feel ashamed
of yourselves.
Sincerely,
Robert
PS: if I've offended anyone (yeah, I singled a few
out)
, prove me wrong, but spare me your insultedness.
It's become a pathetic hobby in -core.