форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
Сообщение от opennews (??) on 02-Окт-10, 15:57
Исследователи из Массачусетского Технологического института пришли к выводу (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
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

2. "Рост числа процессорных ядер приведет к необходимости смены ..."	+2 +/–
Сообщение от vvnab on 02-Окт-10, 16:16
DragonFlyBSD?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	62. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Vitaly_loki (ok) on 02-Окт-10, 21:48
	Я именно о ней и подумал, читая эту новость )
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	77. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Aquarius (ok) on 03-Окт-10, 00:07
	а что в ней на этот предмет?
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	84. "Рост числа процессорных ядер приведет к необходимости смены ..."	–3 +/–
	Сообщение от аноним on 03-Окт-10, 01:01
	а то. зайдите на сайт и прочитайте.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	97. "Рост числа процессорных ядер приведет к необходимости смены ..."	+5 +/–
	Сообщение от Aquarius (ok) on 03-Окт-10, 08:57
	> а то. зайдите на сайт и прочитайте. то что они от блокировок принялись избавляться сразу после форка и сейчас, скорее всего, избавились совсем? так это я и без их сайта знаю а нельзя просто прямо ответить на прямо заданный вопрос?
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	173. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от www2 (??) on 12-Окт-10, 15:19
	А в DragonFly принята несколько другая парадигма многопроцессорной системы. Там у каждого ядра есть свой планировщик. Поэтому в пределах одного планировщика получается практически однозадачная система, которой не нужны блокировки. В случае же если необходимо обратиться к ресурсу, закреплённому за другим процессором, процесс либо сам мигрирует на этот процессор либо отправляет запрос диспетчеру ресурса, работающему на этом процессоре. Запрос представляет собой сообщение, которое складывается в очередь сообщений диспетчера ресурса. Диспетчер ресурса обрабатывает сообщения по очереди и отвечает на них. Процесс сам решает, стоит ли ему ждать ответа на сообщение или стоит обработать ответ на сообщение асинхронно, продолжая выполнять другую работу. Например, есть жёсткий диск, есть драйвер жёсткого диска. Этот драйвер является отдельным процессом и он привязан к одному процессору. На другом процессоре этот же драйвер запуститься не может, а на том же самом процессоре драйвер-процесс не сможет сам себя вытеснить. Все обращения к жёсткому диску попадают в виде сообщений в очередь сообщений драйвера-процесса и обрабатываются по очереди. Всё это существенно отличается от парадигмы реентерабельности единого образа ядра, когда любой процесс может попытаться обратиться к ресурсу любого процессора. При этом приходится постоянно проверять доступность ресурса и блокировать его.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	174. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Vitaly_loki (ok) on 27-Окт-10, 15:01
	>[оверквотинг удален] > или стоит обработать ответ на сообщение асинхронно, продолжая выполнять другую работу. > Например, есть жёсткий диск, есть драйвер жёсткого диска. Этот драйвер является отдельным > процессом и он привязан к одному процессору. На другом процессоре этот > же драйвер запуститься не может, а на том же самом процессоре > драйвер-процесс не сможет сам себя вытеснить. Все обращения к жёсткому диску > попадают в виде сообщений в очередь сообщений драйвера-процесса и обрабатываются по > очереди. > Всё это существенно отличается от парадигмы реентерабельности единого образа ядра, когда > любой процесс может попытаться обратиться к ресурсу любого процессора. При этом > приходится постоянно проверять доступность ресурса и блокировать его. Всё верно! Если сказать простыми словами, то там используются LWKT (Light Weight Kernel Threads), т.е. каждый процесс обладает собственным планировщиком. Насколько я помню, именно из-за реализации этиз концепций Диллон и ушел из FreeBSD.
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

3. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
Сообщение от Аноним (??) on 02-Окт-10, 16:20
Результаты исследования: http://pdos.csail.mit.edu/papers/linux:osdi10.pdf
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	95. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Vkni on 03-Окт-10, 08:23
	> Результаты исследования: 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. Т.е. "Бобёр, выдыхай".
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

4. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
Сообщение от only you on 02-Окт-10, 16:23
принципиально новый Linux? :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	140. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от andr.ru on 04-Окт-10, 09:48
	Принципиально старый Plan9 https://researcher.ibm.com/researcher/view_project.php?id=1271 http://www.vitanuova.com/ Линукс сакс
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	141. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от fr0ster (ok) on 04-Окт-10, 09:52
	> Принципиально старый Plan9 > https://researcher.ibm.com/researcher/view_project.php?id=1271 > http://www.vitanuova.com/ > Линукс сакс Да, линукс полное г по сравнению с планом, по мнению "спицалистов" его курить нельзя. Вы План9 часто видели в промышленной эксплуатации? Вот когда какая то фича будет востребована, тогда она как тут говорилось и появится в Линуксе, так как Линукс не модой руководствуется, а практическими нуждами, как впрочем и любая нелабораторная ОСь
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	154. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от User294 (ok) on 05-Окт-10, 05:38
	> Да, линукс полное г по сравнению с планом, по мнению "спицалистов" его > курить нельзя. Крутой велосипед с турбонаддувом. Правда на улицах почему-то попадаются менее крутые концепты обычно. Да, не всем дано понять круть турбонаддува в велосипеде. Велосипеды без турбонаддува - сакс.
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	163. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от fr0ster (ok) on 05-Окт-10, 08:17
	>> Да, линукс полное г по сравнению с планом, по мнению "спицалистов" его >> курить нельзя. > Крутой велосипед с турбонаддувом. Правда на улицах почему-то попадаются менее крутые концепты > обычно. Да, не всем дано понять круть турбонаддува в велосипеде. Велосипеды > без турбонаддува - сакс. Вы нехороший человек, я теперь от любопытства помру, пытаясь понять, куда же именно турбонаддув велосипедисту вставляется.
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

5. "Рост числа процессорных ядер приведет к необходимости смены ..."	+2 +/–
Сообщение от аноним on 02-Окт-10, 16:30
А как же работали 1024-ядерные системы покойной SGI? И все ядра под одной копией linux!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Arcturus (ok) on 02-Окт-10, 16:57
	1024-ядерные или 1024 процессорные?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	61. "Рост числа процессорных ядер приведет к необходимости смены ..."	+1 +/–
	Сообщение от StrangeAttractor (ok) on 02-Окт-10, 21:40
	> 1024-ядерные или 1024 процессорные? Кстати, а какая разница? Правда интересно. Мне ясно только что при отдельных процах получается кэша больше.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	67. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от DmitryINdig0 (ok) on 02-Окт-10, 22:54
	суперкомпьютеры сильны, когда каждая нода выполняет свою часть задачи. А потом все решения надо объединить. Помнится на Пентиум3 в МГУ строился вычислительный кластер, и много денег потратили на сеть, что бы задержки и коллизии исключить, которые бывают в распространенном езернете. Там какой-то "хитрый" езернет был. Сейчас я японии строить собираются 10Тфлопный суперписюк ) Так там как раз одна из особенностей, это новый подход к сети кластера. Или же еще пример. Применение шейдеров видеокарты для вычисления - хорошая идея, но задачу надо разбить правильно и главное что бы под "размер" шейдера. Затем на выходе собрать результат. Вот так я понимаю.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	69. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от админ on 02-Окт-10, 23:33
	>суперкомпьютеры сильны, когда каждая нода выполняет свою часть задачи. а при чём тут ноды? был задан конкретный вопрос. зы: ядра почти не отличаются от выделенных камней. иногда просто некоторые ресурсы бывают общими - кэш, фпу и т.д.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	124. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Аноним (??) on 03-Окт-10, 19:46
	Это только если абстрагироваться что скорость и задержки в канале связи на кристале и на плате - это совсем разные вещи :)
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	152. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от yet another anonim on 05-Окт-10, 05:27
	Какую плату вы имеете ввиду? Данные между физически связанными ядрами вполне радостно гуляют внутри чипа, с частотой, явно большей, чем та, что между отдельными процами, избегая всяких прочих плат, и, соотв., с задержкой меньшей. Платы в таком случае лишь получают уже готовые обработанные вещи и посылают новые данные для обработки.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	22. "Рост числа процессорных ядер приведет к необходимости смены ..."	–20 +/–
	Сообщение от User294 (ok) on 02-Окт-10, 19:30
	> А как же работали 1024-ядерные системы покойной SGI? А еще вон в топ500 почему-то куча линукса. А если то что говорят фрукты из MIT правда - ну допилят ядро, куда ж они денутся? :) Может парни из MIT себе грант на "принципиально новую ОС" хотят выбить?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	28. "Рост числа процессорных ядер приведет к необходимости смены ..."	+3 +/–
	Сообщение от Аноним (??) on 02-Окт-10, 19:43
	Кластер и супер-мультиядерность на одном чипе - несколько разные вещи.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	35. "Рост числа процессорных ядер приведет к необходимости смены ..."	–14 +/–
	Сообщение от User294 (ok) on 02-Окт-10, 19:59
	> Кластер и супер-мультиядерность на одном чипе - несколько разные вещи. Однозначно. Правда насчет того что супер-мультиядерность вообще перспективна - это большой вопрос. Где Kilocore от IBM, например? А то там 1024 ядра чтоли обещали, или около того. У многоядерников есть проблема: если задача не параллелится (а параллелится не любая задача), все упирается в скорость 1 ядра а остальные ничего не делают. При этом чем круче отдельное ядро (и чем их меньше умещается, соответственно) тем лучше работает 1-поточная задача. Ну вот интели и амд всякие нынче для борьбы с этим жутко изгаляются. Делая всякие TurboCore и что там еще (ака разгон 1 ядра при неактивных остальных).
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	70. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от админ on 02-Окт-10, 23:36
	кстати согласен - без правильного распараллеливания задачи фиг что получится. сейчас на смп проще считать так - одна задача, один проц.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	155. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от User294 (ok) on 05-Окт-10, 05:43
	> кстати согласен - без правильного распараллеливания задачи фиг что получится. А некоторые задачи как-то так изначально последовательные и не очень то хотят параллелиться по природе своей. Собственно этот простой и обидный факт и является основной проблемой многоядерников, из-за которых процы с уймой относительно слабых ядер так и не пошли в массы.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	164. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от fr0ster (ok) on 05-Окт-10, 08:18
	> является основной проблемой многоядерников, из-за которых процы с уймой относительно слабых > ядер так и не пошли в массы. Не совсем так, видяхи те же узкоспециализированные компы, а какая массовость?
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	52. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Аноним (??) on 02-Окт-10, 20:59
	Мисье все знайка - доведу до твоего сведения - в TOP500 нет не одной машины с количеством ядер на одной ноде выше 32х. Ноды обмениваются между собой или через shared memory (mmap большого файла) или через MPI. ТОЧКА. То как linux kernel пытались запускать на SGI Altrix - это отдельная и грустная история - он там просто не работал, ибо инициализация 512 ядер занимала дохрена времени и накладные расходы вобщем-то тоже. Линукс на машинах Cray XT[3-5], IBM BG/L сводится к одной вещи - запускалка процессов. Единственное серьезное использование это service node - там еще +/- похожее на привычное окружение. Надеяться что ядро "допилят" не стоит - много ли допиливаний под Cray вернулось в ядро? А BG/L specific ?
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	55. "Рост числа процессорных ядер приведет к необходимости смены ..."	–23 +/–
	Сообщение от User294 (ok) on 02-Окт-10, 21:19
	> много ли допиливаний под Cray вернулось в ядро? Вы хотите сказать что вон та орава ядерщиков не сможет так же? При том их главный финноамериканец это самое ядро с нуля написал? Прикольно, да :) > Надеяться что ядро "допилят" не стоит Да что вы так нервничаете? Время покажет. Будут 48-ядерные процы майнстримом - тогда и увидим все. Я думаю что если кастомеры начнут теребить редхатов, ораклей, айбиэмов и прочих - они быстренько допилят, никуда не денутся. А что, у них еще и выбор будет? :)
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	78. "Рост числа процессорных ядер приведет к необходимости смены ..."	+1 +/–
	Сообщение от Аноним (??) on 03-Окт-10, 00:11
	>> много ли допиливаний под Cray вернулось в ядро? > Вы хотите сказать что вон та орава ядерщиков не сможет так же? Не сможет. > При том их главный финноамериканец это самое ядро с нуля написал? > Прикольно, да :) Один он ? ну ты наивный малый :) почитаешь на lwn.net кто вкладывает и за чьи деньги в ядро? А что будет если туда не будут вкладывать - то где эти интузиасты будут ?:) >> Надеяться что ядро "допилят" не стоит > Да что вы так нервничаете? Время покажет. Будут 48-ядерные процы майнстримом - > тогда и увидим все. По себе судить не стоит. > Я думаю что если кастомеры начнут теребить редхатов, ораклей, айбиэмов и прочих > - они быстренько допилят, никуда не денутся. А что, у них > еще и выбор будет? :) Ты хоть раз общался с сапортом RedHat ? видимо нет. Если ты не клиент с 1000 лицензий - ты им слабо интересен. Если ты еще хочешь чего-то странного, что не укладывается в их виденье мира - то ровно так же. Собрать ядро с какой нить опцией - идешь лесом, починить баг который им кажется маловажным - ровно так же. Так что мисье всезнайка облажался в очередной раз.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	98. "Рост числа процессорных ядер приведет к необходимости смены ..."	+1 +/–
	Сообщение от Аноним (??) on 03-Окт-10, 09:40
	>>> много ли допиливаний под Cray вернулось в ядро? >> Вы хотите сказать что вон та орава ядерщиков не сможет так же? >Не сможет. Сможет.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	112. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от fr0ster (ok) on 03-Окт-10, 15:18
	>>>> много ли допиливаний под Cray вернулось в ядро? >>> Вы хотите сказать что вон та орава ядерщиков не сможет так же? >>Не сможет. > Сможет. Вначале посчитает, сколько на это надо бабок и пошлет затею лесом, пока широкого употребления многоядерных систем не будет.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	148. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от User294 (ok) on 04-Окт-10, 17:13
	> Не сможет. Да бросьте, там собралась такая куча ориентированных не на процесс и теоретическую круть а на результат что они *любую* актуальную задачу смогут вкатать в асфальт. Не где-то там в теории как математик из анекдота про пожар и пожарный кран, а на практике. В реальном мире. На реальных машинах. Будет задача хорошо работать на 48 ядрах? Сделают. Готов даже поспорить на $100 :) > Один он ? Ну, начал он один. А потом орава присоединилась. И вот теперь там такая могучая кучка которая может разобраться с любой задачей. >ну ты наивный малый :) почитаешь на lwn.net кто вкладывает и за чьи деньги в ядро? Да я его и так в общем то читаю регулярно. Что-то опоздали вы с советами лет на эн... > А что будет если туда не будут вкладывать - то где эти интузиасты будут ?:) Кто тут еще наивный :). Если уж на горизонте нарисуется задача "хорошо работать с 48 ядрами" - уж вкладывающие бабки в линух будут первым делом заинтересованы скорее всего, т.к. у них или их кастомеров и будут такие железяки первым делом. И, кстати, допилить напильничком до работающего состояния то что уже есть - куда дешевле чем с нуля такое же но идеологически правильнее написать. Это даже туповатые инвесторы понимают. > По себе судить не стоит. Ну так и не судите. > Ты хоть раз общался с сапортом RedHat ? видимо нет. > Если ты не клиент с 1000 лицензий - ты им слабо интересен. Ради одного В. Пупкина с 1 лицензией ессно никто не будет кастомно кодить что-то в большом масштабе. Только вот 48-ядерные процы ради одного В.Пупкина и подавно никто не станет производить, если что. Первыми заинтересуются такими железками как раз эти, с 1000 лицензий которые. У Пупкинов пупок развяжется платить за первые процы с 48 ядрами. Дальше оно может быть станет майнстримом. А может быть вслед за Итаником отправится. Это уж рынок решать будет. > Если ты еще хочешь чего-то странного, что не укладывается в их виденье > мира - то ровно так же. Если процессоры с 48 ядрами станут обыденностью - они перестанут быть странными. А если к ним придет один В. Пупкин с одной лицензией но где-то каким-то чудом урвавший инженерный сэмпл 48-ядерного проца - ну да, он не повод для дерганий. Хотя-бы потому что вообще нет гарантий что этот проц в серию пойдет. А повкалывать ради красоты концепций самой по себе и счастья одного В. Пупкина - дорого и непрактично. > Собрать ядро с какой нить опцией - идешь лесом, починить баг который > им кажется маловажным - ровно так же. Извините. Попробуйте такое попросить у микрософта для сравнения? А хотя-бы и будучи кастомером с 1000 лицензий? > Так что мисье всезнайка облажался в очередной раз. И правда - облажался. Потому что "мисье" - это позор! Анонимные аналитики школу не заканчивали? oO
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	68. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от zuborg on 02-Окт-10, 23:25
	>Ноды обмениваются между собой или через shared memory (mmap большого файла) Ещё один всезнайка нашелся. И чем же мемори расшаривается ? Сокет планки памяти запаян на материнки обоих нод ? Или изменения в файле через NFS синхронизируются ? Короче, слыхал звон, да не знал где он...
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	75. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Аноним (??) on 03-Окт-10, 00:05
	>Или изменения в файле через NFS синхронизируются ? Если для вас сетевые FS заканчиваются NFS - мне вас очень жаль. lustre | GPFS + mmaped file - вполне себе схема shared memory. DLM обеспечит когентность кэшей на всех нодах.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	80. "Рост числа процессорных ядер приведет к необходимости смены ..."	+1 +/–
	Сообщение от Аноним (??) on 03-Окт-10, 00:27
	Ах да, забыл. вокруг этого mmap file, накручивают стопку MPI_barrier что бы синхронизировать доступ. а за одно советую чутку заглянуть в google по словам "MPI shared memory mmap" узнаете много нового для себя, и перестанете кичиться своим невежеством.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	85. "Рост числа процессорных ядер приведет к необходимости смены ..."	+2 +/–
	Сообщение от аноним on 03-Окт-10, 01:04
	> а за одно советую чутку заглянуть в google по словам "MPI shared > memory mmap" > узнаете много нового для себя, и перестанете кичиться своим невежеством. Вы бы язык-то прикусили, да почитали бы о том, о чем несете абсолютный бред, ни хрена не понимая как оно работает.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	86. "Рост числа процессорных ядер приведет к необходимости смены ..."	–3 +/–
	Сообщение от Аноним (??) on 03-Окт-10, 01:39
	Да да :) расскажи мне убогому как оно работает.. Как DLM поддерживает когентность page cache на многих машинах :) А я послушаю "аналитика" ;-) Или все знания окачиваются NFS? так в NFS v4.1 уже начались подобия нормальной файловой системы..
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	105. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от zuborg on 03-Окт-10, 13:53
	>Ноды обмениваются между собой или через shared memory (mmap большого файла) >... >GPFS + mmaped file - вполне себе схема shared memory Итак, подытожим, ноды суперкомпа обмениваются между собой информацией используя сетевые файловые системы (такие как GPFS) через замечательный IPC механизм shared memory, который по определению работает в пределах одной машины (т.к. память, хранящаяся в состоянии одного и того же блока транзиторов в конкретном чипе памяти может быть отображена в адресное пространство нескольких процессов только в пределах той машины, на которой эти процессы исполняются) Вы у Петросяна помощником не работаете ?
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	118. "Рост числа процессорных ядер приведет к необходимости смены ..."	+2 +/–
	Сообщение от Аноним (??) on 03-Окт-10, 17:36
	>>Ноды обмениваются между собой или через 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 - но работает, и для некоторых задач - имеет место использоваться. > Вы у Петросяна помощником не работаете ? ищите колег ?
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	119. "Рост числа процессорных ядер приведет к необходимости смены ..."	+1 +/–
	Сообщение от Аноним (??) on 03-Окт-10, 17:42
	за одно стоит прочитать определение http://en.wikipedia.org/wiki/Shared_memory что бы в очередной раз не слыть невеждой и мне в очередной раз жаль что понятие shared memory для вас закончилось на System V IPC, а понятия файловых систем - на NFS который не имеет никакого distributed lock manager.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	122. "Рост числа процессорных ядер приведет к необходимости смены ..."	+1 +/–
	Сообщение от zuborg on 03-Окт-10, 18:21
	>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. прошу прощения за излишнюю резкость в предыдущих сообщениях.
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	125. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Аноним (??) on 03-Окт-10, 19:56
	>>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 software In 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, or 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. This is most often used for shared libraries and for XIP. переводим: - метод межпроцесорного взаимодействия когда один процесс создает область памяти к которой другие могут получить доступ - запихивание разных vma (virtual memory area) в разные процессы - так что они реально имеют доступ к общим данным. так все таки применимо - или тут разные процессы (на разных нодах) не получают доступ к общим данным? > Копия содержимого памяти и "одна и та же страница" памяти - это существенно различные понятия. а ничего что после pagger и последующего востановления из свопа - у вас будут разные физические страницы? и любое приложение на userland работает с виртуальными адресами - которые никак не связаны с реальными транзисторами. А с точки зрения виртуальной памяти нет никакой разницы - соединили микросхемы в 2х нодах физически или логически. ps. я понимаю вашу позицию как системотехника, но в данном случае разговор идет о процессах выполняющихся не в ядре, и оперирующими виртуальной памятью.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	126. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от zuborg on 03-Окт-10, 20:51
	>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, хотя и может казаться им.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	136. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Аноним (??) on 04-Окт-10, 08:48
	Сознательно игнорируете первую строчку определения данного 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.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	146. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от zuborg on 04-Окт-10, 13:25
	>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 ?! Где-то есть какой-то екзепляр данных, другие процессы каким-то (неважно каким, логически все способы еквивалентны ведь) способом получает доступ к этим данным. Сможете это опровергнуть ?
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	71. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от админ on 02-Окт-10, 23:40
	>Мисье все знайка - доведу до твоего сведения - в TOP500 нет не одной машины с количеством ядер на одной ноде выше 32х. 32 - уже не хило. совсем до 48 не далеко. пока одни помои льют, время идёт и другие работают. >Линукс на машинах Cray XT[3-5], IBM BG/L сводится к одной вещи - запускалка процессов. на моём ноуте - тоже.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	76. "Рост числа процессорных ядер приведет к необходимости смены ..."	–1 +/–
	Сообщение от Аноним (??) on 03-Окт-10, 00:07
	>>Мисье все знайка - доведу до твоего сведения - в TOP500 нет не одной машины с количеством ядер на одной ноде выше 32х. > 32 - уже не хило. 16 или 32 был только в BG/L. Но там далеко не SMP, а POWER[5|6] + NUMA. > совсем до 48 не далеко. пока одни помои льют, время идёт и > другие работают. >>Линукс на машинах Cray XT[3-5], IBM BG/L сводится к одной вещи - запускалка процессов. > на моём ноуте - тоже. Да ну? что бы запустить 1 процесс который будет по сети работать ?:)
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	82. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от аноним on 03-Окт-10, 00:38
	>16 или 32 был только в BG/L. Но там далеко не SMP, а POWER[5|6] + NUMA. ха! это что-то меняет? >Да ну? ну да. >что бы запустить 1 процесс который будет по сети работать ?:) угу. браузер. как в твоём случае. чтобы скопировать с вики ничего не доказывающую информацию.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	87. "Рост числа процессорных ядер приведет к необходимости смены ..."	–1 +/–
	Сообщение от Аноним (??) on 03-Окт-10, 01:40
	>>16 или 32 был только в BG/L. Но там далеко не SMP, а POWER[5|6] + NUMA. > ха! это что-то меняет? Очень многое.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	88. "Рост числа процессорных ядер приведет к необходимости смены ..."	–1 +/–
	Сообщение от админ on 03-Окт-10, 01:48
	ничего это не меняет. если есть что сказать - ю а велком. а так - в сад.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	89. "Рост числа процессорных ядер приведет к необходимости смены ..."	–1 +/–
	Сообщение от Аноним (??) on 03-Окт-10, 02:01
	> ничего это не меняет. > если есть что сказать - ю а велком. а так - в > сад. Если не понимаете то точно в сад - учиться :) различия в подходах к SMP и NUMA я думаю сможете и без меня в wiki прочитать. помоему на страничке с NUMA как раз и описывались все проблемы традиционной SMP архитектуры - почему стали использовать NUMA.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	109. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от админ on 03-Окт-10, 14:50
	вы действительно не понимаете или прикидываетесь? если последнее, то очень умело. чтобы расставить точки на И - объясните какое отношение всё вышесказанное имеет к сабжу.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	117. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Аноним (??) on 03-Окт-10, 17:23
	самое что не наесть прямое - в тексте рассматриваются проблемы _SMP_ систем которых не может быть в NUMA, если программировать правильно.
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	120. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Аноним (??) on 03-Окт-10, 17:45
	> вы действительно не понимаете или прикидываетесь? > если последнее, то очень умело. > чтобы расставить точки на И - объясните какое отношение всё вышесказанное имеет > к сабжу. в частности - частое и бездумное использование atomic - создает неявные memory barier которые вызывают cache flush со всех CPU в системе, чем перегружают каналы связи. А linux kernel славился бездумным использованием atomic - благо дело при малом количестве CPU и i386 архитектуре это очень дешево (hint поищите патч ника который вычищал atomic из dcache - там приводились цифры насколько вырасла производительность после этого).
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	91. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Алексей (??) on 03-Окт-10, 04:08
	Всезнайка наверное не читал 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.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	127. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Аноним. on 03-Окт-10, 23:47
	>Мисье все знайка - доведу до твоего сведения - в TOP500 нет не одной машины с количеством ядер на одной ноде выше 32х. http://top500.org/system/8385 Ранее в списке был Росгидромет, где было более 32 ядер. >То как linux kernel пытались запускать на SGI Altrix - это отдельная и грустная история - он там просто не работал, ибо инициализация 512 ядер занимала дохрена времени и накладные расходы вобщем-то тоже. Работал, работает и будет работать... не надо врать... И времени эта "инициализация" занимала не много.... и даже на 1024 ядрах. >Линукс на машинах Cray XT[3-5], IBM BG/L сводится к одной вещи - запускалка процессов. А что оно ещё должно делать?? Угадывать, что вы хотите посчитать и сразу выдавать результат???
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	139. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Аноним (??) on 04-Окт-10, 09:02
	>>Мисье все знайка - доведу до твоего сведения - в 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 - поймете.
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

	147. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Аноним. on 04-Окт-10, 14:05
	>Что хотели то сказать ссылкой на 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 - А что приборы". Вы решите сначала, что хотите сказать, а уже потом говорите, а не прыгайте по мыслям. Вопрос стоит так, что ещё, помимо запуска процессов, оно должно делать???
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

6. "Рост числа процессорных ядер приведет к необходимости смены ..."	–2 +/–
Сообщение от pro100master (ok) on 02-Окт-10, 16:34
ну, имхо, в 48-ядерных в любом случае эффективность будет низкая: объём кэша не резиновый, а память и шина тормоза.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	12. "Рост числа процессорных ядер приведет к необходимости смены ..."	–1 +/–
	Сообщение от Карбофос (ok) on 02-Окт-10, 17:16
	там, в принципе, выход только один: уменьшить разницу между характеристиками кэша и внешней памятью
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	26. "Рост числа процессорных ядер приведет к необходимости смены ..."	–6 +/–
	Сообщение от User294 (ok) on 02-Окт-10, 19:37
	> ну, имхо, в 48-ядерных в любом случае эффективность будет низкая: объём кэша > не резиновый, а память и шина тормоза. Придется хреначить кучу каналов памяти (до тех пор пока не задолбутся разводить из на 10-слойных бутербродах по дикой цене). Или сделать кеш в который треды умещаются. Впрочем это будет довольно нишевой штукой. Не все задачи можно распараллелить на 48 потоков. Числокрушилки с кучей слабых ядер есть давно, но они являются довольно нишевыми штуками, интересным в сильно некоторых областях. Например: брут известного MD5 хеша можно разложить на 48 процессоров без проблем, опробуя одновременно 48 разных вариантов. А попробуйте теперь разложить на 48 процессоров рассчет хеша ОДНОГО файла? Тут то и будут опаньки - результат зависит от предыдущего и ничего ускорить не выйдет. Ну и будет хэш считать 1 проц. А еще 47 будут курить бамбук и кушать электричество.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	34. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Аноним123321 (ok) on 02-Окт-10, 19:56
	>... и кушать электричество. на самом деле нет. вы никогда не задумывались почему темпиратура процессора зависит от того делает-ли он чтото или простаивает? а зависит она потомучто умные дяденьки придумали как можно отключать (усыплять) неиспользуемые-в-данный-момент блоки процессора :-)
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	38. "Рост числа процессорных ядер приведет к необходимости смены ..."	–6 +/–
	Сообщение от User294 (ok) on 02-Окт-10, 20:07
	> вы никогда не задумывались почему темпиратура процессора зависит от того делает-ли он > чтото или простаивает? Потому что CMOS схема кушает что-то только в момент переключения, сэр. Перезаряд емкостей. Чем чаще и больше переключений, тем больше кушается (есть еще впрочем токи утечек и прочая). Разумеется, можно поотключать лишние ядра или постопать им клок или снизить частоту клока. Но как-то вот в реально существующих general purpose процах это делается далеко не с максимальной эффективностью. > а зависит она потомучто умные дяденьки придумали как можно отключать (усыплять) неиспользуемые-в-данный-момент > блоки процессора :-) Собственно оно из особенностей схемотехники CMOS вытекает. А умные дяденьки к слову в general purpose процах не очень свою попу рвут на этот счет. В мелких микроконтроллерах,  процессорах для мобилок и прочая на этот счет пыжатся намного сильнее. Поэтому хотя в теории вы и правы, на практике оно все-таки ближе к тому что я сказал, как минимум пока. Есть и всякие побочные грабли. Если источник питания проца должен вытянуть 48 ядер, тогда при работе 1 ядра он будет работать с недогрузом в десятки раз и его КПД опять же будет не ахтецкий. Хотя с этим научились частично бороться переключая число фаз преобразователя. Но еще ж есть основной блок питания например. К которому все это тоже применимо и там почему-то никто числом фаз преобразователей не щелкает. В общем реальная картина получается не такой же как идеальная.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	57. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от fr0ster (ok) on 02-Окт-10, 21:34
	Многоядерные системы были, есть и будут весьма специализированными девайсами, то есть ситуация простоя для них не актуальна, их создают под задачу часто.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	130. "Рост числа процессорных ядер приведет к необходимости смены ..."	–1 +/–
	Сообщение от User294 (ok) on 04-Окт-10, 06:42
	> Многоядерные системы были, есть и будут весьма специализированными девайсами, Эээ ну 2...6 ядерные процессоры попадаются и у юзеров. В не слишком специализированных девайсах. Но простому юзеру весьма проблематично загрузить даже 6 ядер надолго.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	131. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от fr0ster (ok) on 04-Окт-10, 06:51
	>> Многоядерные системы были, есть и будут весьма специализированными девайсами, > Эээ ну 2...6 ядерные процессоры попадаются и у юзеров. В не слишком > специализированных девайсах. Но простому юзеру весьма проблематично загрузить даже 6 ядер > надолго. У нас как бы речь было о 32 и более. Неточно высказался тогда, "Многоядерные системы(много более 6 ядер) были, есть и будут весьма специализированными девайсами". Устроит?
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	135. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от User294 (ok) on 04-Окт-10, 06:58
	> Устроит? Однозначно, Кэп.
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	158. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от yet another anonim on 05-Окт-10, 06:34
	Угу, что-то не слышал я ещё о реальных продающихся процах, отключающих ядра. А существующие, всё, что могут, так это понизить частоту макс. в 2-2.5 раза от стандартной (пример моего ноута 2 ГГц ->> 1 ГГц), ну и, по крайней мере, мобильные версии - чуть-чуть уменьшить напряжение тока (мой пример: 1.25 В ->> 0.95 В). Это, конечно же, не так плохо, но можно сильно лучше. И насчёт "потребляющих во время переключений CMOS" вы правы - спецом не так давно проверял - выставил под Вистой программкой RMClock держать 2ГГц и напругу 1.25В, но при этом не нагружал ничем - так темп. с 38-44C поднималась до ~44-49C, вентилятор лишь немного повысил обороты, потом, дав работы 7-зипу, загрузив оба потока, обнаружил, повышение темп. уже до 56-61C и обороты уже поднялись выше среднего. Специально при этом следил за частотами видюшки - не изменялись (а вот темп. из-за близкого расположения и общей сист. охлаждения, поднялась на 8 градусов). Темп. комнаты не засекал, но дело было после полуночи и в комнате было прохладно. Летом, жарой, к этому всему можно добавлять +10C.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	167. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от fidaj (ok) on 05-Окт-10, 10:43
	> Угу, что-то не слышал я ещё о реальных продающихся процах, отключающих ядра. > А существующие, всё, что могут, так это понизить частоту макс. в > 2-2.5 раза от стандартной (пример моего ноута 2 ГГц ->> 1 > ГГц)... угу на линухе у меня тоже почти так же, но на "другой системе" мой же этот же ноут - понижает в 21 раз: с 2100МГц до 100МГц.... не ровняйте все по линуксу.... "на правах лирического отступления..."
	Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

	171. "Рост числа процессорных ядер приведет к необходимости смены ..."	+1 +/–
	Сообщение от Kalinin on 05-Окт-10, 12:08
	Там основные потери от скин эффекта.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	74. "Рост числа процессорных ядер приведет к необходимости смены ..."	+3 +/–
	Сообщение от Карбофос (ok) on 02-Окт-10, 23:46
	>темпиратура больше не нужно было писать
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

7. "Рост числа процессорных ядер приведет к необходимости смены ..."	+2 +/–
Сообщение от _Vitaly_ (ok) on 02-Окт-10, 16:35
Они изобрели транспьютер?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Рост числа процессорных ядер приведет к необходимости смены ..."	+2 +/–
Сообщение от fidaj (ok) on 02-Окт-10, 16:48
Пусть не гонят! Plan9 к этому давно уже готова! Манагеры МС взялись за аналитику?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	24. "Рост числа процессорных ядер приведет к необходимости смены ..."	–7 +/–
	Сообщение от Анонимный трус on 02-Окт-10, 19:33
	При чем тут План9, который вообще никому не нужен? И при чем тут манагеры МС? Исследование в MIT делали.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	32. "Рост числа процессорных ядер приведет к необходимости смены ..."	–6 +/–
	Сообщение от User294 (ok) on 02-Окт-10, 19:52
	>Исследование в MIT делали. Наверное они грант хотят стрясти :).При том почему-то мне так кажется что если 48-ядерные процы станут нормой жизни то линуха всяко подтянут до нормальной работы и на этом хардваре. А куда они денутся то? Как начнут кастомеры всяких ораклов, айбиэмов и редхатов прессовать, так и раздуплятся... :)
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	45. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от fidaj (ok) on 02-Окт-10, 20:22
	> При чем тут План9, который вообще никому не нужен? если он не нужен лично вам, то это ничего не значит > И при чем тут манагеры МС? Исследование в MIT делали. У вас все документальные данные в наличии со стророны МС, кому и за что они платят?
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	50. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Аноним (??) on 02-Окт-10, 20:49
	План9 - академическая сферовакуумная ОС. Что там к чему готово, я без понятия, но вам правильно говорят - он никому не нужен. Хотя как архитектурный образец, конечно, да. Их много. Inferno, Plan9, Singularity и прочие. Понадобится - на этой основе сделают что-то реально работающее. тем не менее, архитектура архитектурой, но принципиальную не-распараллеливаемость многих задач это не отменяет.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	53. "Рост числа процессорных ядер приведет к необходимости смены ..."	+1 +/–
	Сообщение от fidaj (ok) on 02-Окт-10, 21:00
	> План9 - академическая сферовакуумная ОС. Что там к чему готово, я без > понятия, но вам правильно говорят - он никому не нужен. А жаль :( > Хотя как архитектурный образец, конечно, да. Их много. Inferno, Plan9, Singularity и > прочие. Понадобится - на этой основе сделают что-то реально работающее. > тем не менее, архитектура архитектурой, но принципиальную не-распараллеливаемость многих > задач это не отменяет. Зато появляется новый абстрактный уровень не привязанный к конкретному железу.. вернее уже есть в лице ненужного плана9...
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	56. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Px on 02-Окт-10, 21:22
	Да, есть принципиально не распараллеливаемые задачи, но много ли машин на которых считают одну единственную «МегаЗадачу»???
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	81. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от XeNoN (ok) on 03-Окт-10, 00:35
	>Plan9 к этому давно уже готова! К чему готова? К обозначенной выше проблеме? Ни разу не готова. Ни по своей архитектуре, ни по текущей реализации, plan 9 не уделывает никакого современного наследника UNIX применительно к проблеме кучи ядер.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

9. "Рост числа процессорных ядер приведет к необходимости смены ..."	+2 +/–
Сообщение от Аноним (??) on 02-Окт-10, 16:50
Долго же они приходили к этому мнению.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Рост числа процессорных ядер приведет к необходимости смены ..."	+6 +/–
Сообщение от Аноним (??) on 02-Окт-10, 16:52
К счастью, Linux с открытыми драйверами и базовыми компонентами - готов к переменам, они возможны.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	31. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Аноним (??) on 02-Окт-10, 19:51
	Для того, чтобы сделать то, что они имеют в виду, простым перепилом ведра не обойдешься. Там именно заново придется все писать
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	39. "Рост числа процессорных ядер приведет к необходимости смены ..."	–15 +/–
	Сообщение от User294 (ok) on 02-Окт-10, 20:10
	> Там именно заново придется все писать Помнится Таненбаум в свое время очень ругался что линукс сильно завязан на аппаратные особенности i386. А сегодня у меня почему-то пачка железок с линуксом. И среди них ни одного i386 :). Только x64, ARM и MIPS почему-то. Такие вот чудеса истории.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	65. "Рост числа процессорных ядер приведет к необходимости смены ..."	–2 +/–
	Сообщение от Аноним (??) on 02-Окт-10, 22:18
	При чем тут привязка к железу? Ну хорошо, попробуйте переделать ведро под модель а-ля Inferno, я посмотрю на это...
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	72. "Рост числа процессорных ядер приведет к необходимости смены ..."	–1 +/–
	Сообщение от админ on 02-Окт-10, 23:43
	аналогия. чем это хуже привязки к количеству камней? зы: вопрос больше железячный - нужны более быстрые каналы между процами для начала. а пока это больше ограничение архитектуры, чем ос.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	132. "Рост числа процессорных ядер приведет к необходимости смены ..."	+1 +/–
	Сообщение от User294 (ok) on 04-Окт-10, 06:52
	> При чем тут привязка к железу? Просто в свое время линух за "непортабельность" ругали. А он возьми да и стань одной из наиболее портабельных операционок. Весьма иронично. Сегодня его ругают за то что на 48 ядрах не работает оптимально. Зато думаю что когда процы с 48 ядрами станут майнстримом (если вообще станут), линукс вероятно будет их поддерживать на ура. Вероятно даже лучше чем большая часть иных систем в этот же момент времени. > Ну хорошо, попробуйте переделать ведро под модель а-ля Inferno, я посмотрю на это... "А нафига?" Если кому-то будет надо чтобы работало на 48 ядрах нормально - и так допинают. Эволюционным методом вместо революционного. В конечном итоге - засчитывается все-таки практический результат, а не теоретическая крутизна. Потому что нечто может быть очень круто в теории но никогда вообще не оказаться реализовано на практике по разным причинам. Тогда оно будет всего лишь бесполезным артефактом. Как пример: орали все - микроядра, микроядра. В итоге в чистом виде они никому не впились. Зато появились гибридные ядра, гипервизоры и что там еще. Не то чтобы теория совсем стухла, но на практике оказалась совсем не такой как ее изначально сватали теоретики :)
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

13. "Рост числа процессорных ядер приведет к необходимости смены ..."	+1 +/–
Сообщение от Аноним (??) on 02-Окт-10, 17:33
мне интересно, userspace будут вообще пилить в сторону потоковости? tar, gzip, bzip - однопоточные. Есть многопоточные форки, но это форки, и они не всегда есть в дистрибутиве, и к тому же не совместимы на 100% по аргументам командной строки
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	20. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от аноним on 02-Окт-10, 19:12
	> мне интересно, userspace будут вообще пилить в сторону потоковости? tar, gzip, bzip > - однопоточные. Есть многопоточные форки, но это форки, и они не > всегда есть в дистрибутиве, и к тому же не совместимы на > 100% по аргументам командной строки Если вам надо - возьмите и допилите совместимость. А "не всегда есть в дистрибутиве" - исключительно проблема дистрибутива.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	66. "Рост числа процессорных ядер приведет к необходимости смены ..."	+1 +/–
	Сообщение от anonymous (??) on 02-Окт-10, 22:22
	>tar, gzip, bzip - однопоточные lzma и xz. а tar - это не компрессор, ему и на одном ядре неплохо живётся.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

14. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
Сообщение от devlink on 02-Окт-10, 17:51
По моему они на Minix и еже с ними намекают.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	94. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Vkni on 03-Окт-10, 08:19
	> По моему они на Minix и еже с ними намекают. Это тот же Unix, пусть в него и добавлены идеи 86-го года. :-)
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

17. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
Сообщение от kshetragia (ok) on 02-Окт-10, 18:37
А что? В Линуксе есть честный SMP?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	73. "Рост числа процессорных ядер приведет к необходимости смены ..."	–1 +/–
	Сообщение от админ on 02-Окт-10, 23:45
	нет, он врёт. на 8 ядрах линейная зависимость. врёт зараза.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

21. "Рост числа процессорных ядер приведет к необходимости смены ..."	–15 +/–
Сообщение от User294 (ok) on 02-Окт-10, 19:27
> Пока память используется, она не доступна для других задач А кеши у процессоров - типа для красоты? Или предлагается влупить 48 ядер, оперативку которая не может их прокачать, и кеша не добавлять? :) А так линуксный кернел уже с кучей тредов. Если они в кеш влезут - ну и ладушки. Алсо, не все задачи хорошо параллелятся. Задач которые могут эффективно размазаться на 48 ядер в природе в общем то не так уж и много.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	162. "Рост числа процессорных ядер приведет к необходимости смены ..."	–1 +/–
	Сообщение от yet another anonim on 05-Окт-10, 08:00
	>> Пока память используется, она не доступна для других задач > А кеши у процессоров - типа для красоты? Или предлагается влупить 48 > ядер, оперативку которая не может их прокачать, и кеша не добавлять? > :) А так линуксный кернел уже с кучей тредов. Если они > в кеш влезут - ну и ладушки. Алсо, не все задачи > хорошо параллелятся. Задач которые могут эффективно размазаться на 48 ядер в > природе в общем то не так уж и много. Тем не менее он прав - проблема преувеличена. Как бы не случайно ли на будущее на новых многоядерных процах вводят общий увеличенный кэш третьего уровня и возможность контролировать частоты ядер отдельно? Да и при 48 ядрах производительность будет такая, что уже вряд ли кто-то будет обращать внимание на скорость системы\типичной среды окружения вообще, учитывая, к тому же, их относительную нетребовательность и моду переноса всего лишнего на видеокарты. Ну а тяжёлые специализированные задачи в абс. большинстве своём, как и "движущие прогресс" игры, отлично поддаются параллелизации (и давно в принципе уже "запараллелизованы") и упомянутые проблемы их касаются лишь частично. Ну и, наконец, они сами сказали, что несколько мелких исправлений устраняют большинство проблем. Так к чему весь этот гудёж? :)
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

23. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
Сообщение от svchost (ok) on 02-Окт-10, 19:32
А не проще железячникам вместо увеличения количества ядер продолжать уменьшать техпроцессы, улучшать архитектуры, увеличивать частоты и кэш? А то опять к одноядерным процессорам придем, с кучей "внутренних ядер", "исполнительных блоков" или что-то в этом роде.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	25. "Рост числа процессорных ядер приведет к необходимости смены ..."	–2 +/–
	Сообщение от Анонимный трус on 02-Окт-10, 19:35
	> А не проще железячникам вместо увеличения количества ядер продолжать уменьшать техпроцессы, > улучшать архитектуры, увеличивать частоты и кэш? А то опять к одноядерным > процессорам придем, с кучей "внутренних ядер", "исполнительных блоков" или что-то в > этом роде. Дорого. Нарастить число ядер дешевле, чем перевести линию на новый техпроцесс.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	47. "Рост числа процессорных ядер приведет к необходимости смены ..."	+5 +/–
	Сообщение от fidaj (ok) on 02-Окт-10, 20:24
	>> А не проще железячникам вместо увеличения количества ядер продолжать уменьшать техпроцессы, >> улучшать архитектуры, увеличивать частоты и кэш? А то опять к одноядерным >> процессорам придем, с кучей "внутренних ядер", "исполнительных блоков" или что-то в >> этом роде. > Дорого. Нарастить число ядер дешевле, чем перевести линию на новый техпроцесс. При чем тут дорого - поучите физику - поймете почему техпроцесс уменьшать уже некуда!
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	60. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от svchost (ok) on 02-Окт-10, 21:39
	Как некуда? Уже 22 на подходе, 32 нм давно есть в серийном производстве, а Интел все еще свои "энергоэффективные" АТОМы лепит на 45. Думается, 11 нм тоже не проблема.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	64. "Рост числа процессорных ядер приведет к необходимости смены ..."	+3 +/–
	Сообщение от fidaj (ok) on 02-Окт-10, 22:03
	> Как некуда? Уже 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... ну и что - дальше-то нужно менять принцип транзистора и уменьшение техпроцесса не поможет уже...
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	101. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от svchost (ok) on 03-Окт-10, 10:55
	Вот, кстати, интересно http://www.3dnews.ru/news/ibm_11_nm_ne_predel_dlya_kremniya/
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	102. "Рост числа процессорных ядер приведет к необходимости смены ..."	+2 +/–
	Сообщение от fidaj (ok) on 03-Окт-10, 11:45
	> Вот, кстати, интересно http://www.3dnews.ru/news/ibm_11_nm_ne_predel_dlya_kremniya/ Ну когда сделают - тогда и посмотрим, НО все-равно это тупиковая ветвь - это ясно как "Божий день"!
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	159. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от yet another anonim on 05-Окт-10, 07:03
	>> Вот, кстати, интересно http://www.3dnews.ru/news/ibm_11_nm_ne_predel_dlya_kremniya/ > Ну когда сделают - тогда и посмотрим, НО все-равно это тупиковая ветвь > - это ясно как "Божий день"! Так любая ветвь тупикова, вопрос только, где и когда мы на этот тупик наткнёмся. А если до этого тупика ещё как минимум неск. техпроцессов и много лет ещё - то нечего и тревогу бить почём зря. Вот и не спешат всякие Интелы с заменой принципа транзистора, придёт время - выход найдётся. Вон с графеном проводят эксперименты и уже выяснили ни одну его сверхспособность.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	168. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от fidaj (ok) on 05-Окт-10, 10:44
	>>> Вот, кстати, интересно http://www.3dnews.ru/news/ibm_11_nm_ne_predel_dlya_kremniya/ >> Ну когда сделают - тогда и посмотрим, НО все-равно это тупиковая ветвь >> - это ясно как "Божий день"! > Так любая ветвь тупикова, вопрос только, где и когда мы на этот > тупик наткнёмся. А если до этого тупика ещё как минимум неск. > техпроцессов и много лет ещё - то нечего и тревогу бить > почём зря. Вот и не спешат всякие Интелы с заменой принципа > транзистора, придёт время - выход найдётся. Вон с графеном проводят эксперименты > и уже выяснили ни одну его сверхспособность. уже наткнулись - просто в производство еще не все запускают - старьё еще нужно со складов распродать...
	Ответить | Правка | ^ к родителю #159 | Наверх | Cообщить модератору

	133. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от User294 (ok) on 04-Окт-10, 06:56
	> ну и что - дальше-то нужно менять принцип транзистора Угу, они уже вон на 3 ГГц застряли и что-то не больно то спешат даже просто кремний выбрасывать :). Вместо этого они решили в параллельные вычисления поиграть. И теперь у нас пузомерка не гигагерцы уже а количество ядер. А когда юзерам не станет нужно столько ядер - они начнут соревноваться в чем-нибудь еще. Ну например кто больше MIPS/Watt выжмет. Или там еще чего.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	138. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от fr0ster (ok) on 04-Окт-10, 08:56
	>> ну и что - дальше-то нужно менять принцип транзистора > Угу, они уже вон на 3 ГГц застряли и что-то не больно > то спешат даже просто кремний выбрасывать :). Вместо этого они решили > в параллельные вычисления поиграть. И теперь у нас пузомерка не гигагерцы > уже а количество ядер. А когда юзерам не станет нужно столько > ядер - они начнут соревноваться в чем-нибудь еще. Ну например кто > больше MIPS/Watt выжмет. Или там еще чего. Лучше бы сразу начали в "кто больше MIPS/Watt выжмет" играть.
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	153. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от User294 (ok) on 05-Окт-10, 05:28
	> Лучше бы сразу начали в "кто больше MIPS/Watt выжмет" играть. Да уж :). Но как-то так получилось что это стало вообще упоминаться как характеристика лишь сравнительно недавно.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	160. "Рост числа процессорных ядер приведет к необходимости смены ..."	–1 +/–
	Сообщение от yet another anonim on 05-Окт-10, 07:19
	>> ну и что - дальше-то нужно менять принцип транзистора > Угу, они уже вон на 3 ГГц застряли и что-то не больно > то спешат даже просто кремний выбрасывать :). Вместо этого они решили > в параллельные вычисления поиграть. И теперь у нас пузомерка не гигагерцы > уже а количество ядер. А когда юзерам не станет нужно столько > ядер - они начнут соревноваться в чем-нибудь еще. Ну например кто > больше MIPS/Watt выжмет. Или там еще чего. Вообще-то это очень условно "застряли". Выходили же модели с 4+ ГГц. А "энтузиасты" разгоняют и на 5, и на 6 и выше ГГц (правда уже с экзотическими и непрактичными системами охлаждения и проч.) Просто чтоб обеспечить достаточный выход стабильно работающих процев на таких частотах надо несколько усложнить и удорожать процесс производства, что несомненно им не в пользу, вот они и пошли по пути, позволяющему временно на эту проблему "забить" - пути параллелизации (ну и плюс всякие оптимизации, 64-битность и проч.) Непонятно, конечно, зачем они раньше всё это игнорировали\не замечали\тупые манагеры виноваты... Но в будущем точь так же дойдут до ограничивающего кол. ядер на кристалле фактора, и всё равно придётся либо менять материалы, усложнить и удорожать, либо вообще кардинально поменять технологии производства.
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	169. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от fidaj (ok) on 05-Окт-10, 10:47
	>[оверквотинг удален] >> то спешат даже просто кремний выбрасывать :). Вместо этого они решили >> в параллельные вычисления поиграть. И теперь у нас пузомерка не гигагерцы >> уже а количество ядер. А когда юзерам не станет нужно столько >> ядер - они начнут соревноваться в чем-нибудь еще. Ну например кто >> больше MIPS/Watt выжмет. Или там еще чего. > Вообще-то это очень условно "застряли". Выходили же модели с 4+ ГГц. А > "энтузиасты" разгоняют и на 5, и на 6 и выше ГГц > (правда уже с экзотическими и непрактичными системами охлаждения и проч.) Просто > чтоб обеспечить достаточный выход стабильно работающих процев на таких частотах надо > несколько усложнить и удорожать процесс производства, чушь.... откройте термодинамику да почитайте, если осилите....
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	137. "Рост числа процессорных ядер приведет к необходимости смены ..."	+1 +/–
	Сообщение от tanushi on 04-Окт-10, 08:53
	всем доброго времени суток. господин fidaj на самом деле прав. несколько лет назад читал в журнале "в мире науки" (руссифицированная версия the american scientific), что уменьшать до бесконечности не получится. уже, если мне не изменяет память, где-то около 2 нм. подойдут к физическому пределу, меньше которого то ли утечки тока, то ли квантовые эффекты будут настолько велики, что нельзя будет обеспечить стабильной работы. поэтому уже приличное время в лабораториях мира ведутся исследования в направлениях квантовых компьютеров, биокомпьютеров и прочих
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	161. "Рост числа процессорных ядер приведет к необходимости смены ..."	–1 +/–
	Сообщение от yet another anonim on 05-Окт-10, 07:33
	> всем доброго времени суток. господин fidaj на самом деле прав. несколько лет > назад читал в журнале "в мире науки" (руссифицированная версия the american > scientific), что уменьшать до бесконечности не получится. уже, если мне не > изменяет память, где-то около 2 нм. подойдут к физическому пределу, меньше > которого то ли утечки тока, то ли квантовые эффекты будут настолько > велики, что нельзя будет обеспечить стабильной работы. поэтому уже приличное время > в лабораториях мира ведутся исследования в направлениях квантовых компьютеров, биокомпьютеров > и прочих А вы сами представьте - при таких размерах эти транзисторы нужно будет разглядывать в электронный микроскоп, так что это уже будет не просто там квантовые эффекты, а химия - такие транзисторы будут рассыпаться пачками при малейших неточностях при производстве, при попадании на них микро-нанопылинки, дико реагировать на мельчайшие "химические раздражители" - тут уже просто напросто практически перестают действовать законы физики твёрдых тел. А токи не то что "утекают", а вообще норовят без спроса перебежать в соседние не-то-что транзисторы, а я бы даже сказал соединения из пары атомов\молекул. Я думаю никто на квантовые "вычисления" в ближайшее время не перейдёт, скорее будут опробывать новые материалы, допиливать старые технологии, испытывать в деле графен и т.д.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	170. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от fidaj (ok) on 05-Окт-10, 10:49
	>[оверквотинг удален] >> назад читал в журнале "в мире науки" (руссифицированная версия the american >> scientific), что уменьшать до бесконечности не получится. уже, если мне не >> изменяет память, где-то около 2 нм. подойдут к физическому пределу, меньше >> которого то ли утечки тока, то ли квантовые эффекты будут настолько >> велики, что нельзя будет обеспечить стабильной работы. поэтому уже приличное время >> в лабораториях мира ведутся исследования в направлениях квантовых компьютеров, биокомпьютеров >> и прочих > А вы сами представьте - при таких размерах эти транзисторы нужно будет > разглядывать в электронный микроскоп, так что это уже будет не просто > там квантовые эффекты, а химия - ... ну и БРЕД!!! какая химия???? не порите чушь!
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

	175. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от fidaj (ok) on 29-Апр-11, 22:31
	>[оверквотинг удален] > разглядывать в электронный микроскоп, так что это уже будет не просто > там квантовые эффекты, а химия - такие транзисторы будут рассыпаться пачками > при малейших неточностях при производстве, при попадании на них микро-нанопылинки, дико > реагировать на мельчайшие "химические раздражители" - тут уже просто напросто практически > перестают действовать законы физики твёрдых тел. А токи не то что > "утекают", а вообще норовят без спроса перебежать в соседние не-то-что транзисторы, > а я бы даже сказал соединения из пары атомов\молекул. > Я думаю никто на квантовые "вычисления" в ближайшее время не перейдёт, скорее > будут опробывать новые материалы, допиливать старые технологии, испытывать в деле графен > и т.д. http://habrahabr.ru/blogs/hardware/118137/
	Ответить | Правка | ^ к родителю #161 | Наверх | Cообщить модератору

	29. "Рост числа процессорных ядер приведет к необходимости смены ..."	+2 +/–
	Сообщение от Аноним (??) on 02-Окт-10, 19:47
	Так пока что там небольшой технологический(?) тупичок. Частоты повысить не получается, а если даже немного повысить, то это будет не процессор, а обогреватель, что не соответствует современным требованиям по энергосбережению. Да и из старых архитектур надо еще денег повыжимать - зачем на исследования и разработку тратиться. Вообщем куча факторов, искуственно тормозящих развитие технологий. А от кучи ядер толку тоже немного - как минимум для начала надо перейти на быструю RAM не конденсаторного типа, а оно пока в разработке............
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	40. "Рост числа процессорных ядер приведет к необходимости смены ..."	–14 +/–
	Сообщение от User294 (ok) on 02-Окт-10, 20:13
	> начала надо перейти на быструю RAM не конденсаторного типа, Да вообще-то SRAM уже не одно десятилетие назад придуман. Только при том же числе транзисторов он в несколько раз менее емкий получается. Поэтому статичная оперативка - круто, быстро ... и чертовски дорого. И именно поэтому никто ей и не пользуется.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	44. "Рост числа процессорных ядер приведет к необходимости смены ..."	+3 +/–
	Сообщение от fidaj (ok) on 02-Окт-10, 20:19
	> А не проще железячникам вместо увеличения количества ядер продолжать уменьшать техпроцессы,... Не проще... они уже уперлись в атомы... меньше (лептоны и кварки) пока не получается...
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

27. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
Сообщение от Gular (ok) on 02-Окт-10, 19:39
не знаю, насколько это реально и какие аналитики это писали :) , но почитайте, кто не видел еще: http://www.cnews.ru/news/top/index.shtml?2010/08/13/405037
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	43. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от pavlinux (ok) on 02-Окт-10, 20:19
	> не знаю, насколько это реально и какие аналитики это писали :) , > но почитайте, кто не видел еще: http://www.cnews.ru/news/top/index.shtml?2010/08/13/405037 ...К настоящему моменту сумма контрактов составила более $76,6 млн.   ... стоит задача к 2018 г. ... по 11 лямов в год. АвтоВАЗ наверно больше тратит :)
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	48. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от st_dog on 02-Окт-10, 20:29
	http://www.osp.ru/os/2010/05/13003034/
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

30. "Рост числа процессорных ядер приведет к необходимости смены ..."	+16 +/–
Сообщение от pavlinux (ok) on 02-Окт-10, 19:48
В общем, это проблема не OS, а производителей процессоров, контроллеров I/O, материнок... А чё они хотели??? Имея типовые проекты 14-и этажек, построить небосрёб в 1000 этажей, с одним лифтом??? :) И при этои оптимизироваться должны жители - создать расписание поездок на лифте, установить правила - чтоб жители ближайших пяти между собой этажей группировались для поездки как вниз так и вверх, так же группировались по весу, для оптимального заполнения лифта и, как следствие, увеличение траффика. Каждую вторую поездку лифт будет останавливаться только на чётных этажах. Оптимизировать по количеству запросов на обслуживание - если, к примеру, на 205 этаже сгруппировались 10 человек, на 378 - 8, ...., а на 998 - один, то с вероятностью 99.8 он из дома не выйдет :) ЖУЙ ВАМ!!! ДЕЛАЙТЕ НОРМАЛЬНЫЕ КОМПЫ И ПРОЦЕССОРЫ!!!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	51. "Рост числа процессорных ядер приведет к необходимости смены ..."	+3 +/–
	Сообщение от pavlinux (ok) on 02-Окт-10, 20:49
	>> вообщето вся тема -- в 70% сообщений только и говорит про кэши >> и шины.. как это относиться к OS ? > А что, предлагается рассматривать абстрактную ОС в вакууме, в отрыве от реально > существующего железа? :) Это он к тому, что 70% гимороя из-за железа. Авторы же исследования утверждают, что операционки не готовы к многоядерному фаршу! Нельзя быть двум человекам в одном месте, в одно и тоже время, если входить через одну дверь! (с) Я
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	41. "Рост числа процессорных ядер приведет к необходимости смены ..."	–16 +/–
	Сообщение от User294 (ok) on 02-Окт-10, 20:15
	> доказать не может. Жизненно же. Попробуйте распараллелить обсчет MD5 хеша для *одного* большого файла на 48 процов? Ну и как, получается? :)
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	59. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Crazy Alex (??) on 02-Окт-10, 21:39
	Ну вот конкретно md5 этот не параллелится. Ну и что? Компьютеры нынче отнюдь не однозадачные, масса всего параллельно крутится - заче параллелить один алгоритм, когда разных одновременно орда крутится?
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	116. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Аноним (??) on 03-Окт-10, 16:57
	>> доказать не может. > Жизненно же. Попробуйте распараллелить обсчет MD5 хеша для *одного* большого файла на > 48 процов? Ну и как, получается? :) А Вы попробуйте за итерацию подобрать хэш? Ну и как, получается? :) И явно 48 не обойдется подбор вне зависимости от размера файла. Неудачный пример.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	129. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от User294 (ok) on 04-Окт-10, 06:39
	> Неудачный пример. Так проблема в том что в реальном мире дофига этих "неудачных примеров", что и является той ложкой дегтя в бочке с медом многоядерности ;). Поэтому сделав 48-ядерный процессор есть риск обнаружить что спрос на него не такой уж и высокий (т.к. большая часть юзеров с их типовыми задачами просто не могут столько ядер поюзать). Будет еще один итаник? :)
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	149. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от аноним on 04-Окт-10, 22:06
	Надо на уровень выше думать, а не задачи, успешно решающиеся первопнями раздувать на 3 порядка. Зачем вам md5 терабайта? Чтобы повреждение данных обнаружить? Ну обнаружите, и что - будете терабайт перекачивать? Не смешите. Разбейте на блоки и считайте, и параллельте хоть на 500 ядер.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	156. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от User294 (ok) on 05-Окт-10, 06:03
	> на блоки и считайте, и параллельте хоть на 500 ядер. Однозначно! Только вот... 1) А 500 винчей - это нормально? Ну или толку то от 500 ядер, если прогрузится аж пяток ядер, а больше накопитель все-равно не выжимает читать? :) В общем то 500 ядер подразумевают еще и подсистему памяти и ввода-вывода способные их такие прокормить. А с этим как-то пока не очень. Как-то туго себе представляется майнстримовый компьютер с 500-канальной памятью. В суперкомпьютерах на такое могут наверное распереться но в штучных тиражах, да и есть менее геморные методы достижения сравнимой производительности, не требующие таких изгалений и вполне себе успешные, наконец. 2) Надо еще убедить весь мир делать так же. Перейти на такие протоколы/форматы данных и прочая. В принципе это возможно. Остается только вопрос - а захочет ли мир думать вот так? Или вы будете в гордом одиночестве сравнивать ваш параллельный md5 сами с собой. А скачав терабайтный файл с ремотного сервера ... будете по старинке жевать его в 1 поток, жутко чертыхаясь на то что суперпроц с его 48 ядрами обладает довольно хилыми по отдельности ядрами. В итоге желающих покупать 48-ядерные суперпроцы может оказаться как-то маловато и они могут загнуться и/или остаться штучными решениями.
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	165. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от fr0ster (ok) on 05-Окт-10, 08:23
	Куда то вы не туда повели, сами говорили о спецзаточенности многоядерников, и сами теперь рассматриваете их через призму универсальных, обывательских можно сказать, систем.
	Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

	172. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от Dron (ok) on 08-Окт-10, 11:53
	MD5 - это конечно не аргумент... И один файл - это тоже не аргумент. :) То, что пока мало задач, которые могут эффективно использовать многоядерность - это вопрос времени. Раньше любая игрушка умещалась на FDD три раза, и все мучались вопросом - чем же можно загрузить 4 мегабайта памяти на крутых и никому не доступных x386... :) Сейчас такие вопросы не стоят, благополучно загрузили... Будет 1000 ядер - возникнут и алгоритмы, которые смогут их эффективно загрузить. И линукс не заставит себя ждать... за 5 лет они его 3 раза полностью переписать успеют. :)
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	54. "Рост числа процессорных ядер приведет к необходимости смены ..."	+2 +/–
	Сообщение от cmp (??) on 02-Окт-10, 21:10
	В целом - лаконично, но врядле это проблема "производителей процессоров, контроллеров I/O, материнок", нет лучше инструмента для копания, чем лопата, пока у тебя две руки и ноги, с увеличением конечностей эффективность использования будет падать, (неужели чтобы это понять нужно быть Исследователем из Массачусетского Технологического института...) Будет ли эффективным писать новую ОС для эффективной работы на 1000 ядерном проце? А если вспомнить про виртуализацию.. видимо, они там в институте чета покурили и их на панику прибило, - "о боже, небо падает".
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

58. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
Сообщение от StrangeAttractor (ok) on 02-Окт-10, 21:38
> Рост числа процессорных ядер приведет к необходимости смены архитектуры ОС Новости от Капитана Очевидность... Не прошло и n лет как до них дошло...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

63. "Рост числа процессорных ядер приведет к необходимости смены ..."	+1 +/–
Сообщение от Zenitur on 02-Окт-10, 22:01
Я не понял: так надо для второго ядра компилировать второе ядро, или нет?!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	103. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от СуперАноним on 03-Окт-10, 12:43
	А, теперь понятно, что у тебя всё так вечно тормозит :))
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	110. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от pavlinux (ok) on 03-Окт-10, 15:01
	Каждому ядру по ядру! --- А ваще, если сделаешь 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] ...
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	111. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от fr0ster (ok) on 03-Окт-10, 15:08
	> Каждому ядру по ядру! По два "ядра", и за ошибки отрывать по одному.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

93. "Запрашивает Миша Рыцаревъ"	–2 +/–
Сообщение от ua9oas on 03-Окт-10, 07:06
Интересно, а как заставить работать XP на многоядерных процессорах? (она же в отличие от "7" не может этого делать и заодно "7" тяжелее ее). Например можно ли создать такое ПО, которое бы для XP это могло бы делать? А то ведь есть же ПО, которое позволяет использовать более 2 Гб оперативной памяти в 32битных ОС.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	96. "Запрашивает Миша Рыцаревъ"	+/–
	Сообщение от Zenitur on 03-Окт-10, 08:50
	У AMD есть драйвер, оптимизирующий работу с несколькими процессорами, так как сам Windows это делает хуже. Драйвер, кстати, творит чудеса. Ну как-как... Разработчики программ добавляют возможность использования нескольких ядер процессора, оптимизируя тем самым их выполнение. Не удивлюсь, если Windows-пользователи с радостью готовы отдать одно процессорное ядро антивирусу. Я бы посмеялся. Или ты имеешь в виду основные системные библиотеки? Не знаю, что с ними не так. Если даже системная программа не умеет распараллеливаться, попутно запуститься другая, которая займёт второе, третье, четвёртое, пятое, шестое ядро... Была поддержка многоядерности в XP, была. Потому что раньше были популярны многопроцессорные конфигурации. НЕ многоядерные, а многопроцессорные. На сервере, например.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	99. "Запрашивает Миша Рыцаревъ"	+/–
	Сообщение от odus (ok) on 03-Окт-10, 10:17
	Если имеется в виду программа AMD DualCore Optimizer, то для Phenom II, Athlon II эта программа не нужна Что касается многоядерных конфигураций то Windows XP начали делать в то время когда их не было
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

100. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
Сообщение от odus (ok) on 03-Окт-10, 10:49
Для 100-ядерных систем сделают Linux kernel 2.8 :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	104. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от СуперАноним on 03-Окт-10, 12:51
	Да уж пусть его 3.0.X обзывают. А то у людей только что приходящих в Linux создаётся впечатление, что ядро очень медленно развивается: как было 10 лет назад 2.*, так и осталось.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	113. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от cmp (??) on 03-Окт-10, 15:28
	> Да уж пусть его 3.0.X обзывают. А то у людей только что > приходящих в Linux создаётся впечатление, что ядро очень медленно развивается: как > было 10 лет назад 2.*, так и осталось. ага, 5 споловиной в квадрате, если у людей мозга нет понять почему..., или пусть убунту пользуют она аж 10.х. уже, аж на три поколения круче виндовс7 этож кокая моща,
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

106. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
Сообщение от weldpua2008 (ok) on 03-Окт-10, 14:25
У Меня вопрос. Вы тут про параллельное выполнение одного алгоритма говорите... 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-а диска. Один быстрый, не ёмкий и исключительно под ОСь, а другой исключительно под файлопомойку.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	107. "Рост числа процессорных ядер приведет к необходимости смены ..."	+2 +/–
	Сообщение от fidaj (ok) on 03-Окт-10, 14:32
	> А вообще Я не представляю как при скорости чтения до ~150Мб/сек 30-50 > процессов ОДНОВРЕМЕННО будут читать из диска разные данные, причём из разных > областей. > Видимо не долго жить жёстким под ОСь. процессоры уже ооо-чень давно ничего с дисков не "читают"...
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	114. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от weldpua2008 (ok) on 03-Окт-10, 16:30
	>> А вообще Я не представляю как при скорости чтения до ~150Мб/сек 30-50 >> процессов ОДНОВРЕМЕННО будут читать из диска разные данные, причём из разных >> областей. >> Видимо не долго жить жёстким под ОСь. > процессоры уже ооо-чень давно ничего с дисков не "читают"... ...а есть различия?: процессов(программ) и процессоров... Или у Вас волшебные OpenOffice, Firefox, mc, Kate, Mplayer, etc... с диска ничего не читают/пишут?
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	115. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от fidaj (ok) on 03-Окт-10, 16:33
	>>> А вообще Я не представляю как при скорости чтения до ~150Мб/сек 30-50 >>> процессов ОДНОВРЕМЕННО будут читать из диска разные данные, причём из разных >>> областей. >>> Видимо не долго жить жёстким под ОСь. >> процессоры уже ооо-чень давно ничего с дисков не "читают"... > ...а есть различия?: > процессов(программ) и процессоров... > Или у Вас волшебные OpenOffice, Firefox, mc, Kate, Mplayer, etc... с диска > ничего не читают/пишут? уупс - я о другом :)
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	121. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от svchost (ok) on 03-Окт-10, 17:49
	> Я так вижу, что в ящике будет 2-а диска. Один быстрый, не > ёмкий и исключительно под ОСь, а другой исключительно под файлопомойку. Это сейчас только такое извращение у некоторых есть. Покупают интеловские SSD чисто под систему, и терабайтники под файлопомойку. Потом то уж должны же уйти в мир иной эти магнитные крутящиеся механизмы (вместе с оптическими дисками), а их место займут подешевевшие и налаженные SSD диски с крутыми и быстрыми интерфейсами (думается, SATA тоже уйдет как раритет :) ) А вот когда серийное производство в Китае началось бы этих SSDшек, то их шлепали бы как пирожки, тем более, что там меньше нужно железа и к качеству менее критично ввиду отсутствия механики.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	150. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от аноним on 04-Окт-10, 22:12
	> Хм... Tasks: 159 total Нет, это. Вот это - 2 running. Правда, тут потоки не считаются. О вас с 2 задачами речь вообще не идет, вы могли бы и на первопнях сидеть на своих печатных машинках. > А вообще Я не представляю как при скорости чтения до ~150Мб/сек 30-50 > процессов ОДНОВРЕМЕННО будут читать из диска разные данные, причём из разных > областей. Да будет вам известно, нормальные CPU-hungry задачи ничего не читают с диска. Более того, они даже из памяти ничего не читают - все в регистрах и кэше, иначе быстро не получится, сколько ядер не пихай.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

123. "Рост числа процессорных ядер приведет к необходимости смены ..."	+1 +/–
Сообщение от zuborg on 03-Окт-10, 18:34
Solaris 10 + UltraSPARK T1 8 cores x 4 threads (= 32 threads total) 2005-й год, древняя технология по современным меркам
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	128. "Рост числа процессорных ядер приведет к необходимости смены ..."	+1 +/–
	Сообщение от очередной аноним on 04-Окт-10, 00:49
	http://ru.sun.com/products/servers/highend/m9000/index.jsp Содержит 32 или 64 высокопроизводительных процессоров SPARC64 VI (двухъядерных) или SPARC64 VII (четырехъядерных) и до 2 ТБ системной памяти Итого 256 ядер Г..но эти ваши лялихи
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

142. "Рост числа процессорных ядер приведет к необходимости смены ..."	+1 +/–
Сообщение от gkv311 (ok) on 04-Окт-10, 10:05
Ещё с год назад читал про это от представителей Microsoft (про будущие Windows). Основная идея была в том, что эффективнее будет целиком отдавать часть ядер каждому процессу. Как-то заторможенно они это исследование решили провести...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	143. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от fr0ster (ok) on 04-Окт-10, 10:14
	> Ещё с год назад читал про это от представителей Microsoft (про будущие > Windows). Основная идея была в том, что эффективнее будет целиком отдавать > часть ядер каждому процессу. > Как-то заторможенно они это исследование решили провести... ИМХО это мало что даст, "бутылочное горлышко" в другом месте будет, не более. Линейной прибавки производительности не достичь:)
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	151. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от аноним on 04-Окт-10, 22:12
	> Ещё с год назад читал про это от представителей Microsoft Ага, а у них affinity mask до сих пор в long'е. На 32 битах 32 ядра, на 64 битах 64, больше хочешь-не хочешь ничего не будет :)))
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

157. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
Сообщение от stimpack on 05-Окт-10, 06:12
Думается, из всего этого количества байт, что мы все вбили здесь, легко можно сварганить патч для ядра с требуемым для решения этой проблемы функционалом. Жаль лишь, что это байты скорее от миллиона мартышек, что пытаются написать "Войну и Мир", а не от того, кто в состоянии этот патч.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	166. "Рост числа процессорных ядер приведет к необходимости смены ..."	+/–
	Сообщение от fr0ster (ok) on 05-Окт-10, 08:25
	> Жаль лишь, что это байты скорее от миллиона мартышек, что пытаются написать > "Войну и Мир", а не от того, кто в состоянии этот > патч. Какой "Война и Мир"? Мы тут все максимум пытаемся по... самолюбие почесать и развлекаемся немного. Любая серьезная тема будет обсуждаться в личке или еще где.
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема