Исследователи из Массачусетского Технологического института пришли к выводу (http://www.conceivablytech.com/3166/science-research/current.../), что существующие операционные системы испытывают проблемы с эффективностью работы на системах с большим числом процессорных ядер. В качестве граничного значения для SMP-режима в Linux указаны 48-ядреные системы, которые по оценке авторов исследования получат распространение в ближайшие 5-8 лет. Для таких систем придется внести в ОС значительные изменения, связанные с переходом на принципиально иную архитектуру.
При превышении границы в 48 процессорных ядер суммарная производительность Linux будет падать, а не возрастать. Проблема вызвана тем, что несколько ядер часто выполняют лишнюю работу и обрабатывают одни и те же данные, которые нужно держать в памяти чипа во время обработки. Пока память используется, она не доступна для других задач, что приводит к падению производительности из-за "...URL: http://www.conceivablytech.com/3166/science-research/current.../
Новость: http://www.opennet.me/opennews/art.shtml?num=28145
DragonFlyBSD?
Я именно о ней и подумал, читая эту новость )
а что в ней на этот предмет?
а то. зайдите на сайт и прочитайте.
> а то. зайдите на сайт и прочитайте.то что они от блокировок принялись избавляться сразу после форка и сейчас, скорее всего, избавились совсем? так это я и без их сайта знаю
а нельзя просто прямо ответить на прямо заданный вопрос?
А в DragonFly принята несколько другая парадигма многопроцессорной системы. Там у каждого ядра есть свой планировщик. Поэтому в пределах одного планировщика получается практически однозадачная система, которой не нужны блокировки. В случае же если необходимо обратиться к ресурсу, закреплённому за другим процессором, процесс либо сам мигрирует на этот процессор либо отправляет запрос диспетчеру ресурса, работающему на этом процессоре. Запрос представляет собой сообщение, которое складывается в очередь сообщений диспетчера ресурса. Диспетчер ресурса обрабатывает сообщения по очереди и отвечает на них. Процесс сам решает, стоит ли ему ждать ответа на сообщение или стоит обработать ответ на сообщение асинхронно, продолжая выполнять другую работу.Например, есть жёсткий диск, есть драйвер жёсткого диска. Этот драйвер является отдельным процессом и он привязан к одному процессору. На другом процессоре этот же драйвер запуститься не может, а на том же самом процессоре драйвер-процесс не сможет сам себя вытеснить. Все обращения к жёсткому диску попадают в виде сообщений в очередь сообщений драйвера-процесса и обрабатываются по очереди.
Всё это существенно отличается от парадигмы реентерабельности единого образа ядра, когда любой процесс может попытаться обратиться к ресурсу любого процессора. При этом приходится постоянно проверять доступность ресурса и блокировать его.
>[оверквотинг удален]
> или стоит обработать ответ на сообщение асинхронно, продолжая выполнять другую работу.
> Например, есть жёсткий диск, есть драйвер жёсткого диска. Этот драйвер является отдельным
> процессом и он привязан к одному процессору. На другом процессоре этот
> же драйвер запуститься не может, а на том же самом процессоре
> драйвер-процесс не сможет сам себя вытеснить. Все обращения к жёсткому диску
> попадают в виде сообщений в очередь сообщений драйвера-процесса и обрабатываются по
> очереди.
> Всё это существенно отличается от парадигмы реентерабельности единого образа ядра, когда
> любой процесс может попытаться обратиться к ресурсу любого процессора. При этом
> приходится постоянно проверять доступность ресурса и блокировать его.Всё верно! Если сказать простыми словами, то там используются LWKT (Light Weight Kernel Threads), т.е. каждый процесс обладает собственным планировщиком. Насколько я помню, именно из-за реализации этиз концепций Диллон и ушел из FreeBSD.
Результаты исследования: http://pdos.csail.mit.edu/papers/linux:osdi10.pdf
> Результаты исследования: 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.Т.е. "Бобёр, выдыхай".
принципиально новый Linux? :)
Принципиально старый Plan9https://researcher.ibm.com/researcher/view_project.php?id=1271
Линукс сакс
> Принципиально старый Plan9
> https://researcher.ibm.com/researcher/view_project.php?id=1271
> http://www.vitanuova.com/
> Линукс саксДа, линукс полное г по сравнению с планом, по мнению "спицалистов" его курить нельзя.
Вы План9 часто видели в промышленной эксплуатации?
Вот когда какая то фича будет востребована, тогда она как тут говорилось и появится в Линуксе, так как Линукс не модой руководствуется, а практическими нуждами, как впрочем и любая нелабораторная ОСь
> Да, линукс полное г по сравнению с планом, по мнению "спицалистов" его
> курить нельзя.Крутой велосипед с турбонаддувом. Правда на улицах почему-то попадаются менее крутые концепты обычно. Да, не всем дано понять круть турбонаддува в велосипеде. Велосипеды без турбонаддува - сакс.
>> Да, линукс полное г по сравнению с планом, по мнению "спицалистов" его
>> курить нельзя.
> Крутой велосипед с турбонаддувом. Правда на улицах почему-то попадаются менее крутые концепты
> обычно. Да, не всем дано понять круть турбонаддува в велосипеде. Велосипеды
> без турбонаддува - сакс.Вы нехороший человек, я теперь от любопытства помру, пытаясь понять, куда же именно турбонаддув велосипедисту вставляется.
А как же работали 1024-ядерные системы покойной SGI?
И все ядра под одной копией linux!
1024-ядерные или 1024 процессорные?
> 1024-ядерные или 1024 процессорные?Кстати, а какая разница? Правда интересно. Мне ясно только что при отдельных процах получается кэша больше.
суперкомпьютеры сильны, когда каждая нода выполняет свою часть задачи. А потом все решения надо объединить. Помнится на Пентиум3 в МГУ строился вычислительный кластер, и много денег потратили на сеть, что бы задержки и коллизии исключить, которые бывают в распространенном езернете. Там какой-то "хитрый" езернет был.Сейчас я японии строить собираются 10Тфлопный суперписюк ) Так там как раз одна из особенностей, это новый подход к сети кластера.
Или же еще пример. Применение шейдеров видеокарты для вычисления - хорошая идея, но задачу надо разбить правильно и главное что бы под "размер" шейдера. Затем на выходе собрать результат.
Вот так я понимаю.
>суперкомпьютеры сильны, когда каждая нода выполняет свою часть задачи.а при чём тут ноды?
был задан конкретный вопрос.
зы:
ядра почти не отличаются от выделенных камней. иногда просто некоторые ресурсы бывают общими - кэш, фпу и т.д.
Это только если абстрагироваться что скорость и задержки в канале связи на кристале и на плате - это совсем разные вещи :)
Какую плату вы имеете ввиду? Данные между физически связанными ядрами вполне радостно гуляют внутри чипа, с частотой, явно большей, чем та, что между отдельными процами, избегая всяких прочих плат, и, соотв., с задержкой меньшей. Платы в таком случае лишь получают уже готовые обработанные вещи и посылают новые данные для обработки.
> А как же работали 1024-ядерные системы покойной SGI?А еще вон в топ500 почему-то куча линукса. А если то что говорят фрукты из MIT правда - ну допилят ядро, куда ж они денутся? :) Может парни из MIT себе грант на "принципиально новую ОС" хотят выбить?
Кластер и супер-мультиядерность на одном чипе - несколько разные вещи.
> Кластер и супер-мультиядерность на одном чипе - несколько разные вещи.Однозначно. Правда насчет того что супер-мультиядерность вообще перспективна - это большой вопрос. Где Kilocore от IBM, например? А то там 1024 ядра чтоли обещали, или около того. У многоядерников есть проблема: если задача не параллелится (а параллелится не любая задача), все упирается в скорость 1 ядра а остальные ничего не делают. При этом чем круче отдельное ядро (и чем их меньше умещается, соответственно) тем лучше работает 1-поточная задача. Ну вот интели и амд всякие нынче для борьбы с этим жутко изгаляются. Делая всякие TurboCore и что там еще (ака разгон 1 ядра при неактивных остальных).
кстати согласен - без правильного распараллеливания задачи фиг что получится.
сейчас на смп проще считать так - одна задача, один проц.
> кстати согласен - без правильного распараллеливания задачи фиг что получится.А некоторые задачи как-то так изначально последовательные и не очень то хотят параллелиться по природе своей. Собственно этот простой и обидный факт и является основной проблемой многоядерников, из-за которых процы с уймой относительно слабых ядер так и не пошли в массы.
> является основной проблемой многоядерников, из-за которых процы с уймой относительно слабых
> ядер так и не пошли в массы.Не совсем так, видяхи те же узкоспециализированные компы, а какая массовость?
Мисье все знайка - доведу до твоего сведения - в TOP500 нет не одной машины с количеством ядер на одной ноде выше 32х. Ноды обмениваются между собой или через shared memory (mmap большого файла) или через MPI. ТОЧКА.То как linux kernel пытались запускать на SGI Altrix - это отдельная и грустная история - он там просто не работал, ибо инициализация 512 ядер занимала дохрена времени и накладные расходы вобщем-то тоже.
Линукс на машинах Cray XT[3-5], IBM BG/L сводится к одной вещи - запускалка процессов.
Единственное серьезное использование это service node - там еще +/- похожее на привычное окружение.Надеяться что ядро "допилят" не стоит - много ли допиливаний под Cray вернулось в ядро?
А BG/L specific ?
> много ли допиливаний под Cray вернулось в ядро?Вы хотите сказать что вон та орава ядерщиков не сможет так же? При том их главный финноамериканец это самое ядро с нуля написал? Прикольно, да :)
> Надеяться что ядро "допилят" не стоит
Да что вы так нервничаете? Время покажет. Будут 48-ядерные процы майнстримом - тогда и увидим все.
Я думаю что если кастомеры начнут теребить редхатов, ораклей, айбиэмов и прочих - они быстренько допилят, никуда не денутся. А что, у них еще и выбор будет? :)
>> много ли допиливаний под Cray вернулось в ядро?
> Вы хотите сказать что вон та орава ядерщиков не сможет так же?Не сможет.
> При том их главный финноамериканец это самое ядро с нуля написал?
> Прикольно, да :)Один он ? ну ты наивный малый :) почитаешь на lwn.net кто вкладывает и за чьи деньги в ядро?
А что будет если туда не будут вкладывать - то где эти интузиасты будут ?:)
>> Надеяться что ядро "допилят" не стоит
> Да что вы так нервничаете? Время покажет. Будут 48-ядерные процы майнстримом -
> тогда и увидим все.По себе судить не стоит.
> Я думаю что если кастомеры начнут теребить редхатов, ораклей, айбиэмов и прочих
> - они быстренько допилят, никуда не денутся. А что, у них
> еще и выбор будет? :)Ты хоть раз общался с сапортом RedHat ? видимо нет.
Если ты не клиент с 1000 лицензий - ты им слабо интересен.
Если ты еще хочешь чего-то странного, что не укладывается в их виденье мира - то ровно так же.
Собрать ядро с какой нить опцией - идешь лесом, починить баг который им кажется маловажным - ровно так же.
Так что мисье всезнайка облажался в очередной раз.
>>> много ли допиливаний под Cray вернулось в ядро?
>> Вы хотите сказать что вон та орава ядерщиков не сможет так же?
>Не сможет.Сможет.
>>>> много ли допиливаний под Cray вернулось в ядро?
>>> Вы хотите сказать что вон та орава ядерщиков не сможет так же?
>>Не сможет.
> Сможет.Вначале посчитает, сколько на это надо бабок и пошлет затею лесом, пока широкого употребления многоядерных систем не будет.
> Не сможет.Да бросьте, там собралась такая куча ориентированных не на процесс и теоретическую круть а на результат что они *любую* актуальную задачу смогут вкатать в асфальт. Не где-то там в теории как математик из анекдота про пожар и пожарный кран, а на практике. В реальном мире. На реальных машинах. Будет задача хорошо работать на 48 ядрах? Сделают. Готов даже поспорить на $100 :)
> Один он ?
Ну, начал он один. А потом орава присоединилась. И вот теперь там такая могучая кучка которая может разобраться с любой задачей.
>ну ты наивный малый :) почитаешь на lwn.net кто вкладывает и за чьи деньги в ядро?
Да я его и так в общем то читаю регулярно. Что-то опоздали вы с советами лет на эн...
> А что будет если туда не будут вкладывать - то где эти интузиасты будут ?:)
Кто тут еще наивный :). Если уж на горизонте нарисуется задача "хорошо работать с 48 ядрами" - уж вкладывающие бабки в линух будут первым делом заинтересованы скорее всего, т.к. у них или их кастомеров и будут такие железяки первым делом. И, кстати, допилить напильничком до работающего состояния то что уже есть - куда дешевле чем с нуля такое же но идеологически правильнее написать. Это даже туповатые инвесторы понимают.
> По себе судить не стоит.
Ну так и не судите.
> Ты хоть раз общался с сапортом RedHat ? видимо нет.
> Если ты не клиент с 1000 лицензий - ты им слабо интересен.Ради одного В. Пупкина с 1 лицензией ессно никто не будет кастомно кодить что-то в большом масштабе. Только вот 48-ядерные процы ради одного В.Пупкина и подавно никто не станет производить, если что. Первыми заинтересуются такими железками как раз эти, с 1000 лицензий которые. У Пупкинов пупок развяжется платить за первые процы с 48 ядрами. Дальше оно может быть станет майнстримом. А может быть вслед за Итаником отправится. Это уж рынок решать будет.
> Если ты еще хочешь чего-то странного, что не укладывается в их виденье
> мира - то ровно так же.Если процессоры с 48 ядрами станут обыденностью - они перестанут быть странными. А если к ним придет один В. Пупкин с одной лицензией но где-то каким-то чудом урвавший инженерный сэмпл 48-ядерного проца - ну да, он не повод для дерганий. Хотя-бы потому что вообще нет гарантий что этот проц в серию пойдет. А повкалывать ради красоты концепций самой по себе и счастья одного В. Пупкина - дорого и непрактично.
> Собрать ядро с какой нить опцией - идешь лесом, починить баг который
> им кажется маловажным - ровно так же.Извините. Попробуйте такое попросить у микрософта для сравнения? А хотя-бы и будучи кастомером с 1000 лицензий?
> Так что мисье всезнайка облажался в очередной раз.
И правда - облажался. Потому что "мисье" - это позор! Анонимные аналитики школу не заканчивали? oO
>Ноды обмениваются между собой или через shared memory (mmap большого файла)Ещё один всезнайка нашелся. И чем же мемори расшаривается ? Сокет планки памяти запаян на материнки обоих нод ? Или изменения в файле через NFS синхронизируются ?
Короче, слыхал звон, да не знал где он...
>Или изменения в файле через NFS синхронизируются ?Если для вас сетевые FS заканчиваются NFS - мне вас очень жаль.
lustre | GPFS + mmaped file - вполне себе схема shared memory.DLM обеспечит когентность кэшей на всех нодах.
Ах да, забыл.
вокруг этого mmap file, накручивают стопку MPI_barrier что бы синхронизировать доступ.
а за одно советую чутку заглянуть в google по словам "MPI shared memory mmap"
узнаете много нового для себя, и перестанете кичиться своим невежеством.
> а за одно советую чутку заглянуть в google по словам "MPI shared
> memory mmap"
> узнаете много нового для себя, и перестанете кичиться своим невежеством.Вы бы язык-то прикусили, да почитали бы о том, о чем несете абсолютный бред, ни хрена не понимая как оно работает.
Да да :) расскажи мне убогому как оно работает..
Как DLM поддерживает когентность page cache на многих машинах :)
А я послушаю "аналитика" ;-)
Или все знания окачиваются NFS? так в NFS v4.1 уже начались подобия нормальной файловой системы..
>Ноды обмениваются между собой или через shared memory (mmap большого файла)
>...
>GPFS + mmaped file - вполне себе схема shared memoryИтак, подытожим, ноды суперкомпа обмениваются между собой информацией используя сетевые файловые системы (такие как GPFS) через замечательный IPC механизм shared memory, который по определению работает в пределах одной машины (т.к. память, хранящаяся в состоянии одного и того же блока транзиторов в конкретном чипе памяти может быть отображена в адресное пространство нескольких процессов только в пределах той машины, на которой эти процессы исполняются)
Вы у Петросяна помощником не работаете ?
>>Ноды обмениваются между собой или через shared memory (mmap большого файла)
>>...
>>GPFS + mmaped file - вполне себе схема shared memory
> Итак, подытожим, ноды суперкомпа обмениваются между собой информацией используя сетевые
> файловые системы (такие как GPFS) через замечательный IPC механизм shared memory,
> который по определению работает в пределах одной машины (т.к. память, хранящаяся
> в состоянии одного и того же блока транзиторов в конкретном чипе
> памяти может быть отображена в адресное пространство нескольких процессов только в
> пределах той машины, на которой эти процессы исполняются)LOL. вы где учились юноша?
shared memory - не исчерпывается только System V IPC. mmap ровно такой же механиз для организации shared memory и IPC обмена между процесами (http://en.wikipedia.org/wiki/Mmap)
и то что процессы разнесены по разным нодам роли не играет :)2 ноды вполне могут открыть один файл и при помощи mmap(), отобразить в собственное адресное пространство.
После этого механизмы заложеные в distributed lock mamager (DLM - детали прочитаете на wikipedia) воплне могут обеспечить когерентность page cache у этих 2х нод.
Это будет не быстро (по сравнению с обычным чтением с DFS), будет вызывать lock ping-pong - но работает, и для некоторых задач - имеет место использоваться.> Вы у Петросяна помощником не работаете ?
ищите колег ?
за одно стоит прочитать определениеhttp://en.wikipedia.org/wiki/Shared_memory
что бы в очередной раз не слыть невеждой и мне в очередной раз жаль что понятие shared memory для вас закончилось на System V IPC, а понятия файловых систем - на NFS который не имеет никакого distributed lock manager.
>http://en.wikipedia.org/wiki/Shared_memoryцитирую:
In computer hardware, shared memory refers to a (typically) large block of random access memory that can be accessed by several different central processing units (CPUs) in a multiple-processor computer system.Вношу ясность - на разных нодах процессы работают с "физически разными" чипами памяти, следовательно, никакие сетевые FS не могут процессу на одной ноде предоставить доступ к памяти, которая физически находится на другой ноде, поэтому поняние shared memory неприменимо в данном случае.
Еще раз - shared memory это память, представленная физически одним и тем же набором транзисторов в конкретном чипе, отображенная в адресное пространство нескольких процессов, запущеных на одной системе. Следовательно, процесс на другой ноде не может никак получить доступ к "этой" памяти. Сетевая FS может предоставить такому процессу на другой ноде доступ только к "копии" содержимого памяти с исходной ноды.Копия содержимого памяти и "одна и та же страница" памяти - это существенно различные понятия.
PS. прошу прощения за излишнюю резкость в предыдущих сообщениях.
>>http://en.wikipedia.org/wiki/Shared_memory
> цитирую:
> In computer hardware, shared memory refers to a (typically) large block of
> random access memory that can be accessed by several different central
> processing units (CPUs) in a multiple-processor computer system.читаем еще раз. но не между строк
In softwareIn computer software, shared memory is either
a method of inter-process communication (IPC), i.e. a way of exchanging data between programs running at the same time. One process will create an area in RAM which other processes can access, ora method of conserving memory space by directing accesses to what would ordinarily be copies of a piece of data to a single instance instead, by using virtual memory mappings or with explicit support of the program in question. This is most often used for shared libraries and for XIP.
переводим:
- метод межпроцесорного взаимодействия когда один процесс создает область памяти к которой другие могут получить доступ
- запихивание разных vma (virtual memory area) в разные процессы - так что они реально имеют доступ к
общим данным.так все таки применимо - или тут разные процессы (на разных нодах) не получают доступ к общим данным?
> Копия содержимого памяти и "одна и та же страница" памяти - это существенно различные понятия.а ничего что после pagger и последующего востановления из свопа - у вас будут разные физические страницы? и любое приложение на userland работает с виртуальными адресами - которые никак не связаны с реальными транзисторами.
А с точки зрения виртуальной памяти нет никакой разницы - соединили микросхемы в 2х нодах физически или логически.ps. я понимаю вашу позицию как системотехника, но в данном случае разговор идет о процессах выполняющихся не в ядре, и оперирующими виртуальной памятью.
>a method of conserving memory space by directing accesses to what would ordinarily be copies of a piece of data to a single instance instead, by using virtual memory mappings or with explicit support of the program in question.Перевожу:
метод сохранения обьема памяти через перенаправления доступа к тому, что в обычном случае было бы копиями частей данных, к единому екземпляру (данных), используя отображение памяти или с непосредственной поддержкой рассматриваемой программыКлючевое место здесь - "единый екземпляр". Т.е. одна и та же страница памяти, которая доступна различным процессам.
>так все таки применимо - или тут разные процессы (на разных нодах) не получают доступ к общим данным?
К общим данным - да. Которые будут представлены в виде нескольких копий, как минимум по одной на каждой ноде.
К одной и той же странице памяти - разумеется нет.Именно общая страница памяти, отображенная в адресное простраство разных процессов, представляет из себя shared memory, независимо от того по какому физическому адресу она находится после подгрузки из файла или свопа пейджером.
>А с точки зрения виртуальной памяти нет никакой разницы - соединили микросхемы в 2х нодах физически или логически.
Микросхемы в двух нодах нельзя соединить физически. Данные из одной ноды можно скопировать на другую множеством способом, но ни один из них не имеет отношения к понятию shared memory, потому что копирование по определению не представляет собою shared instance.
>ps. я понимаю вашу позицию как системотехника, но в данном случае разговор идет о процессах выполняющихся не в ядре, и оперирующими виртуальной памятью.
А я Вашей позиции не понимаю. Я абсолютно доступным языком обьяснил что такое shared memory и почему mmap over network fs им не является. И контекст выполнения процесса (ядро/не ядро) в данном вопросе не играет никакой роли.
PS. Не все то shared memory, что делается через mmap, хотя и может казаться им.
Сознательно игнорируете первую строчку определения данного wiki?
>>a method of inter-process communication (IPC), i.e. a way of exchanging data between programs running at the same time. One process will create an area in RAM which other processes can access, or
>>с дополнительными уточнениями из hardware.
>>Cache coherence: Whenever one cache is updated with information that may be used by other processors, the change needs to be reflected to the other processors, otherwise the different processors will be working with incoherent data (see cache coherence and memory coherence).
>>>замените processors на nodes - логика не изменится не на грамм.
PS. в определенных условиях будет сущестовать ровно 1 страничка памяти которая будет прыгать между разными нодами. это взятие лока с PW (типы локов в wikipedia DLM) (file open mode - O_WRITE). При это любое чтение/запись на другой ноде будет конфликтовать с этим локом и вызывать удаление страницы из мапинга на ноде 1 и создание страницы на ноде 2.
>One process will create an area in RAM which other processes can accessповторюсь в который раз - процесс на второй ноде НЕ может получить доступ к "area in RAM", которую создал процесс на первой ноде - он (процесс на второй ноде) может получить доступ только к копии данных из этой area, которая (копия) будет предоставлена сетевой FS (или любым другим IPC методом).
>замените processors на nodes - логика не изменится не на грамм.
тут не могу возразить. С логической и топологической точки зрения кеши разных ядер процессора в классическом случае shared memory, и страницы памяти на удаленных нодах для Вашего mmap over net-fs - эквивалентны (в первом случае когерентность обеспечивается протоколом когерентности кешей ядер, во втором - средствами сетевой FS). Тогда почему бы не провести параллель между доступом к данным через цепочку L1-L2-RAM через FSB (QPI etc) и Process1:Node1-Internet-Node2:Process2 через tcp-сокет ?
Послушайте, так получается - все-все IPC логически еквивалентны shared memory ?!
Где-то есть какой-то екзепляр данных, другие процессы каким-то (неважно каким, логически все способы еквивалентны ведь) способом получает доступ к этим данным. Сможете это опровергнуть ?
>Мисье все знайка - доведу до твоего сведения - в TOP500 нет не одной машины с количеством ядер на одной ноде выше 32х.32 - уже не хило.
совсем до 48 не далеко. пока одни помои льют, время идёт и другие работают.
>Линукс на машинах Cray XT[3-5], IBM BG/L сводится к одной вещи - запускалка процессов.на моём ноуте - тоже.
>>Мисье все знайка - доведу до твоего сведения - в TOP500 нет не одной машины с количеством ядер на одной ноде выше 32х.
> 32 - уже не хило.16 или 32 был только в BG/L. Но там далеко не SMP, а POWER[5|6] + NUMA.
> совсем до 48 не далеко. пока одни помои льют, время идёт и
> другие работают.
>>Линукс на машинах Cray XT[3-5], IBM BG/L сводится к одной вещи - запускалка процессов.
> на моём ноуте - тоже.Да ну? что бы запустить 1 процесс который будет по сети работать ?:)
>16 или 32 был только в BG/L. Но там далеко не SMP, а POWER[5|6] + NUMA.ха! это что-то меняет?
>Да ну?ну да.
>что бы запустить 1 процесс который будет по сети работать ?:)угу. браузер. как в твоём случае.
чтобы скопировать с вики ничего не доказывающую информацию.
>>16 или 32 был только в BG/L. Но там далеко не SMP, а POWER[5|6] + NUMA.
> ха! это что-то меняет?Очень многое.
ничего это не меняет.
если есть что сказать - ю а велком. а так - в сад.
> ничего это не меняет.
> если есть что сказать - ю а велком. а так - в
> сад.Если не понимаете то точно в сад - учиться :)
различия в подходах к SMP и NUMA я думаю сможете и без меня в wiki прочитать.
помоему на страничке с NUMA как раз и описывались все проблемы традиционной SMP архитектуры - почему стали использовать NUMA.
вы действительно не понимаете или прикидываетесь?
если последнее, то очень умело.
чтобы расставить точки на И - объясните какое отношение всё вышесказанное имеет к сабжу.
самое что не наесть прямое - в тексте рассматриваются проблемы _SMP_ систем
которых не может быть в NUMA, если программировать правильно.
> вы действительно не понимаете или прикидываетесь?
> если последнее, то очень умело.
> чтобы расставить точки на И - объясните какое отношение всё вышесказанное имеет
> к сабжу.в частности - частое и бездумное использование atomic - создает неявные memory barier которые вызывают cache flush со всех CPU в системе, чем перегружают каналы связи.
А linux kernel славился бездумным использованием atomic - благо дело при малом количестве CPU и i386 архитектуре это очень дешево (hint поищите патч ника который вычищал atomic из dcache - там приводились цифры насколько вырасла производительность после этого).
Всезнайка наверное не читал pdf по ссылке в новости? А ведь стоило бы...
Чтобы не утруждать ваши, без преувеличения, "гениальные" мозги, процитирую здесь только conclusion:This paper analyzes the scaling behavior of a traditional operating system (Linux 2.6.35-rc5) on a 48-core computer with a set of applications that are designed for parallel execution and use kernel services. We find that we can remove most kernel bottlenecks that the applications stress by modifying the applications or kernel slightly. Except for sloppy counters, most of our changes are applications of standard parallel programming techniques. Although our study has a number of limitations (e.g., real application deployments may be bottlenecked by I/O), the results suggest that traditional kernel designs may be compatible with achieving scalability on multicore computers. The MOSBENCH applications are publicly available at http://pdos.csail.mit.edu/mosbench/, so that future work can investigate this hypothesis further.
>Мисье все знайка - доведу до твоего сведения - в TOP500 нет не одной машины с количеством ядер на одной ноде выше 32х.http://top500.org/system/8385 Ранее в списке был Росгидромет, где было более 32 ядер.
>То как linux kernel пытались запускать на SGI Altrix - это отдельная и грустная история - он там просто не работал, ибо инициализация 512 ядер занимала дохрена времени и накладные расходы вобщем-то тоже.
Работал, работает и будет работать... не надо врать... И времени эта "инициализация" занимала не много.... и даже на 1024 ядрах.
>Линукс на машинах Cray XT[3-5], IBM BG/L сводится к одной вещи - запускалка процессов.
А что оно ещё должно делать?? Угадывать, что вы хотите посчитать и сразу выдавать результат???
>>Мисье все знайка - доведу до твоего сведения - в TOP500 нет не одной машины с количеством ядер на одной ноде выше 32х.
> http://top500.org/system/8385Что хотели то сказать ссылкой на Altrix? Он есть и в Oak ridge - там где TOP1 стоит (Ягуар и пару машинок поменьше) - но по факту - "стоит" а не работает.
> Ранее в списке был Росгидромет, где было более 32 ядер.
был :) Но что IBM что Cray почему-то пошли по пути 2-4 cpu и количество ядер не выше 32х.
Видимо путь который пораждает большие NUMA системы - оказался не столь привлекательным?
>>То как linux kernel пытались запускать на SGI Altrix - это отдельная и грустная история - он там просто не работал, ибо инициализация 512 ядер занимала дохрена времени и накладные расходы вобщем-то тоже.
> Работал, работает и будет работать... не надо врать... И времени эта "инициализация"
> занимала не много.... и даже на 1024 ядрах.аха. всего около 10 минут. То то Altrix сейчас очень популярны.
>>Линукс на машинах Cray XT[3-5], IBM BG/L сводится к одной вещи - запускалка процессов.
> А что оно ещё должно делать?? Угадывать, что вы хотите посчитать и
> сразу выдавать результат???Ну как сказать :) когда попробуете скомплировать свой код под Cray XT - поймете.
>Что хотели то сказать ссылкой на Altrix? Он есть и в Oak ridge - там где TOP1 стоит (Ягуар и пару машинок поменьше) - но по факту - "стоит" а не работает.Вы сказали, что в списке нет - я вам показал, что есть.
>был :) Но что IBM что Cray почему-то пошли по пути 2-4 cpu и количество ядер не выше 32х.
Наверное потому, что технологически требуется доработка механизмов синхронизаций. Проще использовать стандартное решение. Опять же я вас удивлю, но IBM умеет соединять в единую SMP машину до 4-х 2-сокетных узлов.
>Видимо путь который пораждает большие NUMA системы - оказался не столь привлекательным?
А может быть дело было в том, что Itanium перестал развиваться??? Сейчас тоже самое делают на Xeon и решение покупается.... Из всех вендоров на рынке, только SGI делает большие NUMA системы.
>аха. всего около 10 минут. То то Altrix сейчас очень популярны.
10 минут на что?? На загрузку с нуля или на инициализацию всех модулей??? На 1024 ядрах это занимает около 10 минут, но 90% времени это инициализация I/O модулей. Смотря где, там где они нужны. Почему же тогда продажи этих систем не падают???
>Ну как сказать :) когда попробуете скомплировать свой код под Cray XT - поймете.
Ясно, как в анекдоте: "Штурман приборы. - 25 - что 25 - А что приборы". Вы решите сначала, что хотите сказать, а уже потом говорите, а не прыгайте по мыслям. Вопрос стоит так, что ещё, помимо запуска процессов, оно должно делать???
ну, имхо, в 48-ядерных в любом случае эффективность будет низкая: объём кэша не резиновый, а память и шина тормоза.
там, в принципе, выход только один: уменьшить разницу между характеристиками кэша и внешней памятью
> ну, имхо, в 48-ядерных в любом случае эффективность будет низкая: объём кэша
> не резиновый, а память и шина тормоза.Придется хреначить кучу каналов памяти (до тех пор пока не задолбутся разводить из на 10-слойных бутербродах по дикой цене). Или сделать кеш в который треды умещаются. Впрочем это будет довольно нишевой штукой. Не все задачи можно распараллелить на 48 потоков. Числокрушилки с кучей слабых ядер есть давно, но они являются довольно нишевыми штуками, интересным в сильно некоторых областях.
Например: брут известного MD5 хеша можно разложить на 48 процессоров без проблем, опробуя одновременно 48 разных вариантов. А попробуйте теперь разложить на 48 процессоров рассчет хеша ОДНОГО файла? Тут то и будут опаньки - результат зависит от предыдущего и ничего ускорить не выйдет. Ну и будет хэш считать 1 проц. А еще 47 будут курить бамбук и кушать электричество.
>... и кушать электричество.на самом деле нет.
вы никогда не задумывались почему темпиратура процессора зависит от того делает-ли он чтото или простаивает?
а зависит она потомучто умные дяденьки придумали как можно отключать (усыплять) неиспользуемые-в-данный-момент блоки процессора :-)
> вы никогда не задумывались почему темпиратура процессора зависит от того делает-ли он
> чтото или простаивает?Потому что CMOS схема кушает что-то только в момент переключения, сэр. Перезаряд емкостей. Чем чаще и больше переключений, тем больше кушается (есть еще впрочем токи утечек и прочая). Разумеется, можно поотключать лишние ядра или постопать им клок или снизить частоту клока. Но как-то вот в реально существующих general purpose процах это делается далеко не с максимальной эффективностью.
> а зависит она потомучто умные дяденьки придумали как можно отключать (усыплять) неиспользуемые-в-данный-момент
> блоки процессора :-)Собственно оно из особенностей схемотехники CMOS вытекает. А умные дяденьки к слову в general purpose процах не очень свою попу рвут на этот счет. В мелких микроконтроллерах, процессорах для мобилок и прочая на этот счет пыжатся намного сильнее. Поэтому хотя в теории вы и правы, на практике оно все-таки ближе к тому что я сказал, как минимум пока. Есть и всякие побочные грабли. Если источник питания проца должен вытянуть 48 ядер, тогда при работе 1 ядра он будет работать с недогрузом в десятки раз и его КПД опять же будет не ахтецкий. Хотя с этим научились частично бороться переключая число фаз преобразователя. Но еще ж есть основной блок питания например. К которому все это тоже применимо и там почему-то никто числом фаз преобразователей не щелкает. В общем реальная картина получается не такой же как идеальная.
Многоядерные системы были, есть и будут весьма специализированными девайсами, то есть ситуация простоя для них не актуальна, их создают под задачу часто.
> Многоядерные системы были, есть и будут весьма специализированными девайсами,Эээ ну 2...6 ядерные процессоры попадаются и у юзеров. В не слишком специализированных девайсах. Но простому юзеру весьма проблематично загрузить даже 6 ядер надолго.
>> Многоядерные системы были, есть и будут весьма специализированными девайсами,
> Эээ ну 2...6 ядерные процессоры попадаются и у юзеров. В не слишком
> специализированных девайсах. Но простому юзеру весьма проблематично загрузить даже 6 ядер
> надолго.У нас как бы речь было о 32 и более. Неточно высказался тогда,
"Многоядерные системы(много более 6 ядер) были, есть и будут весьма специализированными девайсами". Устроит?
> Устроит?Однозначно, Кэп.
Угу, что-то не слышал я ещё о реальных продающихся процах, отключающих ядра. А существующие, всё, что могут, так это понизить частоту макс. в 2-2.5 раза от стандартной (пример моего ноута 2 ГГц ->> 1 ГГц), ну и, по крайней мере, мобильные версии - чуть-чуть уменьшить напряжение тока (мой пример: 1.25 В ->> 0.95 В). Это, конечно же, не так плохо, но можно сильно лучше.
И насчёт "потребляющих во время переключений CMOS" вы правы - спецом не так давно проверял - выставил под Вистой программкой RMClock держать 2ГГц и напругу 1.25В, но при этом не нагружал ничем - так темп. с 38-44C поднималась до ~44-49C, вентилятор лишь немного повысил обороты, потом, дав работы 7-зипу, загрузив оба потока, обнаружил, повышение темп. уже до 56-61C и обороты уже поднялись выше среднего. Специально при этом следил за частотами видюшки - не изменялись (а вот темп. из-за близкого расположения и общей сист. охлаждения, поднялась на 8 градусов). Темп. комнаты не засекал, но дело было после полуночи и в комнате было прохладно. Летом, жарой, к этому всему можно добавлять +10C.
> Угу, что-то не слышал я ещё о реальных продающихся процах, отключающих ядра.
> А существующие, всё, что могут, так это понизить частоту макс. в
> 2-2.5 раза от стандартной (пример моего ноута 2 ГГц ->> 1
> ГГц)...угу на линухе у меня тоже почти так же, но на "другой системе" мой же этот же ноут - понижает в 21 раз: с 2100МГц до 100МГц....
не ровняйте все по линуксу....
"на правах лирического отступления..."
Там основные потери от скин эффекта.
>темпиратурабольше не нужно было писать
Они изобрели транспьютер?
Пусть не гонят!
Plan9 к этому давно уже готова!Манагеры МС взялись за аналитику?
При чем тут План9, который вообще никому не нужен?
И при чем тут манагеры МС? Исследование в MIT делали.
>Исследование в MIT делали.Наверное они грант хотят стрясти :).При том почему-то мне так кажется что если 48-ядерные процы станут нормой жизни то линуха всяко подтянут до нормальной работы и на этом хардваре. А куда они денутся то? Как начнут кастомеры всяких ораклов, айбиэмов и редхатов прессовать, так и раздуплятся... :)
> При чем тут План9, который вообще никому не нужен?если он не нужен лично вам, то это ничего не значит
> И при чем тут манагеры МС? Исследование в MIT делали.У вас все документальные данные в наличии со стророны МС, кому и за что они платят?
План9 - академическая сферовакуумная ОС. Что там к чему готово, я без понятия, но вам правильно говорят - он никому не нужен.Хотя как архитектурный образец, конечно, да. Их много. Inferno, Plan9, Singularity и прочие. Понадобится - на этой основе сделают что-то реально работающее.
тем не менее, архитектура архитектурой, но принципиальную не-распараллеливаемость многих задач это не отменяет.
> План9 - академическая сферовакуумная ОС. Что там к чему готово, я без
> понятия, но вам правильно говорят - он никому не нужен.А жаль :(
> Хотя как архитектурный образец, конечно, да. Их много. Inferno, Plan9, Singularity и
> прочие. Понадобится - на этой основе сделают что-то реально работающее.
> тем не менее, архитектура архитектурой, но принципиальную не-распараллеливаемость многих
> задач это не отменяет.Зато появляется новый абстрактный уровень не привязанный к конкретному железу.. вернее уже есть в лице ненужного плана9...
Да, есть принципиально не распараллеливаемые задачи, но много ли машин на которых считают одну единственную «МегаЗадачу»???
>Plan9 к этому давно уже готова!К чему готова? К обозначенной выше проблеме? Ни разу не готова. Ни по своей архитектуре, ни по текущей реализации, plan 9 не уделывает никакого современного наследника UNIX применительно к проблеме кучи ядер.
Долго же они приходили к этому мнению.
К счастью, Linux с открытыми драйверами и базовыми компонентами - готов к переменам, они возможны.
Для того, чтобы сделать то, что они имеют в виду, простым перепилом ведра не обойдешься. Там именно заново придется все писать
> Там именно заново придется все писатьПомнится Таненбаум в свое время очень ругался что линукс сильно завязан на аппаратные особенности i386. А сегодня у меня почему-то пачка железок с линуксом. И среди них ни одного i386 :). Только x64, ARM и MIPS почему-то. Такие вот чудеса истории.
При чем тут привязка к железу? Ну хорошо, попробуйте переделать ведро под модель а-ля Inferno, я посмотрю на это...
аналогия.
чем это хуже привязки к количеству камней?зы:
вопрос больше железячный - нужны более быстрые каналы между процами для начала.
а пока это больше ограничение архитектуры, чем ос.
> При чем тут привязка к железу?Просто в свое время линух за "непортабельность" ругали. А он возьми да и стань одной из наиболее портабельных операционок. Весьма иронично. Сегодня его ругают за то что на 48 ядрах не работает оптимально. Зато думаю что когда процы с 48 ядрами станут майнстримом (если вообще станут), линукс вероятно будет их поддерживать на ура. Вероятно даже лучше чем большая часть иных систем в этот же момент времени.
> Ну хорошо, попробуйте переделать ведро под модель а-ля Inferno, я посмотрю на это...
"А нафига?" Если кому-то будет надо чтобы работало на 48 ядрах нормально - и так допинают. Эволюционным методом вместо революционного. В конечном итоге - засчитывается все-таки практический результат, а не теоретическая крутизна. Потому что нечто может быть очень круто в теории но никогда вообще не оказаться реализовано на практике по разным причинам. Тогда оно будет всего лишь бесполезным артефактом. Как пример: орали все - микроядра, микроядра. В итоге в чистом виде они никому не впились. Зато появились гибридные ядра, гипервизоры и что там еще. Не то чтобы теория совсем стухла, но на практике оказалась совсем не такой как ее изначально сватали теоретики :)
мне интересно, userspace будут вообще пилить в сторону потоковости? tar, gzip, bzip - однопоточные. Есть многопоточные форки, но это форки, и они не всегда есть в дистрибутиве, и к тому же не совместимы на 100% по аргументам командной строки
> мне интересно, userspace будут вообще пилить в сторону потоковости? tar, gzip, bzip
> - однопоточные. Есть многопоточные форки, но это форки, и они не
> всегда есть в дистрибутиве, и к тому же не совместимы на
> 100% по аргументам командной строкиЕсли вам надо - возьмите и допилите совместимость. А "не всегда есть в дистрибутиве" - исключительно проблема дистрибутива.
>tar, gzip, bzip - однопоточныеlzma и xz. а tar - это не компрессор, ему и на одном ядре неплохо живётся.
По моему они на Minix и еже с ними намекают.
> По моему они на Minix и еже с ними намекают.Это тот же Unix, пусть в него и добавлены идеи 86-го года. :-)
А что? В Линуксе есть честный SMP?
нет, он врёт.
на 8 ядрах линейная зависимость. врёт зараза.
> Пока память используется, она не доступна для других задачА кеши у процессоров - типа для красоты? Или предлагается влупить 48 ядер, оперативку которая не может их прокачать, и кеша не добавлять? :) А так линуксный кернел уже с кучей тредов. Если они в кеш влезут - ну и ладушки. Алсо, не все задачи хорошо параллелятся. Задач которые могут эффективно размазаться на 48 ядер в природе в общем то не так уж и много.
>> Пока память используется, она не доступна для других задач
> А кеши у процессоров - типа для красоты? Или предлагается влупить 48
> ядер, оперативку которая не может их прокачать, и кеша не добавлять?
> :) А так линуксный кернел уже с кучей тредов. Если они
> в кеш влезут - ну и ладушки. Алсо, не все задачи
> хорошо параллелятся. Задач которые могут эффективно размазаться на 48 ядер в
> природе в общем то не так уж и много.Тем не менее он прав - проблема преувеличена. Как бы не случайно ли на будущее на новых многоядерных процах вводят общий увеличенный кэш третьего уровня и возможность контролировать частоты ядер отдельно? Да и при 48 ядрах производительность будет такая, что уже вряд ли кто-то будет обращать внимание на скорость системы\типичной среды окружения вообще, учитывая, к тому же, их относительную нетребовательность и моду переноса всего лишнего на видеокарты. Ну а тяжёлые специализированные задачи в абс. большинстве своём, как и "движущие прогресс" игры, отлично поддаются параллелизации (и давно в принципе уже "запараллелизованы") и упомянутые проблемы их касаются лишь частично. Ну и, наконец, они сами сказали, что несколько мелких исправлений устраняют большинство проблем.
Так к чему весь этот гудёж? :)
А не проще железячникам вместо увеличения количества ядер продолжать уменьшать техпроцессы, улучшать архитектуры, увеличивать частоты и кэш? А то опять к одноядерным процессорам придем, с кучей "внутренних ядер", "исполнительных блоков" или что-то в этом роде.
> А не проще железячникам вместо увеличения количества ядер продолжать уменьшать техпроцессы,
> улучшать архитектуры, увеличивать частоты и кэш? А то опять к одноядерным
> процессорам придем, с кучей "внутренних ядер", "исполнительных блоков" или что-то в
> этом роде.Дорого. Нарастить число ядер дешевле, чем перевести линию на новый техпроцесс.
>> А не проще железячникам вместо увеличения количества ядер продолжать уменьшать техпроцессы,
>> улучшать архитектуры, увеличивать частоты и кэш? А то опять к одноядерным
>> процессорам придем, с кучей "внутренних ядер", "исполнительных блоков" или что-то в
>> этом роде.
> Дорого. Нарастить число ядер дешевле, чем перевести линию на новый техпроцесс.При чем тут дорого - поучите физику - поймете почему техпроцесс уменьшать уже некуда!
Как некуда? Уже 22 на подходе, 32 нм давно есть в серийном производстве, а Интел все еще свои "энергоэффективные" АТОМы лепит на 45.
Думается, 11 нм тоже не проблема.
> Как некуда? Уже 22 на подходе, 32 нм давно есть в серийном
> производстве, а Интел все еще свои "энергоэффективные" АТОМы лепит на 45.
> Думается, 11 нм тоже не проблема.уже много лет назад кто-то из великих умов из физических лабораторий уже предсказывал транзистор из трех атомов... а некоторые только до 7-ми добрались http://www.innov.ru/news-it/2010/05/24/2/
http://www.modlabs.net/articles/tranzistor-iz-7-atomov-uchjo...
ну и что - дальше-то нужно менять принцип транзистора и уменьшение техпроцесса не поможет уже...
Вот, кстати, интересно http://www.3dnews.ru/news/ibm_11_nm_ne_predel_dlya_kremniya/
> Вот, кстати, интересно http://www.3dnews.ru/news/ibm_11_nm_ne_predel_dlya_kremniya/Ну когда сделают - тогда и посмотрим, НО все-равно это тупиковая ветвь - это ясно как "Божий день"!
>> Вот, кстати, интересно http://www.3dnews.ru/news/ibm_11_nm_ne_predel_dlya_kremniya/
> Ну когда сделают - тогда и посмотрим, НО все-равно это тупиковая ветвь
> - это ясно как "Божий день"!Так любая ветвь тупикова, вопрос только, где и когда мы на этот тупик наткнёмся. А если до этого тупика ещё как минимум неск. техпроцессов и много лет ещё - то нечего и тревогу бить почём зря. Вот и не спешат всякие Интелы с заменой принципа транзистора, придёт время - выход найдётся. Вон с графеном проводят эксперименты и уже выяснили ни одну его сверхспособность.
>>> Вот, кстати, интересно http://www.3dnews.ru/news/ibm_11_nm_ne_predel_dlya_kremniya/
>> Ну когда сделают - тогда и посмотрим, НО все-равно это тупиковая ветвь
>> - это ясно как "Божий день"!
> Так любая ветвь тупикова, вопрос только, где и когда мы на этот
> тупик наткнёмся. А если до этого тупика ещё как минимум неск.
> техпроцессов и много лет ещё - то нечего и тревогу бить
> почём зря. Вот и не спешат всякие Интелы с заменой принципа
> транзистора, придёт время - выход найдётся. Вон с графеном проводят эксперименты
> и уже выяснили ни одну его сверхспособность.уже наткнулись - просто в производство еще не все запускают - старьё еще нужно со складов распродать...
> ну и что - дальше-то нужно менять принцип транзистораУгу, они уже вон на 3 ГГц застряли и что-то не больно то спешат даже просто кремний выбрасывать :). Вместо этого они решили в параллельные вычисления поиграть. И теперь у нас пузомерка не гигагерцы уже а количество ядер. А когда юзерам не станет нужно столько ядер - они начнут соревноваться в чем-нибудь еще. Ну например кто больше MIPS/Watt выжмет. Или там еще чего.
>> ну и что - дальше-то нужно менять принцип транзистора
> Угу, они уже вон на 3 ГГц застряли и что-то не больно
> то спешат даже просто кремний выбрасывать :). Вместо этого они решили
> в параллельные вычисления поиграть. И теперь у нас пузомерка не гигагерцы
> уже а количество ядер. А когда юзерам не станет нужно столько
> ядер - они начнут соревноваться в чем-нибудь еще. Ну например кто
> больше MIPS/Watt выжмет. Или там еще чего.Лучше бы сразу начали в "кто больше MIPS/Watt выжмет" играть.
> Лучше бы сразу начали в "кто больше MIPS/Watt выжмет" играть.Да уж :). Но как-то так получилось что это стало вообще упоминаться как характеристика лишь сравнительно недавно.
>> ну и что - дальше-то нужно менять принцип транзистора
> Угу, они уже вон на 3 ГГц застряли и что-то не больно
> то спешат даже просто кремний выбрасывать :). Вместо этого они решили
> в параллельные вычисления поиграть. И теперь у нас пузомерка не гигагерцы
> уже а количество ядер. А когда юзерам не станет нужно столько
> ядер - они начнут соревноваться в чем-нибудь еще. Ну например кто
> больше MIPS/Watt выжмет. Или там еще чего.Вообще-то это очень условно "застряли". Выходили же модели с 4+ ГГц. А "энтузиасты" разгоняют и на 5, и на 6 и выше ГГц (правда уже с экзотическими и непрактичными системами охлаждения и проч.) Просто чтоб обеспечить достаточный выход стабильно работающих процев на таких частотах надо несколько усложнить и удорожать процесс производства, что несомненно им не в пользу, вот они и пошли по пути, позволяющему временно на эту проблему "забить" - пути параллелизации (ну и плюс всякие оптимизации, 64-битность и проч.) Непонятно, конечно, зачем они раньше всё это игнорировали\не замечали\тупые манагеры виноваты... Но в будущем точь так же дойдут до ограничивающего кол. ядер на кристалле фактора, и всё равно придётся либо менять материалы, усложнить и удорожать, либо вообще кардинально поменять технологии производства.
>[оверквотинг удален]
>> то спешат даже просто кремний выбрасывать :). Вместо этого они решили
>> в параллельные вычисления поиграть. И теперь у нас пузомерка не гигагерцы
>> уже а количество ядер. А когда юзерам не станет нужно столько
>> ядер - они начнут соревноваться в чем-нибудь еще. Ну например кто
>> больше MIPS/Watt выжмет. Или там еще чего.
> Вообще-то это очень условно "застряли". Выходили же модели с 4+ ГГц. А
> "энтузиасты" разгоняют и на 5, и на 6 и выше ГГц
> (правда уже с экзотическими и непрактичными системами охлаждения и проч.) Просто
> чтоб обеспечить достаточный выход стабильно работающих процев на таких частотах надо
> несколько усложнить и удорожать процесс производства,чушь.... откройте термодинамику да почитайте, если осилите....
всем доброго времени суток. господин fidaj на самом деле прав. несколько лет назад читал в журнале "в мире науки" (руссифицированная версия the american scientific), что уменьшать до бесконечности не получится. уже, если мне не изменяет память, где-то около 2 нм. подойдут к физическому пределу, меньше которого то ли утечки тока, то ли квантовые эффекты будут настолько велики, что нельзя будет обеспечить стабильной работы. поэтому уже приличное время в лабораториях мира ведутся исследования в направлениях квантовых компьютеров, биокомпьютеров и прочих
> всем доброго времени суток. господин fidaj на самом деле прав. несколько лет
> назад читал в журнале "в мире науки" (руссифицированная версия the american
> scientific), что уменьшать до бесконечности не получится. уже, если мне не
> изменяет память, где-то около 2 нм. подойдут к физическому пределу, меньше
> которого то ли утечки тока, то ли квантовые эффекты будут настолько
> велики, что нельзя будет обеспечить стабильной работы. поэтому уже приличное время
> в лабораториях мира ведутся исследования в направлениях квантовых компьютеров, биокомпьютеров
> и прочихА вы сами представьте - при таких размерах эти транзисторы нужно будет разглядывать в электронный микроскоп, так что это уже будет не просто там квантовые эффекты, а химия - такие транзисторы будут рассыпаться пачками при малейших неточностях при производстве, при попадании на них микро-нанопылинки, дико реагировать на мельчайшие "химические раздражители" - тут уже просто напросто практически перестают действовать законы физики твёрдых тел. А токи не то что "утекают", а вообще норовят без спроса перебежать в соседние не-то-что транзисторы, а я бы даже сказал соединения из пары атомов\молекул.
Я думаю никто на квантовые "вычисления" в ближайшее время не перейдёт, скорее будут опробывать новые материалы, допиливать старые технологии, испытывать в деле графен и т.д.
>[оверквотинг удален]
>> назад читал в журнале "в мире науки" (руссифицированная версия the american
>> scientific), что уменьшать до бесконечности не получится. уже, если мне не
>> изменяет память, где-то около 2 нм. подойдут к физическому пределу, меньше
>> которого то ли утечки тока, то ли квантовые эффекты будут настолько
>> велики, что нельзя будет обеспечить стабильной работы. поэтому уже приличное время
>> в лабораториях мира ведутся исследования в направлениях квантовых компьютеров, биокомпьютеров
>> и прочих
> А вы сами представьте - при таких размерах эти транзисторы нужно будет
> разглядывать в электронный микроскоп, так что это уже будет не просто
> там квантовые эффекты, а химия - ...ну и БРЕД!!!
какая химия????
не порите чушь!
>[оверквотинг удален]
> разглядывать в электронный микроскоп, так что это уже будет не просто
> там квантовые эффекты, а химия - такие транзисторы будут рассыпаться пачками
> при малейших неточностях при производстве, при попадании на них микро-нанопылинки, дико
> реагировать на мельчайшие "химические раздражители" - тут уже просто напросто практически
> перестают действовать законы физики твёрдых тел. А токи не то что
> "утекают", а вообще норовят без спроса перебежать в соседние не-то-что транзисторы,
> а я бы даже сказал соединения из пары атомов\молекул.
> Я думаю никто на квантовые "вычисления" в ближайшее время не перейдёт, скорее
> будут опробывать новые материалы, допиливать старые технологии, испытывать в деле графен
> и т.д.
Так пока что там небольшой технологический(?) тупичок. Частоты повысить не получается, а если даже немного повысить, то это будет не процессор, а обогреватель, что не соответствует современным требованиям по энергосбережению. Да и из старых архитектур надо еще денег повыжимать - зачем на исследования и разработку тратиться. Вообщем куча факторов, искуственно тормозящих развитие технологий. А от кучи ядер толку тоже немного - как минимум для начала надо перейти на быструю RAM не конденсаторного типа, а оно пока в разработке............
> начала надо перейти на быструю RAM не конденсаторного типа,Да вообще-то SRAM уже не одно десятилетие назад придуман. Только при том же числе транзисторов он в несколько раз менее емкий получается. Поэтому статичная оперативка - круто, быстро ... и чертовски дорого. И именно поэтому никто ей и не пользуется.
> А не проще железячникам вместо увеличения количества ядер продолжать уменьшать техпроцессы,...Не проще... они уже уперлись в атомы... меньше (лептоны и кварки) пока не получается...
не знаю, насколько это реально и какие аналитики это писали :) , но почитайте, кто не видел еще: http://www.cnews.ru/news/top/index.shtml?2010/08/13/405037
> не знаю, насколько это реально и какие аналитики это писали :) ,
> но почитайте, кто не видел еще: http://www.cnews.ru/news/top/index.shtml?2010/08/13/405037...К настоящему моменту сумма контрактов составила более $76,6 млн.
... стоит задача к 2018 г.
... по 11 лямов в год.АвтоВАЗ наверно больше тратит :)
http://www.osp.ru/os/2010/05/13003034/
В общем, это проблема не OS, а производителей процессоров, контроллеров I/O, материнок...А чё они хотели??? Имея типовые проекты 14-и этажек, построить небосрёб в 1000 этажей, с одним лифтом??? :)
И при этои оптимизироваться должны жители - создать расписание поездок на лифте,
установить правила - чтоб жители ближайших пяти между собой этажей группировались
для поездки как вниз так и вверх, так же группировались по весу, для оптимального
заполнения лифта и, как следствие, увеличение траффика. Каждую вторую поездку лифт
будет останавливаться только на чётных этажах. Оптимизировать по количеству запросов
на обслуживание - если, к примеру, на 205 этаже сгруппировались 10 человек,
на 378 - 8, ...., а на 998 - один, то с вероятностью 99.8 он из дома не выйдет :)
ЖУЙ ВАМ!!! ДЕЛАЙТЕ НОРМАЛЬНЫЕ КОМПЫ И ПРОЦЕССОРЫ!!!
>> вообщето вся тема -- в 70% сообщений только и говорит про кэши
>> и шины.. как это относиться к OS ?
> А что, предлагается рассматривать абстрактную ОС в вакууме, в отрыве от реально
> существующего железа? :)Это он к тому, что 70% гимороя из-за железа.
Авторы же исследования утверждают, что операционки не готовы к многоядерному фаршу!Нельзя быть двум человекам в одном месте, в одно и тоже время,
если входить через одну дверь! (с) Я
> доказать не может.Жизненно же. Попробуйте распараллелить обсчет MD5 хеша для *одного* большого файла на 48 процов? Ну и как, получается? :)
Ну вот конкретно md5 этот не параллелится. Ну и что? Компьютеры нынче отнюдь не однозадачные, масса всего параллельно крутится - заче параллелить один алгоритм, когда разных одновременно орда крутится?
>> доказать не может.
> Жизненно же. Попробуйте распараллелить обсчет MD5 хеша для *одного* большого файла на
> 48 процов? Ну и как, получается? :)А Вы попробуйте за итерацию подобрать хэш? Ну и как, получается? :)
И явно 48 не обойдется подбор вне зависимости от размера файла.
Неудачный пример.
> Неудачный пример.Так проблема в том что в реальном мире дофига этих "неудачных примеров", что и является той ложкой дегтя в бочке с медом многоядерности ;). Поэтому сделав 48-ядерный процессор есть риск обнаружить что спрос на него не такой уж и высокий (т.к. большая часть юзеров с их типовыми задачами просто не могут столько ядер поюзать). Будет еще один итаник? :)
Надо на уровень выше думать, а не задачи, успешно решающиеся первопнями раздувать на 3 порядка. Зачем вам md5 терабайта? Чтобы повреждение данных обнаружить? Ну обнаружите, и что - будете терабайт перекачивать? Не смешите. Разбейте на блоки и считайте, и параллельте хоть на 500 ядер.
> на блоки и считайте, и параллельте хоть на 500 ядер.Однозначно! Только вот...
1) А 500 винчей - это нормально? Ну или толку то от 500 ядер, если прогрузится аж пяток ядер, а больше накопитель все-равно не выжимает читать? :) В общем то 500 ядер подразумевают еще и подсистему памяти и ввода-вывода способные их такие прокормить. А с этим как-то пока не очень. Как-то туго себе представляется майнстримовый компьютер с 500-канальной памятью. В суперкомпьютерах на такое могут наверное распереться но в штучных тиражах, да и есть менее геморные методы достижения сравнимой производительности, не требующие таких изгалений и вполне себе успешные, наконец.
2) Надо еще убедить весь мир делать так же. Перейти на такие протоколы/форматы данных и прочая. В принципе это возможно. Остается только вопрос - а захочет ли мир думать вот так? Или вы будете в гордом одиночестве сравнивать ваш параллельный md5 сами с собой. А скачав терабайтный файл с ремотного сервера ... будете по старинке жевать его в 1 поток, жутко чертыхаясь на то что суперпроц с его 48 ядрами обладает довольно хилыми по отдельности ядрами. В итоге желающих покупать 48-ядерные суперпроцы может оказаться как-то маловато и они могут загнуться и/или остаться штучными решениями.
Куда то вы не туда повели, сами говорили о спецзаточенности многоядерников, и сами теперь рассматриваете их через призму универсальных, обывательских можно сказать, систем.
MD5 - это конечно не аргумент...
И один файл - это тоже не аргумент. :)То, что пока мало задач, которые могут эффективно использовать многоядерность - это вопрос времени. Раньше любая игрушка умещалась на FDD три раза, и все мучались вопросом - чем же можно загрузить 4 мегабайта памяти на крутых и никому не доступных x386... :)
Сейчас такие вопросы не стоят, благополучно загрузили...
Будет 1000 ядер - возникнут и алгоритмы, которые смогут их эффективно загрузить. И линукс не заставит себя ждать... за 5 лет они его 3 раза полностью переписать успеют. :)
В целом - лаконично, но врядле это проблема "производителей процессоров, контроллеров I/O, материнок", нет лучше инструмента для копания, чем лопата, пока у тебя две руки и ноги, с увеличением конечностей эффективность использования будет падать, (неужели чтобы это понять нужно быть Исследователем из Массачусетского Технологического института...)Будет ли эффективным писать новую ОС для эффективной работы на 1000 ядерном проце?
А если вспомнить про виртуализацию.. видимо, они там в институте чета покурили и их на панику прибило, - "о боже, небо падает".
> Рост числа процессорных ядер приведет к необходимости смены архитектуры ОСНовости от Капитана Очевидность...
Не прошло и n лет как до них дошло...
Я не понял: так надо для второго ядра компилировать второе ядро, или нет?!
А, теперь понятно, что у тебя всё так вечно тормозит :))
Каждому ядру по ядру!
---А ваще, если сделаешь 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]
...
> Каждому ядру по ядру!По два "ядра", и за ошибки отрывать по одному.
Интересно, а как заставить работать XP на многоядерных процессорах? (она же в отличие от "7" не может этого делать и заодно "7" тяжелее ее). Например можно ли создать такое ПО, которое бы для XP это могло бы делать? А то ведь есть же ПО, которое позволяет использовать более 2 Гб оперативной памяти в 32битных ОС.
У AMD есть драйвер, оптимизирующий работу с несколькими процессорами, так как сам Windows это делает хуже. Драйвер, кстати, творит чудеса.
Ну как-как... Разработчики программ добавляют возможность использования нескольких ядер процессора, оптимизируя тем самым их выполнение. Не удивлюсь, если Windows-пользователи с радостью готовы отдать одно процессорное ядро антивирусу. Я бы посмеялся.
Или ты имеешь в виду основные системные библиотеки? Не знаю, что с ними не так. Если даже системная программа не умеет распараллеливаться, попутно запуститься другая, которая займёт второе, третье, четвёртое, пятое, шестое ядро... Была поддержка многоядерности в XP, была. Потому что раньше были популярны многопроцессорные конфигурации. НЕ многоядерные, а многопроцессорные. На сервере, например.
Если имеется в виду программа AMD DualCore Optimizer,
то для Phenom II, Athlon II эта программа не нужнаЧто касается многоядерных конфигураций то Windows XP начали делать в то время когда их не было
Для 100-ядерных систем сделают Linux kernel 2.8 :)
Да уж пусть его 3.0.X обзывают. А то у людей только что приходящих в Linux создаётся впечатление, что ядро очень медленно развивается: как было 10 лет назад 2.*, так и осталось.
> Да уж пусть его 3.0.X обзывают. А то у людей только что
> приходящих в Linux создаётся впечатление, что ядро очень медленно развивается: как
> было 10 лет назад 2.*, так и осталось.ага, 5 споловиной в квадрате, если у людей мозга нет понять почему..., или пусть убунту пользуют она аж 10.х. уже, аж на три поколения круче виндовс7 этож кокая моща,
У Меня вопрос. Вы тут про параллельное выполнение одного алгоритма говорите...
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-а диска. Один быстрый, не ёмкий и исключительно под ОСь, а другой исключительно под файлопомойку.
> А вообще Я не представляю как при скорости чтения до ~150Мб/сек 30-50
> процессов ОДНОВРЕМЕННО будут читать из диска разные данные, причём из разных
> областей.
> Видимо не долго жить жёстким под ОСь.процессоры уже ооо-чень давно ничего с дисков не "читают"...
>> А вообще Я не представляю как при скорости чтения до ~150Мб/сек 30-50
>> процессов ОДНОВРЕМЕННО будут читать из диска разные данные, причём из разных
>> областей.
>> Видимо не долго жить жёстким под ОСь.
> процессоры уже ооо-чень давно ничего с дисков не "читают"......а есть различия?:
процессов(программ) и процессоров...Или у Вас волшебные OpenOffice, Firefox, mc, Kate, Mplayer, etc... с диска ничего не читают/пишут?
>>> А вообще Я не представляю как при скорости чтения до ~150Мб/сек 30-50
>>> процессов ОДНОВРЕМЕННО будут читать из диска разные данные, причём из разных
>>> областей.
>>> Видимо не долго жить жёстким под ОСь.
>> процессоры уже ооо-чень давно ничего с дисков не "читают"...
> ...а есть различия?:
> процессов(программ) и процессоров...
> Или у Вас волшебные OpenOffice, Firefox, mc, Kate, Mplayer, etc... с диска
> ничего не читают/пишут?уупс - я о другом :)
> Я так вижу, что в ящике будет 2-а диска. Один быстрый, не
> ёмкий и исключительно под ОСь, а другой исключительно под файлопомойку.Это сейчас только такое извращение у некоторых есть. Покупают интеловские SSD чисто под систему, и терабайтники под файлопомойку. Потом то уж должны же уйти в мир иной эти магнитные крутящиеся механизмы (вместе с оптическими дисками), а их место займут подешевевшие и налаженные SSD диски с крутыми и быстрыми интерфейсами (думается, SATA тоже уйдет как раритет :) )
А вот когда серийное производство в Китае началось бы этих SSDшек, то их шлепали бы как пирожки, тем более, что там меньше нужно железа и к качеству менее критично ввиду отсутствия механики.
> Хм... Tasks: 159 totalНет, это. Вот это - 2 running. Правда, тут потоки не считаются.
О вас с 2 задачами речь вообще не идет, вы могли бы и на первопнях сидеть на своих печатных машинках.> А вообще Я не представляю как при скорости чтения до ~150Мб/сек 30-50
> процессов ОДНОВРЕМЕННО будут читать из диска разные данные, причём из разных
> областей.Да будет вам известно, нормальные CPU-hungry задачи ничего не читают с диска. Более того, они даже из памяти ничего не читают - все в регистрах и кэше, иначе быстро не получится, сколько ядер не пихай.
Solaris 10 + UltraSPARK T1 8 cores x 4 threads (= 32 threads total)2005-й год, древняя технология по современным меркам
http://ru.sun.com/products/servers/highend/m9000/index.jspСодержит 32 или 64 высокопроизводительных процессоров SPARC64 VI (двухъядерных) или SPARC64 VII (четырехъядерных) и до 2 ТБ системной памяти
Итого 256 ядер
Г..но эти ваши лялихи
Ещё с год назад читал про это от представителей Microsoft (про будущие Windows). Основная идея была в том, что эффективнее будет целиком отдавать часть ядер каждому процессу.
Как-то заторможенно они это исследование решили провести...
> Ещё с год назад читал про это от представителей Microsoft (про будущие
> Windows). Основная идея была в том, что эффективнее будет целиком отдавать
> часть ядер каждому процессу.
> Как-то заторможенно они это исследование решили провести...ИМХО это мало что даст, "бутылочное горлышко" в другом месте будет, не более.
Линейной прибавки производительности не достичь:)
> Ещё с год назад читал про это от представителей MicrosoftАга, а у них affinity mask до сих пор в long'е. На 32 битах 32 ядра, на 64 битах 64, больше хочешь-не хочешь ничего не будет :)))
Думается, из всего этого количества байт, что мы все вбили здесь, легко можно сварганить патч для ядра с требуемым для решения этой проблемы функционалом.
Жаль лишь, что это байты скорее от миллиона мартышек, что пытаются написать "Войну и Мир", а не от того, кто в состоянии этот патч.
> Жаль лишь, что это байты скорее от миллиона мартышек, что пытаются написать
> "Войну и Мир", а не от того, кто в состоянии этот
> патч.Какой "Война и Мир"? Мы тут все максимум пытаемся по... самолюбие почесать и развлекаемся немного. Любая серьезная тема будет обсуждаться в личке или еще где.