Вау! Круто, я и не знал, что уже есть двухпроцессорные мамы под атлон. 
Правда все это дело тетировали на маме от Tyan, а это значит,
 что купить ее простому смертному будет невозможно. 
Может Asus или Iwill выпустят такие мамы... 
Никто ничего поэтому поводу не слышал?
А вообще, машина крутая, если появится у нас в раше по доступной
 цене куплю не глядя! 8-)

Надо ждать пока Epox или на худой конес MCI начнут выпускать многопроцессорные матери под атлоны . Эти будут наверняка по доступным ценам . А Асус IMHO жирно за марку деньги снимает .. Мой EPOX чуть ли не на 150 немецко-фашистских буказоидов был дешевле асусовского аналога , притом держал все самое новое(на то время) , вроде 133 клокинга памяти , безглючной работы в AGP4 , возможности оверклокинга из биоса и многово другого ..

Чушь собачья. Ядро НЕ СОБИРАЕТСЯ в параллельном режиме. Если только одновременно собирали и модули и ядро... Но и в этом случае не было бы в ДВА раза быстрее. Брехня.

>Чушь собачья. Ядро НЕ СОБИРАЕТСЯ в параллельном режиме. Если только >одновременно собирали и модули и ядро... Но и в этом случае не было >бы в ДВА раза быстрее. Брехня.
любая программа может компилироваться в параллельном режиме:
make -j 4
я этой опцией постоянно пользуюсь на своем 4х Xeon,
ну а сборка из объектников конечного файла идет на 1 процессоре,
но это не лимитирующаяя стадия. Время компиляции и оптимизации
исходников намного больше.
:) .

> А Асус IMHO жирно за марку деньги снимает

Суди сам, на моих тестах ASUS A7V 1Ghz Athlon собирает ядро с модулями
менее чем за 4 минуты.

2foreigner: что не о чём не говорит. Ядро ядру рознь , а говорить что твой Асус собирает ядро быстрее ... ( и тихо смотреть на сборку ядра 1.x.x =) )

А какой блок питания надо на 2-каменный атлоновый комп?
Ватт на 500? Ж:-))
Тогда и калорифер в доме не нужен будет Ж:-))
Думаю, производители блоков питания будут очень рады этой новинке.

Что-то и вправду долгонько Атлон собирал ядро... Не спорю, что в 2.4-й ветке ядро БОЛЬШОЕ стало ;-), но мой 2*PII-300 2.2.17-е ядро собирал порядка 2-3 минут... Причём - с 9-м уровнем оптимизации. Но стояло "make -j 10" ;-).
Кароче, чем больше у make цифирка, тем лучше!!! ;-) Кто-нибудь пробовал "make -j n" (так, вроде?) ставить? ;-) Вот тогда вообще ВЕСЕЛО получается... Главное, чтобы памяти хватило... А то падает... ;-)

2anonymous (*) (2001-02-02 03:28:09.0):
Сразу видно, что многопроцессорных систем под Linux ты не видел... Да и вообще про архитектуру {567}x86 у тебя представления, мягко скажем, неполные. Я тебе вот что скажу: ЛЮБОЙ проц класса Pentium или выше сам по себе, фактически, "двухпроцессорный" - ибо имеет два конвейера "сборки" результатов вычислений (впрочем, достаточно ограниченно...). Короче, факт в том, что команды типа "inc", "dec" и т. д. могут выполнятся 2 штуки за такт на одном процессоре и именно поэтому тест BogoMIPS показывает значение, в два раза большее суммарной частоты всех имеющихся в наличии процессоров - она как раз такими командами и считает... ;-)
Так что вопли по поводу "она не может компилить", "она не знает" и т. д. оставь, пожалуйста, для своей бабушки и для подружки. А ещё - для кретинов типа Irsi, VSL, Ogr & Co.

::ЛЮБОЙ проц класса Pentium или выше сам по себе, фактически, "двухпроцессорный"

Вы видимо слегка заблуждаетесь. Pentinum вполне "однопроцессорен" ;o). А вот PII, да. Фактически PII = PPro + MMX + (16bit optimised).

Полностью солидарен с ROOT!

2Rabbit: Ты ещё про FPU забыл...
Млин, какие же вы тупицы... Отослать вас в тот же ComputerWorld за 96-й год, что ли? Или напрямик в /usr/doc/Linux-mini-HOWTOs/BogoMips??? ;-) Достало уже кричать: УЖ КОЛИ НЕ ЗНАЕТЕ, ТАК УЗНАЙТЕ СНАЧАЛА, А ПОТОМ УЖ ВОПИТЕ!!!

2Spy: THX.

Я только одного не пойму: как у них от второго процессора получается прирост быстродействия в два с половиной раза? Т.е. получается что: 1) на одном процессоре все компилировалось с -j1, а на двухпроуцессорной, ну, с большим значением; 2) ядро имеет серьезные проблемы с производительностью в однопроцессорной конфигурации; 3) и то и другое. Ни один из перечисленных вариантов не выглядит симпатичным.

2Stephen: А вот это - чёрт его знает. Я 2.4.х-е ядро пока что не пробовал. И Атлоны - тоже. Там же многое может быть... Типа:
1) Ошибки в AMD-шном SMP.
2) Недостаточная документированность SMP "от AMD" => недостаточная поддержка ядром 2.4.х.
3) Ошибки в ядре.
4) Ошибки в ядерных конфигах.
5) Ошибки в подходе к тестированию: 1-е ядро, скажем, компилили на 2.4.0 (или использовали "стандартное"), а второй тест уже был на "собранном" в предыдущий раз 2.4.1 двухпроцессорном ядре... Вот и получается такой дикий прирост производительности только за счёт "ненаучного" подхода к тестированию. Хотя удивляться нечему - сплошь и рядом такие "тесты" вылазиют.

CВПТЛБ СДТБ ТБУРБТБММЕМЙЧБЕФУС РТПУФП ЛМБУУОП. чУЕ ЪБЧЙУЙФ ПФ ФПЗП ЛБЛПЕ НЕУФП Ч УЙУФЕНЕ СЧМСЕФУС "ХЪЛЙН". с ЪБРХУЛБМ make -j (ЙНЕООП ФБЛ, ВЕЪП ЧУСЛЙИ ФБН 4 ЙМЙ 8 ;) ОБ 2xP3-800/1G/... - РПМХЮБМПУШ ВЩУФТЕЕ Ч ЫЕУФШ (!) ТБЪ. оП ЬФП ЗПЧПТЙФ ОЕ П ТЕБМЙЪБГЙЙ SMP, Б П ОЕУВБММБОУЙТПЧБООПУФЙ УЙУФЕНЩ: ЦЕУФЛЙК ДЙУЛ ИПФШ Й UW SCSI-3, ОП ОЕ РПУРЕЧБЕФ ЪБ РТПГПН. б РТЙ make -j - c ДЙУЛБ ЮЙФБЕФ ЛХЮБ РТПГЕУУПЧ, ЧЩЦЙНБС ЙЪ ДЙУЛПЧПК РПДУЙУФЕНЩ ЧУЕ. лУФБФЙ, ЧПЧУЕ ОЕПВСЪБФЕМШОП ЙНЕФШ ЗЙЗ ПРЕТБФЙЧЛЙ ДМС make -j - ВПМШЫЕ ЮЕН 560M НОЕ ЪБОСФШ ОЕ ХДБМПУШ. лУФБФЙ, ОБ ПДОП РТПГПЧЩИ НБЫЙОЛБИ make -j ФПЦЕ НПЦЕФ ТБВПФБФШ ВЩУФТЕЕ, РП ФПК ЦЕ РТЙЮЙОЕ. оБ НПЕК ТБВ.УФБОГЙЙ (1xAthlon 900/256/...) make -j 6 ТБВПФБЕФ ФПЦЕ УХЭЕУФЧЕООП ВЩУФТЕЕ (ФХФ ВПМШЫЕ ЮЕН 6 С ОЕ РТПВПЧБМ - ПРЕТБФЙЛЙ НБМПЧБФП).

Damned links, why does it do it? Sorry.

это links кривой

кто хочет знать как что работает на x86 от пня и выше --- могу
посоветовать дельное руководство: www.agner.org/assem
все просто и понятно, особенно после странных интеловских док.

для прикола попробовал скомпилить 2.4.1 на 2xPIII 500MHz. получил 7м7сек для make -j 1, 4м45сек для make -j 2, и 3м42сек для make -j 4.

Нда, опять при добавлении второго проца производительность возрастает более чем в ДВА раза...:) Давно я так не смеялся...:))) А подумать не пробовали? :)

где ты увидел у меня БОЛЕЕ, чем в два раза? чуть меньше, чем в два раза, в моем случае.. это не 142%

4:51 = 291/120 = 2.425 раза. bc врет ?

Любителям links

Кстати, по листу рассылки links пришел патч by Walery Studennikov к links 0.95, который исправляет досадный баг с кодировкой. Если сильно нужен, пишите мне на velinor@aport.ru (URL я не нашел)

2velinor: да выложил бы сам где-нибуть... а то заколебешся всем желающим отправлять...:)

P.S. А там патча чтоб xon/xoff понимал не появилось? А то приходится свой терминал на 9600 из-за него зажимать...:(
А уж как эта эпопея с HTTP Auth достала...:(

На счет ускорения в более чем в 2 раза (кстати говоря, Irsi прав - это ошибка. есть закон Адмала S<=1/(f+(1-f)/n)), S-ускорение, n-число процессоров etc) - никому не приходило в голову что просто система на одном процессоре тормозила? Никто с линуксом на Athlon 1.2 однопроцессорном не работал? Может там глюки какие есть?

links patch

Irsi, нда, пожалуй.
http://velinor.virtualave.net/links-0.95-forms-charset.patch.tar.gz
Кстати, Irsi, по-подробнее о проблеме xon/xoff, plz.
HTTP Auth будет в скором времени

Господа, внимательно читайте условие задачи, а потом уже делайте выводы.
Для умственно-отсталого Irsi это еще простительно, а для остальных нет.
Сразу скажу, что тест бесусловно глупый, но результаты его вполне доказуемы.

Итак, по условию имелась машина с
1) двухпроцессорной платой
2) двумя процессорами (и в первом и во втором тесте)
3) SMP-ядром (опять же и в первом и во втором тесте)
4) 256 Мб памяти (важный фактор)
5) оба процессора 1.2 Ghz (важный фактор)

Тесты проводились один за другим без перезагрузки, но с промежуточным `make clean'.
Памяти достаточно, и много полезных вещей оказывается в кеше, что уже гарантирует
более быстрый второй проход даже на одном процессоре. Это раз.

Далее, первый делал `make bzImage', второй следом - `make -j3' bzImage.
Сразу вопрос: процессоров два, а количество jobs указывается три. Почему не два?
Что дает этот дополнительный job? Правильно, при `make bzImage' загрузка
процессора была отнюдь не 100%, поскольку все объекты собирались последовательно,
и довольно большое суммарное время мощный процессор простаивал, ожидая диск.
А вот `make -j3' мог загрузить два процессора гораздо лучше, так как количество
простоев заметно уменьшалось.

кстати, make -j <n>, где n больше 4, ускорения уже не вызывает.. если меньше - то да, есть эффект. заметьте, что у меня ускорилось ровно в 2 раза.. и кроме того, я перекомпилировал несколько раз, чтобы закэшировалось :)

2foreigner: похоже на правду... делаем вывод - это некорректный тест, ничего не говорящий об реальной эффективности поддержки SMP в ядре 2.4...:)

2velinor: да все просто... links ничего не знает про xon/xoff и посему если скорость терминала установит >9600, то терминал не успевает обрабатывать поступающий поток, говорит линксу "погодь немного", линкс игнорирует это и продолжает вывод... в результате - на экране "мусор"...
При скорости <=9600 терминал справляется с потоком, но все же изредка немного мусора возникает... Да и медленно это...:(
Да, терминал нормальный - DEC VT420... Кабель - тоже ибо на скорости 38400 все программы работают нормально, кроме линкса... Впрочем если в pine отключить распознование xon/xoff, то картина выходит абсолютно аналогичная случаю с links...

2Irsi: Млин, мудозвон! Да ты головкой своей от пиписьки хотя бы подумай малёк, да заодно почитай на досуге (после того, как подрочишь, прыщавый ты наш!) такие вещи, как архитектура шины у Атлонов или Деков (одного поля ягодки). Далее, смотрим там такую вещь, как отсутствие простоя шины при занятом устройстве ввода-вывода (то бишь то, что называется "пакетной шиной передачи данных"). А вот тут уже СОВСЕМ другая песенка получается. И вызывает удивление, что он, при увеличении числа процессоров, не показывает прирост производительности в ДЕСЯТКИ раз.
Например: один проц ожидает от контроллера IDE пакетик данных, а в это время НИЧТО не мешает 2-му процессору мучать ОЗУ или контроллер SCSI - шина-то не занята... А если вспомнить, что ОЗУ работает в несколько сот раз быстрее винта... Это, ессно, примерчик простенький - специально для таких тупоголовых индивидов типа тебя. На самом деле, всё, конечно, гораздо сложнее.
Так что вопли по поводу "SMP убогое" оставьте для подружек, а господину Адмалу вставьте в задницу его глиняную табличку с этим самым законом. Надо учитывать, что прогресс на месте не стоит.

2Foreigner: Частично согласен. Но не согласен с 3-мя вещами:
1. Тест, всё-таки, надо было проводит с одинаковыми параметрами make - причём, желательно j>8.
2. ДАЛЕКО не факт, что в памяти много чего осталось - gcc память ЛЮБИТ - ему память "по жизни" хочется чем больше, тем лучше. Так что вероятность того, что что-то осталось в ней полезное стремится к нулю.
3. Тест с однопроцессорной конфигурацией надо было проводить на однопроцессорном ядре - это ближе к истине. ;-)

2ALL: Кстати, об Адмале: его теория описывает ПРОИЗВОДИТЕЛЬНОСТЬ системы, а не скорость выполнения конкретных задач. То бишь, можно сказать, примерное значение суммарной BogoMIPS, при увеличении числа процессоров... ;-) Даже ежу Irsi должно быть понятно, что эта цифирка ну ОЧЕНЬ далека от тех задач, которые компьютеру приходится выполнять в офисе/дома. Как обычно, "теорема ни о чём"... ;-)

Ну просто душа радуется. Особенно про табличку в задницу понравилось. :) Вот за это и люблю этот сайт. Тут сектанты в одном штате через суд отменили законы термодинамики ибо они с их устоями не согласуются. Прогресс однозначно на месте не стоит. :-)

2shuras: этож рут - заслуженный клоун LOR...:))

2Irsi: Уёжище, а слабо показалось что-то дельное ответить? Ты, мудак, ДУМАЙ, чего пишешь сначала, а потом уж выёживайся! Знаете, как вы, выродки, в пробирке недоношенные, ДОСТАЛИ своей куетой??? RTFM, RTFM и ещё раз RTFM. А потом уж пытайтесь пальчики ваши кривые выпрямить козьей мордочкой.