Комментарии 100
Умело он нагрузил 256 ядер на 95%. Вычисляет pi?
Вообще было бы интереснее посмотреть на эту «256-процессорную машинку». По моим прикидкам это будет машинище, а не машинка.
Вообще было бы интереснее посмотреть на эту «256-процессорную машинку». По моим прикидкам это будет машинище, а не машинка.
в гта4 наверное играет.
Он просто запустил Windows 7.
Ну не знаю. Такое представление мне не кажется безумно удобным.
Значительно лучше был бы график типа такого со сносками:
Значительно лучше был бы график типа такого со сносками:
256 разноцветных линий на одном графике? в ситуации как на скриншоте в статье будет тяжело разглядеть что-либо
гм… ну есть несколько вариантов: либо выбирать, какие ядра отображать на графике, но такой способ не очень уместен… скажем так, на любителя.
либо, второй вариант: несколько таких графиков. 16 графиков, по 16 ядер на каждый, к примеру.
либо, третий вариант, выводить на этот график, который я указал сверху, только те ядра которые пересекли определенный (предустановленный пользователем) порог. Например, 70% загрузки.
вот как-то так :)
либо, второй вариант: несколько таких графиков. 16 графиков, по 16 ядер на каждый, к примеру.
либо, третий вариант, выводить на этот график, который я указал сверху, только те ядра которые пересекли определенный (предустановленный пользователем) порог. Например, 70% загрузки.
вот как-то так :)
нет, он вычисляет последнюю цифру pi =)
а вообще, это ведь просто нагрузить любую машинку на максимум. Есть N-ядер. Запускаем N бесконечных циклов…
Он использует виртуализацию на Hyper-V от microsoft
на самом деле, ядра заняты прорисовыванием графиков для диспетчера задач.
дискету форматирует
А радиатор там от тепловоза наврено
^C ^V
Мне кажется, что если рисовать графики не контурами а заливать нижние, загруженные части — вполне можно будет увидеть простаивающие ядра.
Думаю View -> CPU History -> One Graph, All CPUs спасет положение. ;)
Тут на мой взгляд, зависит от того зачем ему мониторить 256 процессоров. Допустим, если нужно вычислить какой процессор не нагружен, хватит и простого наложение графиков: работающие будут болтаться вверху, а свободный снизу. Как-то так =)
Интересно, как это будет выглядеть в Gnome? Меня и 4 то ядра при просмотре HD гипнотизируют :)
Оператор атомной электростанции наверное чувствует себя также глядя на свои приборы.
Ну возможным решением я бы предложил: строить усредненный график, цветом(изменением от красного к синему например) показывающий количество незадействованных ядер(«температура» загрузки) — получится своеобразная цветовая индикация.
Параллельно выделить 1,2 сигнальные зоны(например уровень 75 и 25 % от загрузки), и выводить помимо усредненного графика еще всего 2: количество(числовое значение) ядер с загрузкой выше 75% и с загрузкой ниже 25%.
Количество сигнальных зон можно сделать изменяемым от 2 до 10, как и сигнальные уровни.
Проблема будет решена: получаем абсолютно информативный и незагруженный график.
Параллельно выделить 1,2 сигнальные зоны(например уровень 75 и 25 % от загрузки), и выводить помимо усредненного графика еще всего 2: количество(числовое значение) ядер с загрузкой выше 75% и с загрузкой ниже 25%.
Количество сигнальных зон можно сделать изменяемым от 2 до 10, как и сигнальные уровни.
Проблема будет решена: получаем абсолютно информативный и незагруженный график.
Если вы имели что то вроде инфракрасного снимка, то идея вполне интересна. Прямо в таком же порядке оставить квадраты под ядра, только не рисовать на них графики, а закрашивать цветом, от зеленого к красному в зависимости от загрузки.
Не совсем.
Цвет меняет не табло, а сам усредненный график загруженность процессора(-ов).
А помимо усредненного графика строится еще 1,2(можно гистограммой или круговой диаграммой), учитывающие сколько ядер находятся в той или иной сигнальной зоне (например 200 ядер нагружены больше 75%, 50 меньше 25%, 6 посередине — видим что распараллеливание вычислений реализованно неверно/не доконца).
Ведь важно знать, по-сути, не насколько каждое ядро нагруженно, а насколько равномерно производятся вычисления процессором и как эффективно используется его мощность.
Цвет меняет не табло, а сам усредненный график загруженность процессора(-ов).
А помимо усредненного графика строится еще 1,2(можно гистограммой или круговой диаграммой), учитывающие сколько ядер находятся в той или иной сигнальной зоне (например 200 ядер нагружены больше 75%, 50 меньше 25%, 6 посередине — видим что распараллеливание вычислений реализованно неверно/не доконца).
Ведь важно знать, по-сути, не насколько каждое ядро нагруженно, а насколько равномерно производятся вычисления процессором и как эффективно используется его мощность.
Ну плюсом можно применить к этому группировку ядер.
>Ведь важно знать, по-сути, не насколько каждое ядро нагруженно, а насколько равномерно производятся вычисления процессором и как эффективно используется его мощность.
По общей окраске окна и будет видно утилизацию процессора. Будет достаточно беглого взгляда, чтобы это понять. а вот раскрашивать графики… фиг его знает, не думаю, что это сильно поможет визуализации.
По общей окраске окна и будет видно утилизацию процессора. Будет достаточно беглого взгляда, чтобы это понять. а вот раскрашивать графики… фиг его знает, не думаю, что это сильно поможет визуализации.
Можно так:
Кажется MrTiM выше что-то похожее предлагает.
Кто-нибудь знает ящик, где 256 x86 ядер? Мне в голову ничего кроме altix и больших sun'овских железяк неприходит.
А почему обязательно x86? MS вроде не отказывалась от выпуска серверных версий для Itanium. Может это Altix или Integrity.
В результатах SPEC CPU 2006 максимум, что я нашёл для x86 — 96 ядер (на 6-ядерных Xeon-ах).
В результатах SPEC CPU 2006 максимум, что я нашёл для x86 — 96 ядер (на 6-ядерных Xeon-ах).
если не х86, то в видеокартах nvidia GTX 280, например, 240 ядер
ставишь 2 по SLI и имеешь 500 ядер в обычном десктопе
а потом через CUDA их можно нагрузить чем-нибудь
ставишь 2 по SLI и имеешь 500 ядер в обычном десктопе
а потом через CUDA их можно нагрузить чем-нибудь
В блоге сказано, что нагрузка создаётся MS SQL. GPU — это хорошо, конечно, но (пока?) это довольно ограниченный класс задач. Тогда уж Tilera можно вспомнить: 64 VLIW-ядра на PCI-E плате.
А сабжевая картинка — это HP Integrity Superdome на итаниках, в урл надо было заглянуть, оказывается :-) Интересно, там 256 ядер или 128 с Montvale-овским SMT.
А сабжевая картинка — это HP Integrity Superdome на итаниках, в урл надо было заглянуть, оказывается :-) Интересно, там 256 ядер или 128 с Montvale-овским SMT.
Вроде бы следующая mac os snow leopard уже будет использовать gpu как дополнение к cpu не только для графических задач.
Photoshop cs4, например, уже использует.
А cuda — приятная штука, компилятор C для видеокарты. Думаю, очень скоро это все дело получит широкое распространение. Ведь уже сейчас работает на обычных видеокартах (втч и на недорогих, и на встроенных), дело только в софте.
Photoshop cs4, например, уже использует.
А cuda — приятная штука, компилятор C для видеокарты. Думаю, очень скоро это все дело получит широкое распространение. Ведь уже сейчас работает на обычных видеокартах (втч и на недорогих, и на встроенных), дело только в софте.
НЛО прилетело и опубликовало эту надпись здесь
Очень насущная проблема. Надо срочно что-то решать.
Правильно — двумястами пятьюдесятью шестью.
хм, а не пятидесятью?
Нет.
alls правду глаголет; по крайней мере согласно этому источнику
НЛО прилетело и опубликовало эту надпись здесь
интересно, как будет выглядеть загрузка linux с 256 пингвинами :)
Спасибо, давно хотел узнать, как будет выглядеть диспетчер задач, когда в компьютере больше 4 ядер.
Может еще покажете, как выглядят 8, 16 ядер?
Может еще покажете, как выглядят 8, 16 ядер?
Стоит задаться вопросом, почему же на кластерах с тысячами ядер не встаёт такая проблема? ;-) а при серьёзных вычислениях мониторят не только загрузку ядер, но и I/O на диск, а на кластерах ещё и сетевую активность…
А я вот на Стиме как-то проходил опрос по железной составляющей моей машины. Любопытства ради полез в результаты — у кого как (моя шестилетняя старушка, оказывается, еще посреди стоит). Выяснилось, что на Стиме играет два человека, у которых 128 ядер. Мне не совсем ясны две вещи:
1. Кто эти люди? Охранники Пиксара по ночам развлекаются что ли?
2. Во что они играют? В Портал?
Пруфлинка, к сожалению, нет. Если здесь есть стимоиды, которые недавно проходили этот опрос, прошу поделиться ссылкой.
1. Кто эти люди? Охранники Пиксара по ночам развлекаются что ли?
2. Во что они играют? В Портал?
Пруфлинка, к сожалению, нет. Если здесь есть стимоиды, которые недавно проходили этот опрос, прошу поделиться ссылкой.
НЛО прилетело и опубликовало эту надпись здесь
Бросив взгляд на такую картинку сразу же понял, что комп только что чем-то нагрузили, ибо почти на всех ядрах загрузка большая. По крайней мере в данном скриншоте траблов со сбором информации нет.
Хуже, когда ядра работают неравномерно, тогда действительно непонятно.
Хуже, когда ядра работают неравномерно, тогда действительно непонятно.
НЛО прилетело и опубликовало эту надпись здесь
Так вот она какая, ядерная война :)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А если пользователь не один? Выделили кому-то 10 ядер, а у него половина не работают — так заметишь тут :-))
Подумаешь в кластере десяток машин умрет, пользователи сайта и не заметят.
Эти машины созданы явно не для домохозяек, а для ресурсоемких вычислений, где каждая минута простоя стоит миллионов. В такой ситуации мониторинг и нахождение узких мест в алгоритмах распараллеливания — чуть ли не передовая задача.
Эти машины созданы явно не для домохозяек, а для ресурсоемких вычислений, где каждая минута простоя стоит миллионов. В такой ситуации мониторинг и нахождение узких мест в алгоритмах распараллеливания — чуть ли не передовая задача.
Вовремя я Erlang изучать начал:)
В нём нет модификации переменных и от этого программы на нём хорошо параллелятся?
Говорят, что на N ядерном процессоре Erlang программа будет работать в N раз быстрее:)
Ну а по делу, как я понял два дня с ним поигравшись, отсутствие shared памяти на скорость сильно не влияет, это больше для избежания ошибок и дэдлоков.
Основной прирост производительности в самой идеалогии Конкуррентно Ориентированного Программирования.
Типо на каждый чих создаем новый процесс, и синхронизация между процессами происходит через сообщение, что быстрее чем через shared память со всякими локами и тд.
А теперь, каждый процесс выполняется на своем ядре — это же просто сказка какая-то!:) Отсюда и увеличение скорости.
А неизменяемые переменные по-моему вообще во всех функциональных языках есть.
Ну а по делу, как я понял два дня с ним поигравшись, отсутствие shared памяти на скорость сильно не влияет, это больше для избежания ошибок и дэдлоков.
Основной прирост производительности в самой идеалогии Конкуррентно Ориентированного Программирования.
Типо на каждый чих создаем новый процесс, и синхронизация между процессами происходит через сообщение, что быстрее чем через shared память со всякими локами и тд.
А теперь, каждый процесс выполняется на своем ядре — это же просто сказка какая-то!:) Отсюда и увеличение скорости.
А неизменяемые переменные по-моему вообще во всех функциональных языках есть.
Ну-ну, а сообщения реализуются по вашему как? ;)
Говорят много чего, главное понимать область применимости и правильно понимать преимущества языка.
Говорят много чего, главное понимать область применимости и правильно понимать преимущества языка.
Всмысле сообщения между процессами реализуются через shared память?
Не факт. Там процессы на уровне виртуальной машины а не на уровне потоков ОС. Но это если несколько процессов на одном ядре.
Когда выполнение паралелится на несколько ядер, то под каждое ядро запускается экземпляр интерпретатора, который обрабатывает свои процессы.
Смысл точно такой же, как если бы мы распаралеливали приложение на две разные машины.
А насчет области применимости, я в предыдущем посте ничего не говорил:)
Не факт. Там процессы на уровне виртуальной машины а не на уровне потоков ОС. Но это если несколько процессов на одном ядре.
Когда выполнение паралелится на несколько ядер, то под каждое ядро запускается экземпляр интерпретатора, который обрабатывает свои процессы.
Смысл точно такой же, как если бы мы распаралеливали приложение на две разные машины.
А насчет области применимости, я в предыдущем посте ничего не говорил:)
В то-то и штука, что основное преимущество Эрланга не в «лёгких» потоках или скорости, а в следствиях из-за разделения: уменьшении числа ошибок у программистов, которых начинают обучать с этого языка, простота написания программ, логика которых не подразумевает обильное использование сообщений.
А если считать, что ВМ предоставляет нам возможность программировать как будто бы мы использовали распределённую систему, то нам снова никуда не деться от латентности этих пересылок, их реализация в любом случае подразумевает передачу некоторых данных от нити к нити через ВМ, что не может обойтись без накладных расходов.
А если считать, что ВМ предоставляет нам возможность программировать как будто бы мы использовали распределённую систему, то нам снова никуда не деться от латентности этих пересылок, их реализация в любом случае подразумевает передачу некоторых данных от нити к нити через ВМ, что не может обойтись без накладных расходов.
А насчет области применимости, я в предыдущем посте ничего не говорил:)Согласитесь, не всякую программу, и даже не всякую параллельную, можно реализовать на Эрланге быстрее, чем на чём-то другом. Потому что она может не очень хорошо согласовываться с его идеологией, к примеру использовать много пересылок.
Насчет применимости — естественно ерланг это не панацея для любых задач. У него своя область, достаточно узкая(хотя он вроде как и «язык общего назначения») — это распределенные, легко расширяемые и отказоустойчивые системы(одна подмена кода модуля прямо в процессе выполнения чего стоит!:)). Я с этим и не собирался спорить.
Насчет обучения — связи с обучением на ерланге и меньшим числом ошибок у начинающих программистов я не вижу. Вообще это не язык для обучения программированию, у него задачи совсем другие. Да и вообще, миром правят императивные языки:)
>сновное преимущество Эрланга не в «лёгких» потоках или скорости
С этим я совсем не согласен. Простота написания и меньшее количество ошибок — это следствие реализации(сообщения а не shared memory). Именно легкие изолированные процессы это основная фича ерланга, и его идеологии конкурентно ориентированного программирования.
И то что процессы у него не являются системными потоками — это огромный выигрыш в скорости, ведь каждое действие с потоком — это системный вызов. По-этому и обмен сообщениями происходит значительно бычтрее.
>логика которых не подразумевает обильное использование сообщений
Как раз наоборот, подразумевает.
Насчет обучения — связи с обучением на ерланге и меньшим числом ошибок у начинающих программистов я не вижу. Вообще это не язык для обучения программированию, у него задачи совсем другие. Да и вообще, миром правят императивные языки:)
>сновное преимущество Эрланга не в «лёгких» потоках или скорости
С этим я совсем не согласен. Простота написания и меньшее количество ошибок — это следствие реализации(сообщения а не shared memory). Именно легкие изолированные процессы это основная фича ерланга, и его идеологии конкурентно ориентированного программирования.
И то что процессы у него не являются системными потоками — это огромный выигрыш в скорости, ведь каждое действие с потоком — это системный вызов. По-этому и обмен сообщениями происходит значительно бычтрее.
>логика которых не подразумевает обильное использование сообщений
Как раз наоборот, подразумевает.
> Да и вообще, миром правят императивные языки:)
Увидеть это и было целью моих комментариев ;)
согласен с концептуальной стороной вопроса(про потоки, это, я надеюсь, любому ясно), жаль только пока не очень распространены компиляторы Эрланга и боюсь что накладки за счёт интерпретации пока что могут уничтожать выигрыш в скорости переключения, если сравнивать с C(++). Всё жду когда закончится сессия и обновлю софт на кластере, думаю провести сравнение на разных типах задач.
Увидеть это и было целью моих комментариев ;)
согласен с концептуальной стороной вопроса(про потоки, это, я надеюсь, любому ясно), жаль только пока не очень распространены компиляторы Эрланга и боюсь что накладки за счёт интерпретации пока что могут уничтожать выигрыш в скорости переключения, если сравнивать с C(++). Всё жду когда закончится сессия и обновлю софт на кластере, думаю провести сравнение на разных типах задач.
>Увидеть это и было целью моих комментариев ;)
Поклонник императивных?:)
Я тоже долго боялся смотреть в сторону функциональных, особенно когда с первого захода Scheme снесла мне крышу на простой задаче вывести длину списка:)
А сейчас, после более менее плотного знакомства с ерлангом, мне даже нравиться начало. Но любимый Ruby все равно ни на что не променяю:)
Насчет компиляторов — их помоему вообще нет. У них там не просто интерпретатор, а виртуальная машина. Сначала исходник в байткод компилируется, что уже быстрее. И насчет производительности, демаю с этим тоже все норм должно быть(ну, с/с++ конечно будет проигрыш). В эриксоне его же использовали в электронике своей, а там с ресурсами напряженка.
>думаю провести сравнение на разных типах задач.
Было бы очень интересно увидеть результаты:)
Поклонник императивных?:)
Я тоже долго боялся смотреть в сторону функциональных, особенно когда с первого захода Scheme снесла мне крышу на простой задаче вывести длину списка:)
А сейчас, после более менее плотного знакомства с ерлангом, мне даже нравиться начало. Но любимый Ruby все равно ни на что не променяю:)
Насчет компиляторов — их помоему вообще нет. У них там не просто интерпретатор, а виртуальная машина. Сначала исходник в байткод компилируется, что уже быстрее. И насчет производительности, демаю с этим тоже все норм должно быть(ну, с/с++ конечно будет проигрыш). В эриксоне его же использовали в электронике своей, а там с ресурсами напряженка.
>думаю провести сравнение на разных типах задач.
Было бы очень интересно увидеть результаты:)
Вот и мне интересно. Была очень большая тема про Эрланг, в его блоге наверное, мы там крупно так сцепились с ярыми поклонниками. Но в конце концов всё-таки мне удалось их убедить, что Эрланг хорош именно для того, для чего его применяет Эриксон. Сам я больше по вычислительной части и слабо верю в его превосходство над Си и Фортраном в этом. Хотя тесты на сайте языка как обычно говорят об обратном :)
Ну не только для коммутаторов:)
ejabberd например. Или yaws. Так что ерланг хорош для серверов.
А насчет вычислений, тут сценарий может быть такой. В ерланге достаточно просто подключается код на других языках.
Так например для поиска тех же простых чисел, вычисления — на си, а распараллеливание — на ерланге.
Хотя с простыми числами не очень пример, тут сильно алгоритм не распараллелишь.
Но смысл вобщем в том, что критичные куски — это сишный код.
А сравнивать чисто на вычислительных задачах с компилируемыми языками смысла нет, тут и так понятно кто победит:)
Мне почему-то сразу вспоминаются смешные бенчмарки типо «Java 2 times faster then C++!»:)
ejabberd например. Или yaws. Так что ерланг хорош для серверов.
А насчет вычислений, тут сценарий может быть такой. В ерланге достаточно просто подключается код на других языках.
Так например для поиска тех же простых чисел, вычисления — на си, а распараллеливание — на ерланге.
Хотя с простыми числами не очень пример, тут сильно алгоритм не распараллелишь.
Но смысл вобщем в том, что критичные куски — это сишный код.
А сравнивать чисто на вычислительных задачах с компилируемыми языками смысла нет, тут и так понятно кто победит:)
Мне почему-то сразу вспоминаются смешные бенчмарки типо «Java 2 times faster then C++!»:)
Для вычислительной части, по отзывам, очень хороши семейства APL: J, K, Q :)
больше интересно как винда расположит, скажем, 7 ядер… или… 131)
Не понял проблемы.
Для отображения загрузки 256 ядер нужно 16x16 картиночек-гистограмм. На мониторе 1024x768 лехко доступно 700x700 точек для отображения состояния 256 ядер, при этом размер картинки-гистограммы может быть ~35x35 пикселей.
Мне для мониторинга одного проца хватает апплета 30x30 пикселей на панели задач.
Для отображения загрузки 256 ядер нужно 16x16 картиночек-гистограмм. На мониторе 1024x768 лехко доступно 700x700 точек для отображения состояния 256 ядер, при этом размер картинки-гистограммы может быть ~35x35 пикселей.
Мне для мониторинга одного проца хватает апплета 30x30 пикселей на панели задач.
можно нагрузку ядра обозначать высотой тона звука. В сумме будет получаться мелодия, потом специалисты только по звуку будут определять какого рода задача решается системой.
Добавлю-ка я в этот замечательный пост 2009 года ссылку на статью "Использование диспетчера задач при числе логических процессоров 64 и более" и вставлю один скриншот оттуда
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как выглядят 256 ядер?