| |
| |
| |
| |
| 5.97, Aquarius (ok), 08:57, 03/10/2010 [^] [^^] [^^^] [ответить]
| +5 +/– |
 > а то. зайдите на сайт и прочитайте.
то что они от блокировок принялись избавляться сразу после форка и сейчас, скорее всего, избавились совсем? так это я и без их сайта знаю
а нельзя просто прямо ответить на прямо заданный вопрос?
| | |
| |
| 6.173, www2 (??), 15:19, 12/10/2010 [^] [^^] [^^^] [ответить] | +/– | А в DragonFly принята несколько другая парадигма многопроцессорной системы Там ... большой текст свёрнут, показать | | |
|
|
|
|
|
| |
| 2.95, Vkni (?), 08:23, 03/10/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Результаты исследования: http://pdos.csail.mit.edu/papers/linux:osdi10.pdf
Мать, мать, мать! Читаю аннотацию (Abstract):
Except for gmake, all applications trigger
scalability bottlenecks inside a recent Linux kernel. Using
mostly standard parallel programming techniques—
this paper introduces one new technique, sloppy counters—
these bottlenecks can be removed from the kernel
or avoided by changing the applications slightly. Modifying
the kernel required in total 3002 lines of code changes.
И вывод:
A speculative conclusion from this analysis is that there
is no scalability reason to give up on traditional operating
system organizations just yet.
Т.е. "Бобёр, выдыхай".
| | |
|
| |
| |
| |
| 4.154, User294 (ok), 05:38, 05/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
 > Да, линукс полное г по сравнению с планом, по мнению "спицалистов" его
> курить нельзя.
Крутой велосипед с турбонаддувом. Правда на улицах почему-то попадаются менее крутые концепты обычно. Да, не всем дано понять круть турбонаддува в велосипеде. Велосипеды без турбонаддува - сакс.
| | |
| |
| 5.163, fr0ster (ok), 08:17, 05/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
 >> Да, линукс полное г по сравнению с планом, по мнению "спицалистов" его
>> курить нельзя.
> Крутой велосипед с турбонаддувом. Правда на улицах почему-то попадаются менее крутые концепты
> обычно. Да, не всем дано понять круть турбонаддува в велосипеде. Велосипеды
> без турбонаддува - сакс.
Вы нехороший человек, я теперь от любопытства помру, пытаясь понять, куда же именно турбонаддув велосипедисту вставляется.
| | |
|
|
|
|
| 1.5, аноним (?), 16:30, 02/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
А как же работали 1024-ядерные системы покойной SGI?
И все ядра под одной копией linux!
| | |
| |
| |
| 3.61, StrangeAttractor (ok), 21:40, 02/10/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > 1024-ядерные или 1024 процессорные?
Кстати, а какая разница? Правда интересно. Мне ясно только что при отдельных процах получается кэша больше.
| | |
| |
| 4.67, DmitryINdig0 (ok), 22:54, 02/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
 суперкомпьютеры сильны, когда каждая нода выполняет свою часть задачи. А потом все решения надо объединить. Помнится на Пентиум3 в МГУ строился вычислительный кластер, и много денег потратили на сеть, что бы задержки и коллизии исключить, которые бывают в распространенном езернете. Там какой-то "хитрый" езернет был.
Сейчас я японии строить собираются 10Тфлопный суперписюк ) Так там как раз одна из особенностей, это новый подход к сети кластера.
Или же еще пример. Применение шейдеров видеокарты для вычисления - хорошая идея, но задачу надо разбить правильно и главное что бы под "размер" шейдера. Затем на выходе собрать результат.
Вот так я понимаю.
| | |
| |
| 5.69, админ (?), 23:33, 02/10/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>суперкомпьютеры сильны, когда каждая нода выполняет свою часть задачи.
а при чём тут ноды?
был задан конкретный вопрос.
зы:
ядра почти не отличаются от выделенных камней. иногда просто некоторые ресурсы бывают общими - кэш, фпу и т.д.
| | |
| |
| 6.124, Аноним (-), 19:46, 03/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
Это только если абстрагироваться что скорость и задержки в канале связи на кристале и на плате - это совсем разные вещи :)
| | |
| |
| 7.152, yet another anonim (?), 05:27, 05/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
Какую плату вы имеете ввиду? Данные между физически связанными ядрами вполне радостно гуляют внутри чипа, с частотой, явно большей, чем та, что между отдельными процами, избегая всяких прочих плат, и, соотв., с задержкой меньшей. Платы в таком случае лишь получают уже готовые обработанные вещи и посылают новые данные для обработки.
| | |
|
|
|
|
|
| 2.22, User294 (ok), 19:30, 02/10/2010 [^] [^^] [^^^] [ответить]
| –20 +/– | |
> А как же работали 1024-ядерные системы покойной SGI?
А еще вон в топ500 почему-то куча линукса. А если то что говорят фрукты из MIT правда - ну допилят ядро, куда ж они денутся? :) Может парни из MIT себе грант на "принципиально новую ОС" хотят выбить?
| | |
| |
| 3.28, Аноним (-), 19:43, 02/10/2010 [^] [^^] [^^^] [ответить]
| +3 +/– |
Кластер и супер-мультиядерность на одном чипе - несколько разные вещи.
| | |
| |
| 4.35, User294 (ok), 19:59, 02/10/2010 [^] [^^] [^^^] [ответить]
| –14 +/– | |
> Кластер и супер-мультиядерность на одном чипе - несколько разные вещи.
Однозначно. Правда насчет того что супер-мультиядерность вообще перспективна - это большой вопрос. Где Kilocore от IBM, например? А то там 1024 ядра чтоли обещали, или около того. У многоядерников есть проблема: если задача не параллелится (а параллелится не любая задача), все упирается в скорость 1 ядра а остальные ничего не делают. При этом чем круче отдельное ядро (и чем их меньше умещается, соответственно) тем лучше работает 1-поточная задача. Ну вот интели и амд всякие нынче для борьбы с этим жутко изгаляются. Делая всякие TurboCore и что там еще (ака разгон 1 ядра при неактивных остальных).
| | |
| |
| 5.70, админ (?), 23:36, 02/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
кстати согласен - без правильного распараллеливания задачи фиг что получится.
сейчас на смп проще считать так - одна задача, один проц.
| | |
| |
| 6.155, User294 (ok), 05:43, 05/10/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> кстати согласен - без правильного распараллеливания задачи фиг что получится.
А некоторые задачи как-то так изначально последовательные и не очень то хотят параллелиться по природе своей. Собственно этот простой и обидный факт и является основной проблемой многоядерников, из-за которых процы с уймой относительно слабых ядер так и не пошли в массы.
| | |
| |
| 7.164, fr0ster (ok), 08:18, 05/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
> является основной проблемой многоядерников, из-за которых процы с уймой относительно слабых
> ядер так и не пошли в массы.
Не совсем так, видяхи те же узкоспециализированные компы, а какая массовость?
| | |
|
|
|
|
| 3.52, Аноним (-), 20:59, 02/10/2010 [^] [^^] [^^^] [ответить]
| +/– | |
Мисье все знайка - доведу до твоего сведения - в TOP500 нет не одной машины с количеством ядер на одной ноде выше 32х. Ноды обмениваются между собой или через shared memory (mmap большого файла) или через MPI. ТОЧКА.
То как linux kernel пытались запускать на SGI Altrix - это отдельная и грустная история - он там просто не работал, ибо инициализация 512 ядер занимала дохрена времени и накладные расходы вобщем-то тоже.
Линукс на машинах Cray XT[3-5], IBM BG/L сводится к одной вещи - запускалка процессов.
Единственное серьезное использование это service node - там еще +/- похожее на привычное окружение.
Надеяться что ядро "допилят" не стоит - много ли допиливаний под Cray вернулось в ядро?
А BG/L specific ?
| | |
| |
| 4.55, User294 (ok), 21:19, 02/10/2010 [^] [^^] [^^^] [ответить]
| –23 +/– | |
> много ли допиливаний под Cray вернулось в ядро?
Вы хотите сказать что вон та орава ядерщиков не сможет так же? При том их главный финноамериканец это самое ядро с нуля написал? Прикольно, да :)
> Надеяться что ядро "допилят" не стоит
Да что вы так нервничаете? Время покажет. Будут 48-ядерные процы майнстримом - тогда и увидим все.
Я думаю что если кастомеры начнут теребить редхатов, ораклей, айбиэмов и прочих - они быстренько допилят, никуда не денутся. А что, у них еще и выбор будет? :)
| | |
| |
| 5.78, Аноним (-), 00:11, 03/10/2010 [^] [^^] [^^^] [ответить] | +1 +/– | Не сможет Один он ну ты наивный малый почитаешь на lwn net кто вкладывает ... большой текст свёрнут, показать | | |
| |
| 6.98, Аноним (-), 09:40, 03/10/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
>>> много ли допиливаний под Cray вернулось в ядро?
>> Вы хотите сказать что вон та орава ядерщиков не сможет так же?
>Не сможет.
Сможет.
| | |
| |
| 7.112, fr0ster (ok), 15:18, 03/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>>> много ли допиливаний под Cray вернулось в ядро?
>>> Вы хотите сказать что вон та орава ядерщиков не сможет так же?
>>Не сможет.
> Сможет.
Вначале посчитает, сколько на это надо бабок и пошлет затею лесом, пока широкого употребления многоядерных систем не будет.
| | |
|
| 6.148, User294 (ok), 17:13, 04/10/2010 [^] [^^] [^^^] [ответить] | +/– | Да бросьте, там собралась такая куча ориентированных не на процесс и теоретическ... большой текст свёрнут, показать | | |
|
|
| 4.68, zuborg (?), 23:25, 02/10/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Ноды обмениваются между собой или через shared memory (mmap большого файла)
Ещё один всезнайка нашелся. И чем же мемори расшаривается ? Сокет планки памяти запаян на материнки обоих нод ? Или изменения в файле через NFS синхронизируются ?
Короче, слыхал звон, да не знал где он...
| | |
| |
| 5.75, Аноним (-), 00:05, 03/10/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Или изменения в файле через NFS синхронизируются ?
Если для вас сетевые FS заканчиваются NFS - мне вас очень жаль.
lustre | GPFS + mmaped file - вполне себе схема shared memory.
DLM обеспечит когентность кэшей на всех нодах.
| | |
| |
| 6.80, Аноним (-), 00:27, 03/10/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ах да, забыл.
вокруг этого mmap file, накручивают стопку MPI_barrier что бы синхронизировать доступ.
а за одно советую чутку заглянуть в google по словам "MPI shared memory mmap"
узнаете много нового для себя, и перестанете кичиться своим невежеством.
| | |
| |
| 7.85, аноним (?), 01:04, 03/10/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
> а за одно советую чутку заглянуть в google по словам "MPI shared
> memory mmap"
> узнаете много нового для себя, и перестанете кичиться своим невежеством.
Вы бы язык-то прикусили, да почитали бы о том, о чем несете абсолютный бред, ни хрена не понимая как оно работает.
| | |
| |
| 8.86, Аноним (-), 01:39, 03/10/2010 [^] [^^] [^^^] [ответить] | –3 +/– | Да да расскажи мне убогому как оно работает Как DLM поддерживает когентност... текст свёрнут, показать | | |
|
|
| 6.105, zuborg (?), 13:53, 03/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Ноды обмениваются между собой или через shared memory (mmap большого файла)
>...
>GPFS + mmaped file - вполне себе схема shared memory
Итак, подытожим, ноды суперкомпа обмениваются между собой информацией используя сетевые файловые системы (такие как GPFS) через замечательный IPC механизм shared memory, который по определению работает в пределах одной машины (т.к. память, хранящаяся в состоянии одного и того же блока транзиторов в конкретном чипе памяти может быть отображена в адресное пространство нескольких процессов только в пределах той машины, на которой эти процессы исполняются)
Вы у Петросяна помощником не работаете ?
| | |
| |
| 7.118, Аноним (-), 17:36, 03/10/2010 [^] [^^] [^^^] [ответить] | +2 +/– | LOL вы где учились юноша shared memory - не исчерпывается только System V IPC... большой текст свёрнут, показать | | |
| 7.119, Аноним (-), 17:42, 03/10/2010 [^] [^^] [^^^] [ответить]
| +1 +/– | |
за одно стоит прочитать определение
http://en.wikipedia.org/wiki/Shared_memory
что бы в очередной раз не слыть невеждой и мне в очередной раз жаль что понятие shared memory для вас закончилось на System V IPC, а понятия файловых систем - на NFS который не имеет никакого distributed lock manager.
| | |
| |
| 8.122, zuborg (?), 18:21, 03/10/2010 [^] [^^] [^^^] [ответить] | +1 +/– | цитирую In computer hardware, shared memory refers to a typically large block... большой текст свёрнут, показать | | |
| |
| 9.125, Аноним (-), 19:56, 03/10/2010 [^] [^^] [^^^] [ответить] | +/– | читаем еще раз но не между строк In software In computer software, shared memor... большой текст свёрнут, показать | | |
| |
| 10.126, zuborg (?), 20:51, 03/10/2010 [^] [^^] [^^^] [ответить] | +/– | Перевожу метод сохранения обьема памяти через перенаправления доступа к тому, ч... большой текст свёрнут, показать | | |
| |
| 11.136, Аноним (-), 08:48, 04/10/2010 [^] [^^] [^^^] [ответить] | +/– | Сознательно игнорируете первую строчку определения данного wiki a method of int... большой текст свёрнут, показать | | |
| |
| 12.146, zuborg (?), 13:25, 04/10/2010 [^] [^^] [^^^] [ответить] | +/– | повторюсь в который раз - процесс на второй ноде НЕ может получить доступ к are... большой текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 4.71, админ (?), 23:40, 02/10/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Мисье все знайка - доведу до твоего сведения - в TOP500 нет не одной машины с количеством ядер на одной ноде выше 32х.
32 - уже не хило.
совсем до 48 не далеко. пока одни помои льют, время идёт и другие работают.
>Линукс на машинах Cray XT[3-5], IBM BG/L сводится к одной вещи - запускалка процессов.
на моём ноуте - тоже.
| | |
| |
| 5.76, Аноним (-), 00:07, 03/10/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
>>Мисье все знайка - доведу до твоего сведения - в TOP500 нет не одной машины с количеством ядер на одной ноде выше 32х.
> 32 - уже не хило.
16 или 32 был только в BG/L. Но там далеко не SMP, а POWER[5|6] + NUMA.
> совсем до 48 не далеко. пока одни помои льют, время идёт и
> другие работают.
>>Линукс на машинах Cray XT[3-5], IBM BG/L сводится к одной вещи - запускалка процессов.
> на моём ноуте - тоже.
Да ну? что бы запустить 1 процесс который будет по сети работать ?:)
| | |
| |
| 6.82, аноним (?), 00:38, 03/10/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>16 или 32 был только в BG/L. Но там далеко не SMP, а POWER[5|6] + NUMA.
ха! это что-то меняет?
>Да ну?
ну да.
>что бы запустить 1 процесс который будет по сети работать ?:)
угу. браузер. как в твоём случае.
чтобы скопировать с вики ничего не доказывающую информацию.
| | |
| |
| 7.87, Аноним (-), 01:40, 03/10/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
>>16 или 32 был только в BG/L. Но там далеко не SMP, а POWER[5|6] + NUMA.
> ха! это что-то меняет?
Очень многое.
| | |
| |
| |
| 9.89, Аноним (-), 02:01, 03/10/2010 [^] [^^] [^^^] [ответить] | –1 +/– | Если не понимаете то точно в сад - учиться различия в подходах к SMP и NUMA я... текст свёрнут, показать | | |
|
|
|
|
|
| 4.91, Алексей (??), 04:08, 03/10/2010 [^] [^^] [^^^] [ответить] | +/– | Всезнайка наверное не читал pdf по ссылке в новости А ведь стоило бы Чтобы н... большой текст свёрнут, показать | | |
| 4.127, Аноним. (?), 23:47, 03/10/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Мисье все знайка - доведу до твоего сведения - в TOP500 нет не одной машины с количеством ядер на одной ноде выше 32х.
http://top500.org/system/8385 Ранее в списке был Росгидромет, где было более 32 ядер.
>То как linux kernel пытались запускать на SGI Altrix - это отдельная и грустная история - он там просто не работал, ибо инициализация 512 ядер занимала дохрена времени и накладные расходы вобщем-то тоже.
Работал, работает и будет работать... не надо врать... И времени эта "инициализация" занимала не много.... и даже на 1024 ядрах.
>Линукс на машинах Cray XT[3-5], IBM BG/L сводится к одной вещи - запускалка процессов.
А что оно ещё должно делать?? Угадывать, что вы хотите посчитать и сразу выдавать результат???
| | |
| |
| 5.139, Аноним (-), 09:02, 04/10/2010 [^] [^^] [^^^] [ответить] | +/– | Что хотели то сказать ссылкой на Altrix Он есть и в Oak ridge - там где TOP1 ст... большой текст свёрнут, показать | | |
| |
| 6.147, Аноним. (?), 14:05, 04/10/2010 [^] [^^] [^^^] [ответить] | +/– | Вы сказали, что в списке нет - я вам показал, что есть Наверное потому, что тех... большой текст свёрнут, показать | | |
|
|
|
|
|
| 1.6, pro100master (ok), 16:34, 02/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 ну, имхо, в 48-ядерных в любом случае эффективность будет низкая: объём кэша не резиновый, а память и шина тормоза.
| | |
| |
| 2.12, Карбофос (ok), 17:16, 02/10/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
 там, в принципе, выход только один: уменьшить разницу между характеристиками кэша и внешней памятью
| | |
| 2.26, User294 (ok), 19:37, 02/10/2010 [^] [^^] [^^^] [ответить] | –6 +/– | Придется хреначить кучу каналов памяти до тех пор пока не задолбутся разводить ... большой текст свёрнут, показать | | |
| |
| 3.34, Аноним123321 (ok), 19:56, 02/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
 >... и кушать электричество.
на самом деле нет.
вы никогда не задумывались почему темпиратура процессора зависит от того делает-ли он чтото или простаивает?
а зависит она потомучто умные дяденьки придумали как можно отключать (усыплять) неиспользуемые-в-данный-момент блоки процессора :-)
| | |
| |
| 4.38, User294 (ok), 20:07, 02/10/2010 [^] [^^] [^^^] [ответить] | –6 +/– | Потому что CMOS схема кушает что-то только в момент переключения, сэр Перезаряд... большой текст свёрнут, показать | | |
| |
| 5.57, fr0ster (ok), 21:34, 02/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
Многоядерные системы были, есть и будут весьма специализированными девайсами, то есть ситуация простоя для них не актуальна, их создают под задачу часто.
| | |
| |
| 6.130, User294 (ok), 06:42, 04/10/2010 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Многоядерные системы были, есть и будут весьма специализированными девайсами,
Эээ ну 2...6 ядерные процессоры попадаются и у юзеров. В не слишком специализированных девайсах. Но простому юзеру весьма проблематично загрузить даже 6 ядер надолго.
| | |
| |
| 7.131, fr0ster (ok), 06:51, 04/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
>> Многоядерные системы были, есть и будут весьма специализированными девайсами,
> Эээ ну 2...6 ядерные процессоры попадаются и у юзеров. В не слишком
> специализированных девайсах. Но простому юзеру весьма проблематично загрузить даже 6 ядер
> надолго.
У нас как бы речь было о 32 и более. Неточно высказался тогда,
"Многоядерные системы(много более 6 ядер) были, есть и будут весьма специализированными девайсами". Устроит?
| | |
|
|
| |
| 6.167, fidaj (ok), 10:43, 05/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
 > Угу, что-то не слышал я ещё о реальных продающихся процах, отключающих ядра.
> А существующие, всё, что могут, так это понизить частоту макс. в
> 2-2.5 раза от стандартной (пример моего ноута 2 ГГц ->> 1
> ГГц)...
угу на линухе у меня тоже почти так же, но на "другой системе" мой же этот же ноут - понижает в 21 раз: с 2100МГц до 100МГц....
не ровняйте все по линуксу....
"на правах лирического отступления..."
| | |
|
|
|
|
|
| 1.8, fidaj (ok), 16:48, 02/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Пусть не гонят!
Plan9 к этому давно уже готова!
Манагеры МС взялись за аналитику?
| | |
| |
| 2.24, Анонимный трус (?), 19:33, 02/10/2010 [^] [^^] [^^^] [ответить]
| –7 +/– |
При чем тут План9, который вообще никому не нужен?
И при чем тут манагеры МС? Исследование в MIT делали.
| | |
| |
| 3.32, User294 (ok), 19:52, 02/10/2010 [^] [^^] [^^^] [ответить]
| –6 +/– | |
>Исследование в MIT делали.
Наверное они грант хотят стрясти :).При том почему-то мне так кажется что если 48-ядерные процы станут нормой жизни то линуха всяко подтянут до нормальной работы и на этом хардваре. А куда они денутся то? Как начнут кастомеры всяких ораклов, айбиэмов и редхатов прессовать, так и раздуплятся... :)
| | |
| 3.45, fidaj (ok), 20:22, 02/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
> При чем тут План9, который вообще никому не нужен?
если он не нужен лично вам, то это ничего не значит
> И при чем тут манагеры МС? Исследование в MIT делали.
У вас все документальные данные в наличии со стророны МС, кому и за что они платят?
| | |
| |
| 4.50, Аноним (-), 20:49, 02/10/2010 [^] [^^] [^^^] [ответить]
| +/– | |
План9 - академическая сферовакуумная ОС. Что там к чему готово, я без понятия, но вам правильно говорят - он никому не нужен.
Хотя как архитектурный образец, конечно, да. Их много. Inferno, Plan9, Singularity и прочие. Понадобится - на этой основе сделают что-то реально работающее.
тем не менее, архитектура архитектурой, но принципиальную не-распараллеливаемость многих задач это не отменяет.
| | |
| |
| 5.53, fidaj (ok), 21:00, 02/10/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
> План9 - академическая сферовакуумная ОС. Что там к чему готово, я без
> понятия, но вам правильно говорят - он никому не нужен.
А жаль :(
> Хотя как архитектурный образец, конечно, да. Их много. Inferno, Plan9, Singularity и
> прочие. Понадобится - на этой основе сделают что-то реально работающее.
> тем не менее, архитектура архитектурой, но принципиальную не-распараллеливаемость многих
> задач это не отменяет.
Зато появляется новый абстрактный уровень не привязанный к конкретному железу.. вернее уже есть в лице ненужного плана9...
| | |
| 5.56, Px (?), 21:22, 02/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
 Да, есть принципиально не распараллеливаемые задачи, но много ли машин на которых считают одну единственную «МегаЗадачу»???
| | |
|
|
|
| 2.81, XeNoN (ok), 00:35, 03/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
 >Plan9 к этому давно уже готова!
К чему готова? К обозначенной выше проблеме? Ни разу не готова. Ни по своей архитектуре, ни по текущей реализации, plan 9 не уделывает никакого современного наследника UNIX применительно к проблеме кучи ядер.
| | |
|
| 1.10, Аноним (-), 16:52, 02/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +6 +/– |
К счастью, Linux с открытыми драйверами и базовыми компонентами - готов к переменам, они возможны.
| | |
| |
| 2.31, Аноним (-), 19:51, 02/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
Для того, чтобы сделать то, что они имеют в виду, простым перепилом ведра не обойдешься. Там именно заново придется все писать
| | |
| |
| 3.39, User294 (ok), 20:10, 02/10/2010 [^] [^^] [^^^] [ответить]
| –15 +/– | |
> Там именно заново придется все писать
Помнится Таненбаум в свое время очень ругался что линукс сильно завязан на аппаратные особенности i386. А сегодня у меня почему-то пачка железок с линуксом. И среди них ни одного i386 :). Только x64, ARM и MIPS почему-то. Такие вот чудеса истории.
| | |
| |
| 4.65, Аноним (-), 22:18, 02/10/2010 [^] [^^] [^^^] [ответить]
| –2 +/– |
При чем тут привязка к железу? Ну хорошо, попробуйте переделать ведро под модель а-ля Inferno, я посмотрю на это...
| | |
| |
| 5.72, админ (?), 23:43, 02/10/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
аналогия.
чем это хуже привязки к количеству камней?
зы:
вопрос больше железячный - нужны более быстрые каналы между процами для начала.
а пока это больше ограничение архитектуры, чем ос.
| | |
| 5.132, User294 (ok), 06:52, 04/10/2010 [^] [^^] [^^^] [ответить] | +1 +/– | Просто в свое время линух за непортабельность ругали А он возьми да и стань о... большой текст свёрнут, показать | | |
|
|
|
|
| 1.13, Аноним (-), 17:33, 02/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
мне интересно, userspace будут вообще пилить в сторону потоковости? tar, gzip, bzip - однопоточные. Есть многопоточные форки, но это форки, и они не всегда есть в дистрибутиве, и к тому же не совместимы на 100% по аргументам командной строки
| | |
| |
| 2.20, аноним (?), 19:12, 02/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
> мне интересно, userspace будут вообще пилить в сторону потоковости? tar, gzip, bzip
> - однопоточные. Есть многопоточные форки, но это форки, и они не
> всегда есть в дистрибутиве, и к тому же не совместимы на
> 100% по аргументам командной строки
Если вам надо - возьмите и допилите совместимость. А "не всегда есть в дистрибутиве" - исключительно проблема дистрибутива.
| | |
| 2.66, anonymous (??), 22:22, 02/10/2010 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>tar, gzip, bzip - однопоточные
lzma и xz. а tar - это не компрессор, ему и на одном ядре неплохо живётся.
| | |
|
| |
| 2.94, Vkni (?), 08:19, 03/10/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> По моему они на Minix и еже с ними намекают.
Это тот же Unix, пусть в него и добавлены идеи 86-го года. :-)
| | |
|
| |
| 2.73, админ (?), 23:45, 02/10/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
нет, он врёт.
на 8 ядрах линейная зависимость. врёт зараза.
| | |
|
| 1.21, User294 (ok), 19:27, 02/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –15 +/– | |
> Пока память используется, она не доступна для других задач
А кеши у процессоров - типа для красоты? Или предлагается влупить 48 ядер, оперативку которая не может их прокачать, и кеша не добавлять? :) А так линуксный кернел уже с кучей тредов. Если они в кеш влезут - ну и ладушки. Алсо, не все задачи хорошо параллелятся. Задач которые могут эффективно размазаться на 48 ядер в природе в общем то не так уж и много.
| | |
| 1.23, svchost (ok), 19:32, 02/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 А не проще железячникам вместо увеличения количества ядер продолжать уменьшать техпроцессы, улучшать архитектуры, увеличивать частоты и кэш? А то опять к одноядерным процессорам придем, с кучей "внутренних ядер", "исполнительных блоков" или что-то в этом роде.
| | |
| |
| 2.25, Анонимный трус (?), 19:35, 02/10/2010 [^] [^^] [^^^] [ответить]
| –2 +/– |
> А не проще железячникам вместо увеличения количества ядер продолжать уменьшать техпроцессы,
> улучшать архитектуры, увеличивать частоты и кэш? А то опять к одноядерным
> процессорам придем, с кучей "внутренних ядер", "исполнительных блоков" или что-то в
> этом роде.
Дорого. Нарастить число ядер дешевле, чем перевести линию на новый техпроцесс.
| | |
| |
| 3.47, fidaj (ok), 20:24, 02/10/2010 [^] [^^] [^^^] [ответить]
| +5 +/– |
>> А не проще железячникам вместо увеличения количества ядер продолжать уменьшать техпроцессы,
>> улучшать архитектуры, увеличивать частоты и кэш? А то опять к одноядерным
>> процессорам придем, с кучей "внутренних ядер", "исполнительных блоков" или что-то в
>> этом роде.
> Дорого. Нарастить число ядер дешевле, чем перевести линию на новый техпроцесс.
При чем тут дорого - поучите физику - поймете почему техпроцесс уменьшать уже некуда!
| | |
| |
| 4.60, svchost (ok), 21:39, 02/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
Как некуда? Уже 22 на подходе, 32 нм давно есть в серийном производстве, а Интел все еще свои "энергоэффективные" АТОМы лепит на 45.
Думается, 11 нм тоже не проблема.
| | |
| |
| |
| |
| |
| |
| 9.168, fidaj (ok), 10:44, 05/10/2010 [^] [^^] [^^^] [ответить] | +/– | уже наткнулись - просто в производство еще не все запускают - старьё еще нужно с... текст свёрнут, показать | | |
|
|
|
| 6.133, User294 (ok), 06:56, 04/10/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> ну и что - дальше-то нужно менять принцип транзистора
Угу, они уже вон на 3 ГГц застряли и что-то не больно то спешат даже просто кремний выбрасывать :). Вместо этого они решили в параллельные вычисления поиграть. И теперь у нас пузомерка не гигагерцы уже а количество ядер. А когда юзерам не станет нужно столько ядер - они начнут соревноваться в чем-нибудь еще. Ну например кто больше MIPS/Watt выжмет. Или там еще чего.
| | |
| |
| 7.138, fr0ster (ok), 08:56, 04/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
>> ну и что - дальше-то нужно менять принцип транзистора
> Угу, они уже вон на 3 ГГц застряли и что-то не больно
> то спешат даже просто кремний выбрасывать :). Вместо этого они решили
> в параллельные вычисления поиграть. И теперь у нас пузомерка не гигагерцы
> уже а количество ядер. А когда юзерам не станет нужно столько
> ядер - они начнут соревноваться в чем-нибудь еще. Ну например кто
> больше MIPS/Watt выжмет. Или там еще чего.
Лучше бы сразу начали в "кто больше MIPS/Watt выжмет" играть.
| | |
|
|
| 5.137, tanushi (?), 08:53, 04/10/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
всем доброго времени суток. господин fidaj на самом деле прав. несколько лет назад читал в журнале "в мире науки" (руссифицированная версия the american scientific), что уменьшать до бесконечности не получится. уже, если мне не изменяет память, где-то около 2 нм. подойдут к физическому пределу, меньше которого то ли утечки тока, то ли квантовые эффекты будут настолько велики, что нельзя будет обеспечить стабильной работы. поэтому уже приличное время в лабораториях мира ведутся исследования в направлениях квантовых компьютеров, биокомпьютеров и прочих
| | |
| |
| |
| 7.170, fidaj (ok), 10:49, 05/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>> назад читал в журнале "в мире науки" (руссифицированная версия the american
>> scientific), что уменьшать до бесконечности не получится. уже, если мне не
>> изменяет память, где-то около 2 нм. подойдут к физическому пределу, меньше
>> которого то ли утечки тока, то ли квантовые эффекты будут настолько
>> велики, что нельзя будет обеспечить стабильной работы. поэтому уже приличное время
>> в лабораториях мира ведутся исследования в направлениях квантовых компьютеров, биокомпьютеров
>> и прочих
> А вы сами представьте - при таких размерах эти транзисторы нужно будет
> разглядывать в электронный микроскоп, так что это уже будет не просто
> там квантовые эффекты, а химия - ...
ну и БРЕД!!!
какая химия????
не порите чушь!
| | |
|
|
|
|
|
| 2.29, Аноним (-), 19:47, 02/10/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
Так пока что там небольшой технологический(?) тупичок. Частоты повысить не получается, а если даже немного повысить, то это будет не процессор, а обогреватель, что не соответствует современным требованиям по энергосбережению. Да и из старых архитектур надо еще денег повыжимать - зачем на исследования и разработку тратиться. Вообщем куча факторов, искуственно тормозящих развитие технологий. А от кучи ядер толку тоже немного - как минимум для начала надо перейти на быструю RAM не конденсаторного типа, а оно пока в разработке............
| | |
| |
| 3.40, User294 (ok), 20:13, 02/10/2010 [^] [^^] [^^^] [ответить]
| –14 +/– | |
> начала надо перейти на быструю RAM не конденсаторного типа,
Да вообще-то SRAM уже не одно десятилетие назад придуман. Только при том же числе транзисторов он в несколько раз менее емкий получается. Поэтому статичная оперативка - круто, быстро ... и чертовски дорого. И именно поэтому никто ей и не пользуется.
| | |
|
| 2.44, fidaj (ok), 20:19, 02/10/2010 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> А не проще железячникам вместо увеличения количества ядер продолжать уменьшать техпроцессы,...
Не проще... они уже уперлись в атомы... меньше (лептоны и кварки) пока не получается...
| | |
|
| 1.30, pavlinux (ok), 19:48, 02/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +16 +/– |
 В общем, это проблема не OS, а производителей процессоров, контроллеров I/O, материнок...
А чё они хотели??? Имея типовые проекты 14-и этажек, построить небосрёб в 1000 этажей, с одним лифтом??? :)
И при этои оптимизироваться должны жители - создать расписание поездок на лифте,
установить правила - чтоб жители ближайших пяти между собой этажей группировались
для поездки как вниз так и вверх, так же группировались по весу, для оптимального
заполнения лифта и, как следствие, увеличение траффика. Каждую вторую поездку лифт
будет останавливаться только на чётных этажах. Оптимизировать по количеству запросов
на обслуживание - если, к примеру, на 205 этаже сгруппировались 10 человек,
на 378 - 8, ...., а на 998 - один, то с вероятностью 99.8 он из дома не выйдет :)
ЖУЙ ВАМ!!! ДЕЛАЙТЕ НОРМАЛЬНЫЕ КОМПЫ И ПРОЦЕССОРЫ!!!
| | |
| |
| |
| |
| |
| Часть нити удалена модератором |
| 5.51, pavlinux (ok), 20:49, 02/10/2010 [^] [^^] [^^^] [ответить]
| +3 +/– |
>> вообщето вся тема -- в 70% сообщений только и говорит про кэши
>> и шины.. как это относиться к OS ?
> А что, предлагается рассматривать абстрактную ОС в вакууме, в отрыве от реально
> существующего железа? :)
Это он к тому, что 70% гимороя из-за железа.
Авторы же исследования утверждают, что операционки не готовы к многоядерному фаршу!
Нельзя быть двум человекам в одном месте, в одно и тоже время,
если входить через одну дверь! (с) Я
| | |
|
|
| 3.41, User294 (ok), 20:15, 02/10/2010 [^] [^^] [^^^] [ответить]
| –16 +/– | |
> доказать не может.
Жизненно же. Попробуйте распараллелить обсчет MD5 хеша для *одного* большого файла на 48 процов? Ну и как, получается? :)
| | |
| |
| 4.59, Crazy Alex (??), 21:39, 02/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
Ну вот конкретно md5 этот не параллелится. Ну и что? Компьютеры нынче отнюдь не однозадачные, масса всего параллельно крутится - заче параллелить один алгоритм, когда разных одновременно орда крутится?
| | |
| 4.116, Аноним (-), 16:57, 03/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
>> доказать не может.
> Жизненно же. Попробуйте распараллелить обсчет MD5 хеша для *одного* большого файла на
> 48 процов? Ну и как, получается? :)
А Вы попробуйте за итерацию подобрать хэш? Ну и как, получается? :)
И явно 48 не обойдется подбор вне зависимости от размера файла.
Неудачный пример.
| | |
| |
| 5.129, User294 (ok), 06:39, 04/10/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Неудачный пример.
Так проблема в том что в реальном мире дофига этих "неудачных примеров", что и является той ложкой дегтя в бочке с медом многоядерности ;). Поэтому сделав 48-ядерный процессор есть риск обнаружить что спрос на него не такой уж и высокий (т.к. большая часть юзеров с их типовыми задачами просто не могут столько ядер поюзать). Будет еще один итаник? :)
| | |
| 5.149, аноним (?), 22:06, 04/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
Надо на уровень выше думать, а не задачи, успешно решающиеся первопнями раздувать на 3 порядка. Зачем вам md5 терабайта? Чтобы повреждение данных обнаружить? Ну обнаружите, и что - будете терабайт перекачивать? Не смешите. Разбейте на блоки и считайте, и параллельте хоть на 500 ядер.
| | |
| |
| 6.156, User294 (ok), 06:03, 05/10/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> на блоки и считайте, и параллельте хоть на 500 ядер.
Однозначно! Только вот...
1) А 500 винчей - это нормально? Ну или толку то от 500 ядер, если прогрузится аж пяток ядер, а больше накопитель все-равно не выжимает читать? :) В общем то 500 ядер подразумевают еще и подсистему памяти и ввода-вывода способные их такие прокормить. А с этим как-то пока не очень. Как-то туго себе представляется майнстримовый компьютер с 500-канальной памятью. В суперкомпьютерах на такое могут наверное распереться но в штучных тиражах, да и есть менее геморные методы достижения сравнимой производительности, не требующие таких изгалений и вполне себе успешные, наконец.
2) Надо еще убедить весь мир делать так же. Перейти на такие протоколы/форматы данных и прочая. В принципе это возможно. Остается только вопрос - а захочет ли мир думать вот так? Или вы будете в гордом одиночестве сравнивать ваш параллельный md5 сами с собой. А скачав терабайтный файл с ремотного сервера ... будете по старинке жевать его в 1 поток, жутко чертыхаясь на то что суперпроц с его 48 ядрами обладает довольно хилыми по отдельности ядрами. В итоге желающих покупать 48-ядерные суперпроцы может оказаться как-то маловато и они могут загнуться и/или остаться штучными решениями.
| | |
| |
| 7.165, fr0ster (ok), 08:23, 05/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
Куда то вы не туда повели, сами говорили о спецзаточенности многоядерников, и сами теперь рассматриваете их через призму универсальных, обывательских можно сказать, систем.
| | |
|
|
|
| 4.172, Dron (ok), 11:53, 08/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
 MD5 - это конечно не аргумент...
И один файл - это тоже не аргумент. :)
То, что пока мало задач, которые могут эффективно использовать многоядерность - это вопрос времени. Раньше любая игрушка умещалась на FDD три раза, и все мучались вопросом - чем же можно загрузить 4 мегабайта памяти на крутых и никому не доступных x386... :)
Сейчас такие вопросы не стоят, благополучно загрузили...
Будет 1000 ядер - возникнут и алгоритмы, которые смогут их эффективно загрузить. И линукс не заставит себя ждать... за 5 лет они его 3 раза полностью переписать успеют. :)
| | |
|
|
| 2.54, cmp (??), 21:10, 02/10/2010 [^] [^^] [^^^] [ответить]
| +2 +/– | |
В целом - лаконично, но врядле это проблема "производителей процессоров, контроллеров I/O, материнок", нет лучше инструмента для копания, чем лопата, пока у тебя две руки и ноги, с увеличением конечностей эффективность использования будет падать, (неужели чтобы это понять нужно быть Исследователем из Массачусетского Технологического института...)
Будет ли эффективным писать новую ОС для эффективной работы на 1000 ядерном проце?
А если вспомнить про виртуализацию.. видимо, они там в институте чета покурили и их на панику прибило, - "о боже, небо падает".
| | |
|
| 1.58, StrangeAttractor (ok), 21:38, 02/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Рост числа процессорных ядер приведет к необходимости смены архитектуры ОС
Новости от Капитана Очевидность...
Не прошло и n лет как до них дошло...
| | |
| 1.63, Zenitur (?), 22:01, 02/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Я не понял: так надо для второго ядра компилировать второе ядро, или нет?!
| | |
| |
| 2.110, pavlinux (ok), 15:01, 03/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
Каждому ядру по ядру!
---
А ваще, если сделаешь ps ax, то увидишь много SMP клонов типа
[migration/2]
[ksoftirqd/0]
[ksoftirqd/1]
[ksoftirqd/2]
[ksoftirqd/3]
[migration/3]
[kworker/0:1]
[kworker/1:1]
[kworker/2:1]
[kworker/3:1]
...
| | |
|
| 1.93, ua9oas (?), 07:06, 03/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 Интересно, а как заставить работать XP на многоядерных процессорах? (она же в отличие от "7" не может этого делать и заодно "7" тяжелее ее). Например можно ли создать такое ПО, которое бы для XP это могло бы делать? А то ведь есть же ПО, которое позволяет использовать более 2 Гб оперативной памяти в 32битных ОС.
| | |
| |
| 2.96, Zenitur (?), 08:50, 03/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
У AMD есть драйвер, оптимизирующий работу с несколькими процессорами, так как сам Windows это делает хуже. Драйвер, кстати, творит чудеса.
Ну как-как... Разработчики программ добавляют возможность использования нескольких ядер процессора, оптимизируя тем самым их выполнение. Не удивлюсь, если Windows-пользователи с радостью готовы отдать одно процессорное ядро антивирусу. Я бы посмеялся.
Или ты имеешь в виду основные системные библиотеки? Не знаю, что с ними не так. Если даже системная программа не умеет распараллеливаться, попутно запуститься другая, которая займёт второе, третье, четвёртое, пятое, шестое ядро... Была поддержка многоядерности в XP, была. Потому что раньше были популярны многопроцессорные конфигурации. НЕ многоядерные, а многопроцессорные. На сервере, например.
| | |
| |
| 3.99, odus (ok), 10:17, 03/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
 Если имеется в виду программа AMD DualCore Optimizer,
то для Phenom II, Athlon II эта программа не нужна
Что касается многоядерных конфигураций то Windows XP начали делать в то время когда их не было
| | |
|
|
| |
| 2.104, СуперАноним (?), 12:51, 03/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
Да уж пусть его 3.0.X обзывают. А то у людей только что приходящих в Linux создаётся впечатление, что ядро очень медленно развивается: как было 10 лет назад 2.*, так и осталось.
| | |
| |
| 3.113, cmp (??), 15:28, 03/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
> Да уж пусть его 3.0.X обзывают. А то у людей только что
> приходящих в Linux создаётся впечатление, что ядро очень медленно развивается: как
> было 10 лет назад 2.*, так и осталось.
ага, 5 споловиной в квадрате, если у людей мозга нет понять почему..., или пусть убунту пользуют она аж 10.х. уже, аж на три поколения круче виндовс7 этож кокая моща,
| | |
|
|
| 1.106, weldpua2008 (ok), 14:25, 03/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 У Меня вопрос. Вы тут про параллельное выполнение одного алгоритма говорите...
Tasks: 159 total, 2 running, 157 sleeping, 0 stopped, 0 zombie
Cpu(s): 15.7%us, 3.3%sy, 0.0%ni, 80.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2066520k total, 1725484k used, 341036k free, 49404k buffers
Swap: 2056280k total, 0k used, 2056280k free, 1277476k cached
Хм... Tasks: 159 total
Если ядер 128-1024, то получается что процессов меньше=количество ядер :)
Причём реально 10-30 процессов, которые можно и наверное нужно повесить на разные ядра.
Ну есть задачи которые не паралеляться - ну пусть висят на своих ядрах :)
А те, что паралеляться пусть используют пул из ядер ;)
А вообще Я не представляю как при скорости чтения до ~150Мб/сек 30-50 процессов ОДНОВРЕМЕННО будут читать из диска разные данные, причём из разных областей.
Видимо не долго жить жёстким под ОСь.
Я так вижу, что в ящике будет 2-а диска. Один быстрый, не ёмкий и исключительно под ОСь, а другой исключительно под файлопомойку.
| | |
| |
| 2.107, fidaj (ok), 14:32, 03/10/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
> А вообще Я не представляю как при скорости чтения до ~150Мб/сек 30-50
> процессов ОДНОВРЕМЕННО будут читать из диска разные данные, причём из разных
> областей.
> Видимо не долго жить жёстким под ОСь.
процессоры уже ооо-чень давно ничего с дисков не "читают"...
| | |
| |
| 3.114, weldpua2008 (ok), 16:30, 03/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
>> А вообще Я не представляю как при скорости чтения до ~150Мб/сек 30-50
>> процессов ОДНОВРЕМЕННО будут читать из диска разные данные, причём из разных
>> областей.
>> Видимо не долго жить жёстким под ОСь.
> процессоры уже ооо-чень давно ничего с дисков не "читают"...
...а есть различия?:
процессов(программ) и процессоров...
Или у Вас волшебные OpenOffice, Firefox, mc, Kate, Mplayer, etc... с диска ничего не читают/пишут?
| | |
| |
| 4.115, fidaj (ok), 16:33, 03/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>> А вообще Я не представляю как при скорости чтения до ~150Мб/сек 30-50
>>> процессов ОДНОВРЕМЕННО будут читать из диска разные данные, причём из разных
>>> областей.
>>> Видимо не долго жить жёстким под ОСь.
>> процессоры уже ооо-чень давно ничего с дисков не "читают"...
> ...а есть различия?:
> процессов(программ) и процессоров...
> Или у Вас волшебные OpenOffice, Firefox, mc, Kate, Mplayer, etc... с диска
> ничего не читают/пишут?
уупс - я о другом :)
| | |
|
|
| 2.121, svchost (ok), 17:49, 03/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
> Я так вижу, что в ящике будет 2-а диска. Один быстрый, не
> ёмкий и исключительно под ОСь, а другой исключительно под файлопомойку.
Это сейчас только такое извращение у некоторых есть. Покупают интеловские SSD чисто под систему, и терабайтники под файлопомойку. Потом то уж должны же уйти в мир иной эти магнитные крутящиеся механизмы (вместе с оптическими дисками), а их место займут подешевевшие и налаженные SSD диски с крутыми и быстрыми интерфейсами (думается, SATA тоже уйдет как раритет :) )
А вот когда серийное производство в Китае началось бы этих SSDшек, то их шлепали бы как пирожки, тем более, что там меньше нужно железа и к качеству менее критично ввиду отсутствия механики.
| | |
| 2.150, аноним (?), 22:12, 04/10/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Хм... Tasks: 159 total
Нет, это. Вот это - 2 running. Правда, тут потоки не считаются.
О вас с 2 задачами речь вообще не идет, вы могли бы и на первопнях сидеть на своих печатных машинках.
> А вообще Я не представляю как при скорости чтения до ~150Мб/сек 30-50
> процессов ОДНОВРЕМЕННО будут читать из диска разные данные, причём из разных
> областей.
Да будет вам известно, нормальные CPU-hungry задачи ничего не читают с диска. Более того, они даже из памяти ничего не читают - все в регистрах и кэше, иначе быстро не получится, сколько ядер не пихай.
| | |
|
| 1.123, zuborg (?), 18:34, 03/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
Solaris 10 + UltraSPARK T1 8 cores x 4 threads (= 32 threads total)
2005-й год, древняя технология по современным меркам
| | |
| 1.142, gkv311 (ok), 10:05, 04/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 Ещё с год назад читал про это от представителей Microsoft (про будущие Windows). Основная идея была в том, что эффективнее будет целиком отдавать часть ядер каждому процессу.
Как-то заторможенно они это исследование решили провести...
| | |
| |
| 2.143, fr0ster (ok), 10:14, 04/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
> Ещё с год назад читал про это от представителей Microsoft (про будущие
> Windows). Основная идея была в том, что эффективнее будет целиком отдавать
> часть ядер каждому процессу.
> Как-то заторможенно они это исследование решили провести...
ИМХО это мало что даст, "бутылочное горлышко" в другом месте будет, не более.
Линейной прибавки производительности не достичь:)
| | |
| 2.151, аноним (?), 22:12, 04/10/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Ещё с год назад читал про это от представителей Microsoft
Ага, а у них affinity mask до сих пор в long'е. На 32 битах 32 ядра, на 64 битах 64, больше хочешь-не хочешь ничего не будет :)))
| | |
|
| 1.157, stimpack (?), 06:12, 05/10/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Думается, из всего этого количества байт, что мы все вбили здесь, легко можно сварганить патч для ядра с требуемым для решения этой проблемы функционалом.
Жаль лишь, что это байты скорее от миллиона мартышек, что пытаются написать "Войну и Мир", а не от того, кто в состоянии этот патч.
| | |
| |
| 2.166, fr0ster (ok), 08:25, 05/10/2010 [^] [^^] [^^^] [ответить]
| +/– |
> Жаль лишь, что это байты скорее от миллиона мартышек, что пытаются написать
> "Войну и Мир", а не от того, кто в состоянии этот
> патч.
Какой "Война и Мир"? Мы тут все максимум пытаемся по... самолюбие почесать и развлекаемся немного. Любая серьезная тема будет обсуждаться в личке или еще где.
| | |
|
|
