LINUX.ORG.RU

Поддержка SMP в NetBSD


0

0

Следуя сообщению одного из разработчиков NetBSD, система теперь умеет работать на SMP, используя все процессоры в системе. Пока эффективность использования многопроцессорности не слишком велика, но начало положено.

>>> Подробности

★★★★★

Проверено:

Не понимаю, зачем нужен этот отстой....
Лучше бы разработчики NetBSD присоеденились
к какому-нубудь нормальному проекту.

anonymous
()

А почему бы разработчикам Линукса не присоединиться к какому нибудь нормальному проекту?
Зачем делать еще один UNIX? Что в Линуксе принципиально нового?

Havoc ★★★★
()

Линуховое ядро, развивается бестрее всех остальных фрюниховых ядер, и уж объявлять теперь мы умеем работать с n процами в 2001 позор.

anonymous
()

2havoc:
A oni i prisoediniyayutsya - i posle togo nazywayutsya razrabotchikami Linux.

omerm
()

2 anonymous (*) (2001-04-24 11:53:44.0)
Дык, ведь раньше плохо получалось, вот и делятся радостью.
Я не понимаю пессимизма в отношении фряхи -- неплохая ось,
для меня запастной аэродром (иногда, очень редко, заказчик просит
именно ее).

То что _принципиально_решенную_ задачу повторно переписывают,
то же не так плохо. Скучно -- согласен, но 1) каждое переписывание
это всегда поиск структурных ошибок; 2) на чем-то надо тренироваться.


BlackRabit
()
Ответ на: комментарий от Havoc

2Havoc: "А почему бы разработчикам Линукса не присоединиться к какому нибудь нормальному проекту? Зачем делать еще один UNIX? Что в Линуксе принципиально нового?"

Вот это кстати интересный вопрос. И сейчас мы его попробуем прояснить. Когда начинался проект линуха потенциальным разработчикам не было к чему присоединяться. Автор Minix всех отсылал в сад. Разработчик FreeBSD анологично. Hurd то же самое. Вообщем, сидели кулхацкеры, думали что они самые умные (может так и было), и никого до процесса разработки не допускали. Один Линус по молодости сказал - поможите люди добрые кто чем может. Возможно, потом он уже и сам был не рад, но слово не воробей, и ему начали усиленно помогать. Потом, когда все поняли чем один стиль разработки отличается от другого, было уже поздно. Линух по популярности далеко ушел вперед. Отсюда мораль - не надо быть снобом, и думать что ты умнее всех, даже если так оно и есть. А главное - не отсылай всех в сад, максимум 9/10.

ZhekaSmith
()

В общем-то это хорошо когда к разработке ядра не допускаются все кому не лень :) Может мне кто-нибудь объяснит почему сразу после выхода нового ядра от Линуса, его тут-же патчит Кох. Или Линус только новые фичи девелопит и его не волнует насколько стабильно они работают? Хорошо быть впереди планеты всей, но я думаю SMP в исполненни NetBSD (а потом портированное на остальные BSD ветки) - будет в результает эффективнее. Поживем увидим :)

Bauron
()

Я ничего не хочу сказать плохого о Линуксе.
Да NetBSD не слишком распространена.
Но NetBSD неплохой полигон для обкатки разных идей, которые потом могут заимствовать другие операционки.
Довольно много людей защитили диссертации на NetBSD, и это по моему неплохо.
Я считаю, что NetBSD должна жить, хотя бы в качестве испытательного полигона.
А в FreeBSD team людей принимали и принимают, но далеко не всех. ИМХО, это правильно.

Havoc ★★★★
()
Ответ на: комментарий от Bauron

2Bauron:
>В общем-то это хорошо когда к разработке ядра не допускаются все
>кому не лень :) Может мне кто-нибудь объяснит почему сразу после
>выхода нового ядра от Линуса, его тут-же патчит Кох
Два человека - это много? В Линуксе разработка ведется не через
CVS, а через патчи, хорошо это или плохо - вопрос другой, важно что
иначе... Способ разработки ядра линукса - это всего лишь еще один
путь, доказавший свою эффективность, но это не значит что он
"единственно верный".

Led ★★★☆☆
()

Мда. Господа "пионэры", посмотрите на список плафторм, поддержиываемых NetBSD. А теперь на Линуксовый. Есть вопросы?
SMP никогда не было приоритетной задачей для NetBSD team.

--
wart

anonymous
()

>посмотрите на список плафторм, поддержиываемых NetBSD. А >теперь на Линуксовый. Есть вопросы?

Ну и шо ???

Большая разница ???
Списки примерно одинаковые.....

anonymous
()
Ответ на: комментарий от anonymous

2wart:
>посмотрите на список плафторм, поддержиываемых NetBSD. А теперь на
>Линуксовый. Есть вопросы?
Есть. :) Огласите, пожалуйста, ВАШИ списки - мои практически идентичны

Led ★★★☆☆
()
Ответ на: комментарий от Bauron

Bauron: "В общем-то это хорошо когда к разработке ядра не допускаются все кому не лень :)"

Каков ваш критерий отбора? В 91 году студента Линуса Торвальда вычеркиваем? Именно из-за этой глупости Столман теперь всем доказывает что система на самом деле называется GNU/Linux. Может не стоит повторять ошибок?

"Может мне кто-нибудь объяснит почему сразу после выхода нового ядра от Линуса, его тут-же патчит Кох."

Кох вбивает "почти" все патчи, Линус только те, которые считает необходимыми и правильными.

"Или Линус только новые фичи девелопит и его не волнует насколько стабильно они работают?"

Как раз наоборот, Кох ставит новые фичи, а Линуса больше волнует стабильность.

"Хорошо быть впереди планеты всей, но я думаю SMP в исполненни NetBSD (а потом портированное на остальные BSD ветки) - будет в результает эффективнее. Поживем увидим :)"

Даже если вдруг чудом будет эффективнее это ничего значить не будет. Эффективнее всего в солярисе, но что-то не видно большое количество десктопов под солярисом.

ZhekaSmith
()

2Led - из линуксового списка вычеркните sparc, и много чего остального, на чем линукс работает кое-как, а не так как должен. Останется i386 и alpha

Havoc ★★★★
()

> на чем линукс работает кое-как,

А как насчёт работы на этих платформах
NetBSD ??? что-то не попадались спарки с оной ;)
А Linux - неоднократно

anonymous
()
Ответ на: комментарий от anonymous

2wart: "Мда. Господа "пионэры", посмотрите на список плафторм, поддержиываемых NetBSD. А теперь на Линуксовый. Есть вопросы? "

Когда найдешь полный список портов Линукса, приходи, поговорим. ;) Правда, возвращайся раньше чем поймешь что его в природе нету. А то будет скучно без тебя...

"SMP никогда не было приоритетной задачей для NetBSD team. "

Ты будешь смеятся, портируемость никогда не была приоритетной задачей Линуса.

ZhekaSmith
()
Ответ на: комментарий от Havoc

2Havoc:
>из линуксового списка вычеркните sparc, и много чего остального, на
>чем линукс работает кое-как, а не так как должен. Останется i386 и
>alpha
Вы проверили оба списка и протестировали Linux и NetBSD на на всех
платформах? Я Вам завидую :)...

Led ★★★☆☆
()

А чо базар про опять КТО ЛУЧШИЙ ;)) или про SMP

anonymous
()
Ответ на: комментарий от Led

2Led: "Вы проверили оба списка и протестировали Linux и NetBSD на на всех платформах? Я Вам завидую :)..."

И даже успел портировать NetBSD на IBM'овский мейнфреймы и еще на полдюжины малодоступных платформ. Шустрый парень. ;)

ZhekaSmith
()

Интересно, а кому реально SMP надо? Может многопроцессорные системы резко подешевели, а я и не заметил? :)) Только не надо рассказывать про крутые серваки, типа Sun или SGI. Их вопервых не много, а во вторых имеются их родные операционки, в качестве которых врядли кто-то усомнится. IMHO гораздо правельнее продвигать UNIX (вобще, а не только Linux) на desktops.

anonymous
()
Ответ на: комментарий от Bauron

У Коха работа такой. А СМП в исполнении линуха вполне сносен, более того, работает стабильно (тачки молотят себе и молотят КОТОРЫЙ ГОД). А запатчить до нужного состояния или наскрябать драйвер в линухе - что пописать сходить.

anonymous
()
Ответ на: комментарий от anonymous

1. Я использую. И это актуально. Еще бы 4х процессорники стоили дешево - вообще круть настала бы. 2. Sorry, но SGI - полный отстой в плане софта системного. Параллельные компайлеры и в счет не идут. Скока ставил - всегда под возможный корень родной софт сносил и ставил гну. 3. Sun - для ценителей странного и чиста сановского.

anonymous
()
Ответ на: комментарий от anonymous

anonymous: "Интересно, а кому реально SMP надо?"

Ура. Тема по делу. Начнем с того, что на персоналки переходит множество всяких вещей с "крутых серваков". Скажем, суперскалярная архитектура процессора, векторные вычисления уже перешли. Современные ОС для персоналок являются многопользовательскими и многозадачными. Вот одна из таких вещей которые рано или поздно перейдут это SMP. Два процессора на одном кристале это будущее. Причем не очень далекое.

Как это можно использовать с полной отдачей? Один из вариантов писать компонентные программы, как KDE или Gnome десктопы. Делать множество нитей в программах, скажем в игрухе делать обработку графики, звук и AI в отдельных нитях, а для графики даже в нескольких. Есть еще вариант использования Java, один из процессоров выполняет, другой оптимизирует в native код. Для Java на самом деле все еще круче, поскольку в теории там можно распараллеливать казалось не параллельный код очень сильно, используя спекулятивное создание объектов и спекулятивное выполнение функций. К тому же любимая фраза линуксоидов - "а вы представляете как там быстро компилируется ядро".

Так вот, SMP это и настоящее и будущее. Полезная штука ;))

ZhekaSmith
()
Ответ на: комментарий от anonymous

Кому рально надо SMP?! Это тупой вопрос... Сам подумай - лучше процессору переключаться между 2 задачами или лучше чтобы 1 процессор и работал на одной задачей. Тем более есть много действительно серьезных серверов (8 процессоров и более), а не только 2-а... Причем и на x86 есть подобные вещи (>4). Даже 4 процессора - это очень хорошо. Да они постоянно дешевеют (так как новые выходят)... :-) Насчет крутых - согласен, там Linux, xBSD и тп - не являются конкурентами реальных Unix'ов. Но полностью не согласен насчет того что Unix надо продвигать на Desktop'ы. Если с таким подходом, то хотя бы BeOS какой нибудь. Но ни как не серьезные вещи и Linux (потому как он для пользователя desktop'а изначально кривой и не удобный). Unix всегда был строгим, твердым и правильным, поэтому сейчас Unix - это ОС для серверов и рабочих станций очень высокого уровня подготовки ее оператора. Я вообще против Desktop'ов в виде *nix... Пусть все остается как есть: Windows (везде кроме серверов) и Unix (только на серверах). Так меньше проблем для администратора и больше возможностей для конечного пользователя. Насчет FreeBSD и NetBSD хочу сказать, что это действительно хорошие ОС (FreeBSD правда в переди ;-). И кто с ними реально работает, ни куда переходить не будут. Linux и BSD - это очень разные вещи, но последний имеет больше плюсов и меньше минусов (доказательство: посмотрите какие крупные ресурсы стоят на FreeBSD). P.S.: И Windows тоже не говно. У кого руки прямые - у того все нормально работает. А если администратор весь день в Linux'е зависает эксперементируя и настраивая скрипты, то естественно для него Windows по определению - плохо и криво. -Direct

anonymous
()

Вот например AMD считает SMP в Linux самой лучшей и на Линуксе уже пол года ездит и показывает свой 2х процессорный Тандер... Это о чём то говорит..

WOLLE
()

Эх, что ни говорить, но до Solaris и Windows 2000 в плане SMP Linux еще расти надо :(
Но процесс идет хорошо :)
Дали бы Линусу в помощники еще пару-тройку программеров его класса и деньжат, чтобы ни о чем другом думать не нужно было, SMP в полгода, думаю был бы одним из самых лучших в природе.

Но к сожалению Линус не только ядро Linux пишет... Чем то еще по видимому в Tranmeta занимается...

На IBM вся надежда ;)

Eugeny_Balakhonov ★★
()
Ответ на: комментарий от WOLLE

W> Вот например AMD считает SMP в Linux самой лучшей и на Линуксе уже W> пол года ездит и показывает свой 2х процессорный Тандер... Это о W> чём то говорит..

Только вот у самой AMD до сих пор нету ни одного коммерческого мультипроцессорного решения. Хотя бы с 2-мя процессорами. Только инженерные сэмплы.
;-(((

И это единственное, где она пока еще не смогла обставить Intel ;)

Eugeny_Balakhonov ★★
()

"Вот например AMD считает SMP в Linux самой лучшей и на Линуксе уже пол года ездит и показывает свой 2х процессорный Тандер... Это о чём то говорит.. " Это говорит лишь о том что AMD это не серьезный процессор, хотя как и не очень правильной является архитектура x86 вообще. А тем более сервер на базе AMD - это вообще ерунда полная (даже если на сервер загрузка минимум и все самое простое). -Direct

anonymous
()

На сегодняшний день SMP hardware решения чрезвычайно дороги и я думаю,
они останутся таковыми ещё достаточно долго. Производительность же
однопроцессорных систем всё ещё далека от их предела и этот факт
также будет иметь место ещё довольно долго. Сегодня наиболее узким
местом остаётся не столько обработка, сколько передача данных. При
использовании нескольких процессоров это место станит ещё уже.
Серьёзные системы от IBM, Sun, SGI, etc. дороги не столько из-за
количества CPU, сколько из-за умения эффективно их использовать.
Эти системы сбалансированы. Кроме того у них есть родные OS
и пытаться как-то конкурировать на их поле просто смешно. Но таких
систем мало и сделаны они не для простых смертных.

По поводу desktops. Я считаю их стандартообразующей платформой в
некоторых областях технологий. Причина тривиальна - это самая
распространённая платформа. Не стоит принебрегать этим, может плохо
кончиться.

anonymous
()

Что касается десктопа, то (IMHO) там вобще не должно быть ни какой
операционки ;)
Рабочая станция она для того чтобы работать, а не для того чтобы
трахаться ;)

anonymous
()

Персональный комп без операционки!? Ну это вы уж загнули батенька. Щаз ОС даже в мобильники встраивают.

step
()

2anonymous (*) (2001-04-25 00:32:05.0):
"На сегодняшний день SMP hardware решения чрезвычайно дороги и я думаю, они останутся таковыми ещё достаточно долго."
Угу... безумно дороги... 2х процессорная системапроцентов этак на 10-20% дороже однопроцессорной с аналогичном процом. :) А прирост производительности - не менее 70%... Под нормальной ОС, с нормальным софтом разумеется...
"Производительность же однопроцессорных систем всё ещё далека от их предела и этот факт также будет иметь место ещё довольно долго."
Больше чем на порядок производительность современных процов врятли удасться увеличить - размер p-n перехода нельзя уменьшать до бесконечности... А закон Мура пока никто не отменял... так что в течении 5-10 лет в потолок упремся. Кто думает что 10 лет это очень долго, тот простите заблуждается, к тому же экономические соображения могут весьма основательно сократить этот срок.
"Сегодня наиболее узким местом остаётся не столько обработка, сколько передача данных."
В принципе ты прав... Но все не так просто... Впрочем боюсь это нас заведет в такие дебри...:)

Irsi
()

Ребята, вы что-то путаете, 2х процессорная мамка от гигабайт под сокет 370 стоит в москве 80 баксов, в то время когда CUSL2-c 110$. Так что не пищите что SMP это дорого!

chuchelo
()
Ответ на: комментарий от ZhekaSmith

>Даже если вдруг чудом будет эффективнее это ничего значить не будет.
>Эффективнее всего в солярисе, но что-то не видно большое количество десктопов под солярисом.

Десктопы редко бывают SMP ;)
А на самом деле даже в линуксе много чего из NetBSD взято.
Если неверишь, погрипай сырцы ядра на слово NetBSD.

Имхо, NetBSD - это прежде всего полигон для обкатки чего-нибудь.
И если обкатка успешна, то это что-нибудь переходит и в другие BSD и в Linux.


Havoc ★★★★
()
Ответ на: комментарий от green

> Linux on Sparc works great!
По сравнению с чем? Гнутый компилятор под спарком до сих пор не умеет 64-битные прикладухи собирать.

Havoc ★★★★
()
Ответ на: комментарий от Havoc

2Havoc: "А на самом деле даже в линуксе много чего из NetBSD взято. Если неверишь, погрипай сырцы ядра на слово NetBSD. "

Кто-то может посчитать это свидетельством крутости *BSD. На самом деле все проще, достаточно понять разницу в лицензиях. В Linux можно вставлять куски из *BSD ядер. Наоборот, нет. GPL не позволяет. Поэтому в *BSD ядрах нет слов Linux и GPL. Даже если очень захочется взять что-то из Linux ;).

"Имхо, NetBSD - это прежде всего полигон для обкатки чего-нибудь. И если обкатка успешна, то это что-нибудь переходит и в другие BSD и в Linux. "

Ну да. Это, вообще, стандартное преимущество freesource. Если что-то нужное и хорошее реализовано, это можно использовать в других проектах.

ZhekaSmith
()
Ответ на: комментарий от Havoc

2Havoc: "По сравнению с чем? Гнутый компилятор под спарком до сих пор не умеет 64-битные прикладухи собирать."

64-битные приложения на 5%-10% медленнее чем 32-х, если специально не тюнить под 64 бита. Если нет необходимости использовать большое количество памяти, то лучше компилировать на 32-бита.

ZhekaSmith
()

Какой нормальный СМП может быть на интеле (с какой угодно системой) Архитектура изначально не была сделана под него. У Sun'ов hardware смпшное так заточено (там даже специальные чипы есть, помогающие этому делу). Интел просто с..сет.

cornholio
()

Комп без операционки ?
Ну... там может нечто OS-образное внутрях и быть, но юзер не обязан
это знать и настраивать ;)

anonymous
()

>По сравнению с чем? Гнутый компилятор под спарком до сих пор не умеет 64-битные
>прикладухи собирать.

Уже может.. Вроде с прошлого года...
Но для сравнения с NetBSD это не имеет значения, - оба с GCC
живут

anonymous
()

2cornholio: >Архитектура изначально не была сделана под него.
да правда штоль? знаток ты наш... у твоего ненавистного интеля уже с 386 камней были заточки под многопроцессорность (не скажу за всю систему в целом, но, например, в системе аппаратного переключения контекстов задач были все возможности сделать SMP систему, и всякое разное, перечислять которое очень долго), а под PPro разработали спец шины/протоколы позволяющие без особых напрягов втыкать до 4 камней практически параллельно... (это при том, что была туева хуча подводных камней типа конфликтов кешей и подобных приблуд)... так шо попрошу птичку нашу не обижать (c) Матроскин

hoopoe ★★
()
Ответ на: комментарий от ZhekaSmith

>Кто-то может посчитать это свидетельством крутости *BSD. На самом деле все проще, достаточно понять разницу в лицензиях.
>В Linux можно вставлять куски из *BSD ядер. Наоборот, нет. GPL не позволяет.
>Поэтому в *BSD ядрах нет слов Linux и GPL. Даже если очень захочется взять что-то из Linux ;).

Здесь ты не совсем прав. В FreeBSD ядре в частности есть слова Linux и GPL.
Навскидку, в эмуляторе сопроцессора и в драйвере какого-то SCSI контроллера.

Havoc ★★★★
()

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

WOLLE
()

"64-битные приложения на 5%-10% медленнее чем 32-х, если специально не тюнить под 64 бита. Если нет необходимости использовать большое количество памяти, то лучше компилировать на 32-бита."
ZhekaSmith (*) (2001-04-25 12:50:53.0)

Бред полный :-) зачем тогда вообще 64 бита и 16 хватит... Если Linux нормально собирать из исходников не может (под эту платформу), то не надо говорить что так сделано - потому что так лучше. А приложения сделаные четко для 64 бита работаю гораздо быстрее 32-х битных.

---

"Вот только давайте не будет говорить, что AMD может делать только очень простые задачи :-)... В мае будет 2х процессорные системы от AMD. И как я понимаю, по скорости компиляции ядра (которое показывалось на выставке) это будет очень и очень круто"
WOLLE (*) (2001-04-25 15:48:27.0)

Именно это я и хочу сказать. Кому нужна двухпроцессорная система от AMD?! Никому, так как производительность их 2-х процессорной будет такая же как и однопроцессорной системы от Intel (возможно даже и меньше). Тем более AMD только сейчас хочет (еще не сделал...) сделать SMP систему (причем только для 2-х процессоров - смешно если честно...), в то время как Intel это уже очень давно делает (ещё со времён 486-х). P.S.: Выставка - потому и называется выставкой, из-за того что показывают почти не реальные в жизни вещи. P.P.S: А подробнее об этом ядре можно?

-Direct

anonymous
()
Ответ на: комментарий от Havoc

2Havoc: "Здесь ты не совсем прав. В FreeBSD ядре в частности есть слова Linux и GPL. Навскидку, в эмуляторе сопроцессора и в драйвере какого-то SCSI контроллера. "

Интересно... А как они обходят проблему с GPL?

ZhekaSmith
()
Ответ на: комментарий от anonymous

2Direct: "Бред полный :-) зачем тогда вообще 64 бита и 16 хватит... Если Linux нормально собирать из исходников не может (под эту платформу), то не надо говорить что так сделано - потому что так лучше. А приложения сделаные четко для 64 бита работаю гораздо быстрее 32-х битных. "

Про Линукс в этом месте ниче не знаю, и врать не буду. Соларис на UltraSPARC вполне на своем месте (заметьте что я говорю именно про UltraSPARC). А насчет 64-бит. Короче, медленнее работает. То что 64 бита дают автоматом радость это наивный, и я бы даже сказал, детский предрассудок. Почему медленнее? Этому есть аж 3 причины:

a) указатели длиннее, кэш и шины "уменьшаются" в работе с указателями в два раза ;)

б) сохранение при переключениях 64-битных регистров требует больше памяти (когда регистерный файл заканчивается)

в) большинство арфиметики 32-битное, поэтому иногда приходится обрезать 64-битное значение до 32-бит

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

ZhekaSmith
()

Еще раз о списке портов: А что Linux уже нормально работает на VAX? Или на Hitachi SuperH? Или на SGI? Ключевое слово -- нормально, а не "ура, мы boot multiuser!". Я не пытаюсь наехать на Linux или развести флейм. Меня раздражает позиция "whole world is Linux". Мол, "я не понимаю зачем нужен этот отстой", или "ну мы в натуре, самый быстро развивающийся фрюникс, а они все тормоза и отстойщики" (от anonymous'а, который, судя по слогу, сам ни капельки для этих "фрюниксов" не сделал). -- wart

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.