https://opennet.ru/openforum/vsluhforumID3/39131.html В статье "Intel Core 2 "Penryn" Performance under Linux (http://www.linuxhardware.org/article.pl?sid=07/11/21/152234)" представлены результаты тестирования производительности различных Linux операций на машине с новым четырехядерным процессором Intel Core 2 "Penryn".<br><br><br>Среди тестов: сборка GlibC 2.5, кодирование аудио и видео, рендеринг 3D сцен, производительность игр Quake 3 и Enemy Territory, оценка энергопотребления. <br><br><br>В CPU Intel Core 2 "Penryn" реализовано (http://www.linuxhardware.org/article.pl?sid=07/11/15/2015212&mode=thread) около 50 новых инструкций SSE4. Новые инструкции можно разделить на две категории - мультимедиа акселерация (для обработки графики и видео, 2-D и 3-D преобразований) и обработка тестовых данных (оптимизация поиска, выделения сигнатур, операций по сжатию данных). Кроме того реализовано два новых энергосберегающих режима: "Deep Power Down Technology" и "Enhanced Intel Dynamic Acceleration Technology"<br><br>URL: http://www.linuxhardware.org/article.pl?sid=07/11/21/152234<br>Новость https://opennet.ru/openforum/vsluhforumID3/39131.html#55 Mon, 03 Dec 2007 12:03:44 GMT косвенно, но верно<br> https://opennet.ru/openforum/vsluhforumID3/39131.html#54 Mon, 03 Dec 2007 11:51:15 GMT &gt;откуда уверенность, что порт glibc допускает сборку с кастомными -j флагами? <br>&gt;вон gcc ложит на это дело и немало портов еще. <br>&gt;<br>&gt;Лучьше на примере ядра с дефолтным конфигом. Там точно -j работает как <br>&gt;сам задашь <br><br>судя по тому что -j1 работает в полтора раза дольше оптимизация есть<br> https://opennet.ru/openforum/vsluhforumID3/39131.html#53 Fri, 30 Nov 2007 22:23:22 GMT &gt;&gt; А я Висту поставил :) <br>&gt;<br>&gt;в wine'е ? :) <br><br>АААА<br>порвал! %))))<br><br>5!<br> https://opennet.ru/openforum/vsluhforumID3/39131.html#52 Fri, 30 Nov 2007 21:52:16 GMT &gt; А я Висту поставил :) <br><br>в wine'е ? :)<br> https://opennet.ru/openforum/vsluhforumID3/39131.html#51 Thu, 29 Nov 2007 18:06:11 GMT откуда уверенность, что порт glibc допускает сборку с кастомными -j флагами?<br>вон gcc ложит на это дело и немало портов еще.<br><br>Лучьше на примере ядра с дефолтным конфигом. Там точно -j работает как сам задашь<br> https://opennet.ru/openforum/vsluhforumID3/39131.html#50 Thu, 29 Nov 2007 18:01:10 GMT &gt;Я конечно могу сильно ошибаться...<br><br>ошибаешься и сильно.<br><br>Смотри ман того же gcc...<br> https://opennet.ru/openforum/vsluhforumID3/39131.html#49 Thu, 29 Nov 2007 14:10:23 GMT В рамках объективности я проверил, на моем двуядерном pentium D 2.8GHz по 1Mb кеша разница во времени при компиляции glibc-2.6.1 при опциях -j(2-4) менее 0.25%, причем не в чью конкретно пользу. запускал тесты по 2 раза на каждую цифру. Данную разницу можно отнести к погрешности.<br>точные замеры:<br><br>-j1 32:07.473<br>-j2 21:41.745, 21:40.368<br>-j3 21:40.793, 21:34.205<br>-j4 21:25.758, 21:35.959<br><br>сразу говорю что в ручну не собирал, а пользовался командой <br> emerge glibc<br>так что часть времени тратилась ра распаковку сорсов, конфигурацию и установку скомпилиного продукта. перед тестом все программы по возможности выключил, даже иксы.<br><br>конечно интереснее было бы проверить на большем количестве процессоров, но это у меня наверное только через пару месяцев появиться...<br> https://opennet.ru/openforum/vsluhforumID3/39131.html#48 Thu, 29 Nov 2007 13:00:18 GMT http://www.anandtech.com/IT/showdoc.aspx?i=3162&p=1<br> https://opennet.ru/openforum/vsluhforumID3/39131.html#47 Thu, 29 Nov 2007 12:22:14 GMT &gt;&gt;Нет. До сих пор правило N+1 работает хорошо, потому как запасной <br>&gt;&gt;процесс именно на I/O и подскакивает своё отработать.<br>&gt;Даже если речь идет о каком-нить Dual Xeon'е, где, собсно 2 чесных <br>&gt;проца, <br><br>Это в смысле Katmai какие? Ну вот стоит Quad на площадке, один из тех, о ком речь. В т.ч. занимается сборкой (точнее, года полтора назад ещё активно занимался, сейчас скорее изредка).<br><br>&gt;а два так, поржать (HT)<br><br>Это в P4-based... и именно что поржать, учесть их толком не получается -- где чуточку лучше, где на треть хуже.<br><br>&gt;то даже в таком случае CPUs+2 будет более оптимальной формулой, <br>&gt;чем CPUs+1. 2*CPUs - это именно на честных сабжах. <br><br>Простите, но на нечестных можно только гадать.<br><br>&gt;&gt;Вы предлагаете то, что склонно приводить к scheduler thrashing -- оверхед <br>&gt;&gt;на переключение начинает быть заметен.<br>&gt;Потери переключений/потери кеша ничто в сравнении с простоем проца и (уж тем <br>&gt;более!) винта.<br><br>Да, но если затыков в I/O особенных нет (при той же сборке это типично -- надо чем-то выжрать в