Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 140
Вопрос в том, нужен ли суперкомпьютер, доступный каждому? Ведь набор задач, а уж тем более повседневных программ поддерживающих параллелизм не такой большой. И в большинстве случаях видюха за 100$ способна их сильно разогнать (и фотошоп и многие видеоредакторы поддерживают видеокарты).
А вот отсутствие ведещего процессора с частотой под 2-3 ГГц может значительно затормозить обычные приложения.
А вот отсутствие ведещего процессора с частотой под 2-3 ГГц может значительно затормозить обычные приложения.
Тут как раз получается проблема курицы и яйца — сейчас нет массовых параллельных приложений, так как нет массового железа и наоборот. Видеокарты не в счет, так как они больше заточены под векторные операции. Лет 10 назад я учавствовал в проекте по разработке системы по динамическому распаралеливанию программ, и тогда оно загнулось имхо из-за двух причин: не было дешевого железа и долгое нежелание сделать это opensource. Сейчас в моду вошли функциональные языки на которых подобные можно сделать сильно проще, чем на C/C++.
Урра! Erlang рулит! :)
Что-то мне не верится, что можно автоматически красиво распараллеливать на железки типа этой и особенно на видеокарты. Причина — надо очень очень аккуратно делить ресурсы, даже на видеокартах, где теоретическая производительность гигансткая, надо очень и очень сильно думать, как бы все рационально распараллелить и человек далеко не всегда может сделать это быстро.
Хотя получение даже 5% теоретической производительности видеокарт на халяву автоматически было бы хорошо, но пока что очень туго все идет.
Хотя получение даже 5% теоретической производительности видеокарт на халяву автоматически было бы хорошо, но пока что очень туго все идет.
Расскажите подробнее, пожалуйста, хотя бы в комментарии. Тема динамического распараллеливания программ крайне интересна. С какой стороны заходили?
Если вы посмотрите на результаты параллельных вычислений на разных языках на Computer Language Benchmarks Game, можно заметить, что впереди планеты всей Fortran, которому 55 лет в обед, и ADA, которой почти 33. И C/C++ не сильно отстают. Так что пользоваться большим количеством ядер для вычислений пользоваться умеют уже многие, даже shell script. Erlang/OTP хорош там, где много раздельных машин в кластере.
Были бы задачи. А для устройства за $99 они очень быстро найдутся.
Были бы задачи. А для устройства за $99 они очень быстро найдутся.
> Вопрос в том, нужен ли суперкомпьютер, доступный каждому?
Хорошо, что вопрос, а не утверждение, как у DEC в 1977 году:)
Во-первых, такой суперкомпьютер способен уже сейчас принести пользу профессионалам, работающим, например, с 3D и видео — дело лишь за поддержкой в софте.
Во-вторых, само по себе появление столь дешевых домашних ресурсов (в качестве альтернативы арендуемым облачным) позволит появиться и вырасти профессиям и бизнесам, занимающимся обработкой каких-нибудь Big Data, биоинформатикой и т. д., любыми задачами, для которых производительности обычного десктопного процессора уже принципиально мало, тем более что процессоры эти все больше затачиваются под обработку мультимедиа и интерфейсов и, аутсорся вычислительную функцию на другое железо, такое как видеокарты или сабж, фокусируются на управляющей.
В общем, получится как с обычными ПК, домашними серверами и NAS — было бы железо, а задачи найдутся.
Хорошо, что вопрос, а не утверждение, как у DEC в 1977 году:)
Во-первых, такой суперкомпьютер способен уже сейчас принести пользу профессионалам, работающим, например, с 3D и видео — дело лишь за поддержкой в софте.
Во-вторых, само по себе появление столь дешевых домашних ресурсов (в качестве альтернативы арендуемым облачным) позволит появиться и вырасти профессиям и бизнесам, занимающимся обработкой каких-нибудь Big Data, биоинформатикой и т. д., любыми задачами, для которых производительности обычного десктопного процессора уже принципиально мало, тем более что процессоры эти все больше затачиваются под обработку мультимедиа и интерфейсов и, аутсорся вычислительную функцию на другое железо, такое как видеокарты или сабж, фокусируются на управляющей.
В общем, получится как с обычными ПК, домашними серверами и NAS — было бы железо, а задачи найдутся.
давайте прикинем:
(говорим об одинарной точности. суперкомпы сравнивают в двойной)
нынешний игровой комп способен выдать 15GFlops/W в GPU и 4GF/W в CPU (по CPU я просто прикинул. по GPU взял из википедии)
итоговый бенч такого компа может вылится до 5TFlops.
И можем добавить еще парочку видюх, по GF/W не выиграем, но в абсолюте можно довести до 10-13TFlops.
к маю 2013 и GPU и CPU поднимут еще процентов на 30.
субж обещает 70GFlops/W (оч хорошо), но в абсолюте 90GFlops — мощность средненького CPU без видюх.
как я понимаю, энтузиастам выгоднее абсолютные цифры, нежели деленные на ватты
т.е. сейчас на своем домашнем компе вы можете решать те же задачи или даже на 2 порядка больше, что обещает субж (зависит от компа и видюх).
а с учетом того, что на компе мы можем развернуть любую удобную нам ОСь и SDK (можно поставить OpenCL SDK от Intel или AMD, чтобы OpenCL был доступен на CPU), энтузиасты еще в бОльшем плюсе.
а есть еще CUDA, DirectCompute, C++ AMP, обещают Java VM на GPU и всякие деббагеры и тулзы.
субж обещает Ubuntu, какую-нибудь C++IDE и, наверное, OpenCL… вряд ли новый ЯП изобретут.
итого:
как альтернатива большим собратам это конечно хорошо, но в итоге частнику от субжа как-то не очень.
если у них стОящие разработки, то лучше бы им их продать большим игрокам (GPU & CPU), выиграют все
(говорим об одинарной точности. суперкомпы сравнивают в двойной)
нынешний игровой комп способен выдать 15GFlops/W в GPU и 4GF/W в CPU (по CPU я просто прикинул. по GPU взял из википедии)
итоговый бенч такого компа может вылится до 5TFlops.
И можем добавить еще парочку видюх, по GF/W не выиграем, но в абсолюте можно довести до 10-13TFlops.
к маю 2013 и GPU и CPU поднимут еще процентов на 30.
субж обещает 70GFlops/W (оч хорошо), но в абсолюте 90GFlops — мощность средненького CPU без видюх.
как я понимаю, энтузиастам выгоднее абсолютные цифры, нежели деленные на ватты
т.е. сейчас на своем домашнем компе вы можете решать те же задачи или даже на 2 порядка больше, что обещает субж (зависит от компа и видюх).
а с учетом того, что на компе мы можем развернуть любую удобную нам ОСь и SDK (можно поставить OpenCL SDK от Intel или AMD, чтобы OpenCL был доступен на CPU), энтузиасты еще в бОльшем плюсе.
а есть еще CUDA, DirectCompute, C++ AMP, обещают Java VM на GPU и всякие деббагеры и тулзы.
субж обещает Ubuntu, какую-нибудь C++IDE и, наверное, OpenCL… вряд ли новый ЯП изобретут.
итого:
как альтернатива большим собратам это конечно хорошо, но в итоге частнику от субжа как-то не очень.
если у них стОящие разработки, то лучше бы им их продать большим игрокам (GPU & CPU), выиграют все
Нет смысла считать флопсы GPU и CPU вместе. На GPU вы можете в один момент времени исполнять только одну программу, сколько бы ядер там не было. А этот процессор работает как полноценный CPU. То есть на нем можно вполне запустить 64 разные программы выполняющиеся параллельно. Это позволяет работать с гораздо большим количеством существующих алгоритмов.
не вижу причин, почему бы и не посчитать вместе
1) у вас может быть не одна задача, а пара связанных данными алгоритмов
2) в OpenCL 1.2 появилось: «Партицирование устройств — возможность разбиения на уровне OpenCL-приложения устройства на несколько подустройств для непосредственной привязки работ к конкретным вычислительным блокам, резервирования ресурсов для более приоритетных задач или более эффективного совместного использования аппаратных ресурсов, таких как кэш;» © википедия
3) Renderscript и C++ AMP вообще вам не скажут, где они будут решать вашу(и) задачу: на CPU и/или GPU (если только с вашими хинтами)
1) у вас может быть не одна задача, а пара связанных данными алгоритмов
2) в OpenCL 1.2 появилось: «Партицирование устройств — возможность разбиения на уровне OpenCL-приложения устройства на несколько подустройств для непосредственной привязки работ к конкретным вычислительным блокам, резервирования ресурсов для более приоритетных задач или более эффективного совместного использования аппаратных ресурсов, таких как кэш;» © википедия
3) Renderscript и C++ AMP вообще вам не скажут, где они будут решать вашу(и) задачу: на CPU и/или GPU (если только с вашими хинтами)
1) Хотелось бы увидеть пример, чтобы пара связанных данными алгоритмов выполнялась достаточно быстро на GPU, как и на CPU при одинаковом количестве GFlops. Алгоритмы будут должны выполнятся либо последовательно, либо ветвления уведут производительность в глубокий минус.
2) Это не то. Это чтобы на рядом работающих ядрах выполнять задачи, чтобы при ветвлениях не терять много времени из-за пинга. Это не даст отдать 100 ядер под 100 задач, даже под 50 задач не даст.
3) И что? Производительность то не суммируется. 100 GFlops GPU + 10 GFlops CPU не дадут при таком варианте даже близко столько же производительности на большинстве алгоритмов, как 110 GFlops CPU. Компилятор тоже вам не говорит, будут ли использоваться регистры или память, но это же не говорит, что 1 мбайт ОЗУ работает так же быстро, как и 1 мбайт кэша процессора.
2) Это не то. Это чтобы на рядом работающих ядрах выполнять задачи, чтобы при ветвлениях не терять много времени из-за пинга. Это не даст отдать 100 ядер под 100 задач, даже под 50 задач не даст.
3) И что? Производительность то не суммируется. 100 GFlops GPU + 10 GFlops CPU не дадут при таком варианте даже близко столько же производительности на большинстве алгоритмов, как 110 GFlops CPU. Компилятор тоже вам не говорит, будут ли использоваться регистры или память, но это же не говорит, что 1 мбайт ОЗУ работает так же быстро, как и 1 мбайт кэша процессора.
Определение «суперкомпьютера» представляется несколько туманными. Самый медленный суперкомпьютер в top-500 дает 61 TFLOPS.А вот эта дура (CM5/1024) — самый быстрый суперкомпьютер в 1993 году, имела производительность 131 GFlops и стоила $70 000 000 сегодняшними деньгами:
Прошло 30 лет.
20 лет… Кстати 131 — это пиковая величина, реально измеренная вроде как была всего 60.
Двадцать лет, конечно, позор Виктору Перестукину.
В статье же дается теоретическое значение для Parallella, я и привел его для CM5/1024. Немного уточню. Rpeak — это теоретическое значение, которое можно выжать из суперкомпьютера при HPL benchmark (этот тест используется для Top500), если все будет идеальным, у CM5/1024 это 131 GFlops. Rmax — это достигнутое максимальное значение при реальных условиях, это 59.7 GFlops. В Top500 оцениваются именно по Rmax.
При техническом уровне развития 1993 года можно было получить максимум 131 GFlops, но реально выжали в 2 раза меньше. Сейчас посмотрел Top500: у первого места соотношение Rpeak к Rmax 1.23, у второго — 1.07, т.е. гораздо ближе. Более точная электроника, еще какие-то нюансы, возможно, наступление эры водолея сказывается :)
Но прогресс налицо: за 20 лет от 131 GFlops в комнате до 90 GFlops в кармане. Спасибо за поправку!
В статье же дается теоретическое значение для Parallella, я и привел его для CM5/1024. Немного уточню. Rpeak — это теоретическое значение, которое можно выжать из суперкомпьютера при HPL benchmark (этот тест используется для Top500), если все будет идеальным, у CM5/1024 это 131 GFlops. Rmax — это достигнутое максимальное значение при реальных условиях, это 59.7 GFlops. В Top500 оцениваются именно по Rmax.
При техническом уровне развития 1993 года можно было получить максимум 131 GFlops, но реально выжали в 2 раза меньше. Сейчас посмотрел Top500: у первого места соотношение Rpeak к Rmax 1.23, у второго — 1.07, т.е. гораздо ближе. Более точная электроника, еще какие-то нюансы, возможно, наступление эры водолея сказывается :)
Но прогресс налицо: за 20 лет от 131 GFlops в комнате до 90 GFlops в кармане. Спасибо за поправку!
ОЗУ маловато…
А нафига оно вообще? 32-bit single-precision floating point only (no double-precision) — убивает возможность использования для CFD или научных расчётов. Как числодробилка сильно проигрывает обычным десктопным процессорам. Разве что портируют на эту платформу opencv, и использовать это дело для робоплатформ/автопилотов.
Ubuntu 11.10 — они что, издеваются?
Не фонтан конечно, но для конторы из четырех человек они и так очень много сделали.
Имхо при наличии всех спеков и документации обновить до последней версии будет не сильно сложно
Имхо при наличии всех спеков и документации обновить до последней версии будет не сильно сложно
Это говорит о том что это сборка уже у них есть и работает. Т.е. начали делать не менее года назад, что обнадеживает…
Видухам же явно проигрывают 100$ за 800 Gflops (HD 7750) Т.е. в 9 раз больше, чем они может быть когда-нибудь сделают. А когда сделают у AMD и Nvidia будет еще больше.
Проблема параллельных вычислений не в том, что мало железа. А в том, что писать эффективно сложно. А пожелать отлаживать тяжелое 16-ти поточное приложение с независимым кодом в каждом потоке можно только злым врагам.
Проблема параллельных вычислений не в том, что мало железа. А в том, что писать эффективно сложно. А пожелать отлаживать тяжелое 16-ти поточное приложение с независимым кодом в каждом потоке можно только злым врагам.
Ну это смотря как код писать — если руками для каждого потока, то да. А если у вас программа на функциональном языке (с чистыми функциями), то можно аргументы у функции считать параллельно. На эту тему уже довольно много исследований проведено.
Не получится так, что запуск 16-ти ядер и синхронизация в ожидании результатов обойдется дороже линейного решения?
Если гранулы параллелизма делать не сильно маленькие (то есть ввести порог на минимальную сложность вычисляемой функции) то вроде все работает (по крайней мере на примере Т-Системы). Но это было более 10 лет назад и подробностей я уже не помню. Если интересно, то можно начать читать отсюда
И умрет оно при доступе к памяти:)
У видух куча неудобных ограничений. Треды выполняют один код, синхронизация всех тредов разом (из-за этого получается сильный проигрыш на ветвлениях. Все треды при синхронизации будут ждать один единственный тред который заблудился в ветвлениях), стека нет, нормальных битовых операций нет, а int-ы часто эмулируются через флоаты. Видюха посути может нормально работать только с флоатами. Поэтому писать на видюху эффективно не просто сложно, а архисложно. Укладываются только специфичные задачи, и то не целиком, а только кусок который надо параллелить. Так что сравнивать «частоты и ядра» тут просто нельзя, и данный процессор если выйдет таким как его описали вышел — займет свое место на рынке.
Вспомнился комикс про 1024 ядра
А кто может просветить вкратце о том, какие задачи для такой машинки могли бы быть созданы в домашних условиях?
Лично мне сходу в голову приходит только матанализ некоего массива данных, Например, того шума, что насобирал любительский радиотелескоп. Но таких комплексов по всему миру — хорошо, если сотня.
Обычным веб-серверам, насколько я понимаю, это не поможет, пережимать видео — наверное, тоже… Тогда что можно делать с таким устройством дома?
Лично мне сходу в голову приходит только матанализ некоего массива данных, Например, того шума, что насобирал любительский радиотелескоп. Но таких комплексов по всему миру — хорошо, если сотня.
Обычным веб-серверам, насколько я понимаю, это не поможет, пережимать видео — наверное, тоже… Тогда что можно делать с таким устройством дома?
На слэшдоте писали, что есть задачи обработки сигналов от датчиков, которые стоят во всяких удаленных местах и имеют сильно ограниченное питание от солнца и батарей например.
Обработка видео/фотографий/3d. В принципе, при правильном написании и распаралеливании многие повседневные программы способны работать быстрее… И игры (под каждого бота свой отдельный поток) и операционка (десятки процессов из трэя не воюют за время одного процессора). Не говорю уж про коммерческие продукты, работающие с большими объёмами информации (поиск соответствия по биометрической базе, обработка нескольких видеокамер). Но сейчас никто так не пишет программы, так что первые пять лет после выпуска эта платформа будет пользоваться популярностью лишь в узких кругах и новых стартапах…
Ну их можно напаять на плату в большом количестве и сделать из этого PCI-карту:
Вот например они предлагают за $975:
CLUSTER: This package arrives as a ready to use cluster and includes eight Epiphany-III based parallella boards (a total of 144 CPUs), a gigabit switch, cat cables, and the power supply adapters. If we reach our $3M stretch goal, then it will be possible to choose four 64-core Epiphany-IV based boards instead of eight Epiphany-III based boards. (International order should add $40 to the pledge amount).
Вот например они предлагают за $975:
CLUSTER: This package arrives as a ready to use cluster and includes eight Epiphany-III based parallella boards (a total of 144 CPUs), a gigabit switch, cat cables, and the power supply adapters. If we reach our $3M stretch goal, then it will be possible to choose four 64-core Epiphany-IV based boards instead of eight Epiphany-III based boards. (International order should add $40 to the pledge amount).
Веб-сервер, многопользовательский движок СУБД, телефонная станция.
Насчёт веб-сервера я не уверен. Или просто не умею его готовить. Пробовал тестировать загрузку статического и динамического сайтов на восьмиядерном ксеоне.
Сайт один и тот же, но в одном случае он работал в native-режиме, когда все данные хранятся в БД MySQL и каждый вызов инициирует запрос в БД, а во втором случае — он же, но скачаный с помощью клонилки сайтов в туеву хучу html-страниц.
Движок eve-id.net (это киллборда для игры EVE-online).
Конструкция веб-сервера — nginx + memcached + apache, а так же nginx + php-fpm. В обоих случаях мускулу было выдано 6 гиг оперативки из 8, остальное — на веб-сервер.
HTML-файлы клонированного сайта и БД были сложены на SSD со скоростью чтения в 370МБ/с.
В первом случае был удивлён тем, что при 20к одновременных подключений начинает жёстко тупить мускул, нагружая только два ядра из восьми на 100%. Во втором случае nginx честно пытался загрузить шесть ядер, но не смог по причинам, понять которые я не смог в силу малого уровня знаний.
Сайт один и тот же, но в одном случае он работал в native-режиме, когда все данные хранятся в БД MySQL и каждый вызов инициирует запрос в БД, а во втором случае — он же, но скачаный с помощью клонилки сайтов в туеву хучу html-страниц.
Движок eve-id.net (это киллборда для игры EVE-online).
Конструкция веб-сервера — nginx + memcached + apache, а так же nginx + php-fpm. В обоих случаях мускулу было выдано 6 гиг оперативки из 8, остальное — на веб-сервер.
HTML-файлы клонированного сайта и БД были сложены на SSD со скоростью чтения в 370МБ/с.
В первом случае был удивлён тем, что при 20к одновременных подключений начинает жёстко тупить мускул, нагружая только два ядра из восьми на 100%. Во втором случае nginx честно пытался загрузить шесть ядер, но не смог по причинам, понять которые я не смог в силу малого уровня знаний.
Все это хорошо и радостно для 2Вт кроме вот этой строчки:
External interface 2 GB/s * 4 (four directions) = max 8 GB/s
Видеокарты сегодня очень и очень часто упираются именно в память, а там примерно в 20 раз более высокая пропускная способность. А если поставить 20 процессоров таких, то все упрется в синхронизацию данных между отдельными кусками памяти.
IMHO очень уж мало задач остается для таких железок, для массового рынка уже есть видеокарты (которые еле еле осваивают), а это как-то уж совсем специфично, хотя кто знает, может и пригодятся.
External interface 2 GB/s * 4 (four directions) = max 8 GB/s
Видеокарты сегодня очень и очень часто упираются именно в память, а там примерно в 20 раз более высокая пропускная способность. А если поставить 20 процессоров таких, то все упрется в синхронизацию данных между отдельными кусками памяти.
IMHO очень уж мало задач остается для таких железок, для массового рынка уже есть видеокарты (которые еле еле осваивают), а это как-то уж совсем специфично, хотя кто знает, может и пригодятся.
Да что ж вы все с видеокартами это сравниваете.
Видеокарты — тупые числодробилки.
Не сделаешь на них нормального ветвления, не поработаешь с большими блоками данных как единым целым.
Кесарю — кесарево.
Видеокарты — тупые числодробилки.
Не сделаешь на них нормального ветвления, не поработаешь с большими блоками данных как единым целым.
Кесарю — кесарево.
Ну если уж на то пошло, то на GTX 580 16 вполне себе независимых ядер, которые могут радостно ветвиться, ровно столько же, сколько и тут.
Про работу с большими блоками данных не понял. 6Гб на карту вполне себе приличный блок данных, если вы про что-то большее, то у меня большие сомнения по поводу того, что представленный чип сможет получить доступ к гораздо большему блоку.
Про кесарю-кесарево — это правда, хотя как появится больше софта поддерживающего, станет радостней. Просто видеокарты уже есть везде, а вот эти штуки надо покупать под конкретную задачу и вот этих задач в больших количествах я не вижу.
Про работу с большими блоками данных не понял. 6Гб на карту вполне себе приличный блок данных, если вы про что-то большее, то у меня большие сомнения по поводу того, что представленный чип сможет получить доступ к гораздо большему блоку.
Про кесарю-кесарево — это правда, хотя как появится больше софта поддерживающего, станет радостней. Просто видеокарты уже есть везде, а вот эти штуки надо покупать под конкретную задачу и вот этих задач в больших количествах я не вижу.
Прекрасно себе вижу сервер обработки веб-скриптов.
Сервер обработки любых разнообразных запросов выходящих за рамки считал блок озу, сложил, поделил, умножил, записал.
И потреблять это все будет минимум электроэнергии и охлаждать его не нужно будет турбиной от боинга.
Сервер обработки любых разнообразных запросов выходящих за рамки считал блок озу, сложил, поделил, умножил, записал.
И потреблять это все будет минимум электроэнергии и охлаждать его не нужно будет турбиной от боинга.
Лично я не верю, что у них получится предоставить разумную производительность даже с сотнями ядер (особенно в этом случае) просто потому, что бюджет транзисторов у них ограничен и раз уж они сумели запихнуть в него столько ядер, значит они чем-то пожертвовали и как-раз из-за этого он будет работать быстро (т.е. вместо умного контроллера памяти поставили глупый, вместо кэша, еще одно ядро, вместо предсказания ветвлений продвинутого, еще ядро поставили. Чудес не бывает, любая архитектура — компромис и чем менее продвинутая она, тем сложнее писать под нее эффективный код, а с серверным кодом под arm и так все тяжко.
Да и не на тот рынок они целятся судя по описанию.
Да и не на тот рынок они целятся судя по описанию.
Серверный код под ARM как раз бегает лучше любого другого.
Там где не надо считать ARM более чем хорош.
В любом случае строковые данные видеокарта мне не обработает, выборку по базе не сделает и т.д.
На этот рынок есть кому целится, Dell уже интеграторам готовые сервера раздает на ARM.
Жду когда попадет на тест.
И еще раз на счет энергопотребления:
Думаю не сложно посчитать сколько можно сэкономить на электроэнергии выбросив GTX580.
Там где не надо считать ARM более чем хорош.
В любом случае строковые данные видеокарта мне не обработает, выборку по базе не сделает и т.д.
На этот рынок есть кому целится, Dell уже интеграторам готовые сервера раздает на ARM.
Жду когда попадет на тест.
И еще раз на счет энергопотребления:
Думаю не сложно посчитать сколько можно сэкономить на электроэнергии выбросив GTX580.
Ну тут с выборкой по базе то-же будут определённые проблемы, однако.
Лично мне будет интересно с ними столкнуться на личном опыте, и 99$ за это не разу не жалко!
Лично мне будет интересно с ними столкнуться на личном опыте, и 99$ за это не разу не жалко!
Так я и не предлагаю скрипты на GTX580 крутить, тут без вопросов. Я про то, что десятки ядер в одном чипе (как описано в статье) вряд ли будут иметь смысл. А вот ARM с 2-8 ядер вполне может. Просто они целятся как раз на потребительский рынок (и цена соответствующая), а там уже все занято видеокартами кроме совсем специфических ниш. Вот и вопрос, для чего они нужны на потребительском рынке? Для каких задач?
А на счет того, что серверный код бегает быстрее на арме, можно ссылку на тесты (просто я когда последний раз читал, по производительности чистой армы проигрывали, так что интересно) и на количество серверных приложений, которые уже есть под армы vs x86.
А на счет того, что серверный код бегает быстрее на арме, можно ссылку на тесты (просто я когда последний раз читал, по производительности чистой армы проигрывали, так что интересно) и на количество серверных приложений, которые уже есть под армы vs x86.
Для всего где не нужно выполнять только простые математические операции.
ARM-ы проигрывают в расчетах, но публичных тестов чего-то кроме «вычисли мне число Pi», со сравнением эффективности на потребленный ватт я не видел.
Серверные приложения никто не запрещает компилировать из исходников, в основном без изменений, что под ARM делается элементарно, в отличие от видеокарт.
ARM-ы проигрывают в расчетах, но публичных тестов чего-то кроме «вычисли мне число Pi», со сравнением эффективности на потребленный ватт я не видел.
Серверные приложения никто не запрещает компилировать из исходников, в основном без изменений, что под ARM делается элементарно, в отличие от видеокарт.
В этом интел как раз будет сильна, так как архитектура сложнее и «умнее», а у армов с этим не так радостно. На счет простой перекомпиляции, есть у меня сомнения на тему эффективности этого процесса без оптимизации.
Но, даже если предположить серверное применение, 64 ядра — это слишком много. Чтобы данные обрабатывать, их надо получить, и вот тут то оно и загнется. Я не против ARM, я лишь не верю в том, что у них получится соединить 64 ядра эффективно, у Интела не сильно получается, а там гораздо больше денег идет на разработку.
Ну а для не-серверного применения я не вижу задач, для которых оно будет выгодно кроме как поиграться.
Но, даже если предположить серверное применение, 64 ядра — это слишком много. Чтобы данные обрабатывать, их надо получить, и вот тут то оно и загнется. Я не против ARM, я лишь не верю в том, что у них получится соединить 64 ядра эффективно, у Интела не сильно получается, а там гораздо больше денег идет на разработку.
Ну а для не-серверного применения я не вижу задач, для которых оно будет выгодно кроме как поиграться.
Архитектура там содержит программный код(микрокод), который разбивает инструкции на своего рода аналог ARM-овских.
Оптимизация кода по инструкции полноценных процессоров это давно больше удел компиляторов.
С чем они прекрасно справляются.
Intel конечно молодцы, но с энергопотреблением у них плохо, не смотря на супермегапередовой техпроцесс.
И деньги в это вбухивают не от хорошей жизни.
Оптимизация кода по инструкции полноценных процессоров это давно больше удел компиляторов.
С чем они прекрасно справляются.
Intel конечно молодцы, но с энергопотреблением у них плохо, не смотря на супермегапередовой техпроцесс.
И деньги в это вбухивают не от хорошей жизни.
Хотелось бы, чтобы это (хорошая оптимизация компиляторами) было правдой:). Прогресс конечно есть, но им еще расти и расти:)
Ну да ладно, спорить смысла нет, каждый останется при своем мнении, а время нас рассудит. Если у меня появится очередная игрушка с 64 ядрами за 200 долларов, то я буду доволен, если не появится, буду мучать GTX580ые дальше:)
Ну да ладно, спорить смысла нет, каждый останется при своем мнении, а время нас рассудит. Если у меня появится очередная игрушка с 64 ядрами за 200 долларов, то я буду доволен, если не появится, буду мучать GTX580ые дальше:)
Всё упирается в задачи, и возможности для их решения.
Видеокарты упираются в шину и память во многом благодаря серьёзным проблемам с реализацией программной логики, делающим само использование GPU не тривиальной задачей.
Здесь же нам предлагаются RISC ядра способные не только вычислять но и обрабатывать данные!
Необходимость гонять большие объёмы данных между вычислителем и обработчиком отпадает.
Из задач, первое что приходит в голову это работа с блоками в биткоин :-) И хотя по меркам нынешней сложности, сферического быстродействия в вакууме за 99$ явно маловато, но это в теории, а на практике задача хорошо разбивается на диапазоны, в которых будут чесать ядра.
Сюда же можно отнести, множество других криптографических и аналитических задач, где исходных данных в разы больше чем выходных.
Видеокарты упираются в шину и память во многом благодаря серьёзным проблемам с реализацией программной логики, делающим само использование GPU не тривиальной задачей.
Здесь же нам предлагаются RISC ядра способные не только вычислять но и обрабатывать данные!
Необходимость гонять большие объёмы данных между вычислителем и обработчиком отпадает.
Из задач, первое что приходит в голову это работа с блоками в биткоин :-) И хотя по меркам нынешней сложности, сферического быстродействия в вакууме за 99$ явно маловато, но это в теории, а на практике задача хорошо разбивается на диапазоны, в которых будут чесать ядра.
Сюда же можно отнести, множество других криптографических и аналитических задач, где исходных данных в разы больше чем выходных.
Так тут они в память точно также упрутся, я как раз чуть выше писал об этом. 8Гб/с — это мало. Да и взаимодействие между ядрами тоже. Интел со своими 8 ядрами уже подошла к тому пределу, кодга дальнейший рост числа ядер не эффективен именно из-за их взаимодействия между собой и внешним миром. А для криптографии уже есть вполне себе железная реализация в современных процессорах.
Вот и для чего оно еще надо? (ну кроме как игрушка)
Вот и для чего оно еще надо? (ну кроме как игрушка)
Если так рассуждать, то Интелу пора сворачивать производства и подсчитывать убытки. )))
Ну если так смотреть, то они именно этим и занимаются:)
Десктопы исчезают, ноутбуки вытесняются планшетами. Производительность процессоров растет все медленнее и медленнее. Phi получился не очень. Больше 4-6 ядер на процессоре (не серверных) не появляется уже несколько лет.
Десктопы исчезают, ноутбуки вытесняются планшетами. Производительность процессоров растет все медленнее и медленнее. Phi получился не очень. Больше 4-6 ядер на процессоре (не серверных) не появляется уже несколько лет.
На (не серверных) больше и не надо.
На серверных с каждым годом растет, потому что рынок требует.
И в статье описывается железо не для задачек по математике и работе с офисными документами…
На серверных с каждым годом растет, потому что рынок требует.
И в статье описывается железо не для задачек по математике и работе с офисными документами…
Так на серверных 8 есть, вроде больше не было, что всего на 2 ядра больше, чем на десктопах, так что не далеко они ушли.
На не серверных было бы хорошо частоты повышать, а не могут. Уже лет 5 выше 4ггц никто не прыгнул. Архитектуру улучшают, кэш добавляют, тут спору нет, транзисторов ставят больше, но скорость уже сильно не растет. Мне лень искать ссылки, но если попадется статистика производительности в разных задачах, все очень и очень плохо в плане ежегодного роста. Я когда-то считал для дисер, получалось что-то вроде 10% в год скорость каждого ядра и 20% в год в среднем за 5 лет за счет роста числа ядер. Т.е. процессоры, которые будут в 10 раз быстрее существующих мы в ближайшие 10 лет не получим.
Честно говоря, я не совсем понимаю целевой рынок описанного железа.
На не серверных было бы хорошо частоты повышать, а не могут. Уже лет 5 выше 4ггц никто не прыгнул. Архитектуру улучшают, кэш добавляют, тут спору нет, транзисторов ставят больше, но скорость уже сильно не растет. Мне лень искать ссылки, но если попадется статистика производительности в разных задачах, все очень и очень плохо в плане ежегодного роста. Я когда-то считал для дисер, получалось что-то вроде 10% в год скорость каждого ядра и 20% в год в среднем за 5 лет за счет роста числа ядер. Т.е. процессоры, которые будут в 10 раз быстрее существующих мы в ближайшие 10 лет не получим.
Честно говоря, я не совсем понимаю целевой рынок описанного железа.
У меня в серверах по 16 ядер на камень прекрасно крутятся AMD-шки.
Частоты на серверных как раз повышать не так и нужно.
Видимо вы слабо представляете задачи для 90% серверов.
Кстати в Xeon-ах сейчас кеша на ядро столько же сколько было в 54xx серии.
А транзисторов больше для того чтобы выполнять высокоуровневые команды за меньшее число тактов.
Частоты на серверных как раз повышать не так и нужно.
Видимо вы слабо представляете задачи для 90% серверов.
Кстати в Xeon-ах сейчас кеша на ядро столько же сколько было в 54xx серии.
А транзисторов больше для того чтобы выполнять высокоуровневые команды за меньшее число тактов.
А на счет описанного, да хоть контролировать датчики ядерного реактора в реальном времени.
Задача более чем подходящая.
Любые задачи, в которых не нужно много считать, то нужно много одновременных малопотребляющих потоков.
Задача более чем подходящая.
Любые задачи, в которых не нужно много считать, то нужно много одновременных малопотребляющих потоков.
16 AMD ядер — это которые 8 двойных ядер? Тут можно долго и нудно спорить, но это отдельная история.
Про частоты я говорил для десктопов («На не серверных»), там как раз надо.
Про частоты я говорил для десктопов («На не серверных»), там как раз надо.
16 это те которые 16 ядер.
www.amd.com/us/products/server/processors/6000-series-platform/6200/Pages/6200-series-processors.aspx
Это предыдущее поколение, дальше будет больше.
Для десктопов кластер даже и за 99$ не нужен.
Банально не те задачи.
www.amd.com/us/products/server/processors/6000-series-platform/6200/Pages/6200-series-processors.aspx
Это предыдущее поколение, дальше будет больше.
Для десктопов кластер даже и за 99$ не нужен.
Банально не те задачи.
Это сейчас он банально ненужен. Точно так же как ненужна когда то была оперативка больше 640К. Будут возможности — будут писать софт. А сейчас софта нет, и возможности ненужны.
Возможности есть, хоть и не много.
Одно дело когда софта почти нет, потому что мало возможностей, а другое когда его вообще нет, потому что не нужен.
А его нет вообще…
Одно дело когда софта почти нет, потому что мало возможностей, а другое когда его вообще нет, потому что не нужен.
А его нет вообще…
Он есть, но его критически мало. Мало, потому те человекочасы, которые придется вложить в разработку многопоточного кода не соответствуют профиту (из-за этих скромных возможностей), вот и параллелят только самое важное, что дает ощутимый прирост.
Приведите пример софта для дома, который рассчитан на выполнение в кластере.
Если считать полезную нагрузку на все ядра одновременно и длительное время — то видео кодеки, архиваторы.
А в перспективе наличия сотни-двух ядер — будет глобальная переработка уже существующих API, форматов, протоколов.
Например обработка WM_PAINT, она для всех элементов управления сейчас выполняется в 99% в основном треде. А ведь можно каждому окну выдавать свой тред для обработки именно WM_PAINT.
Чтение документов pdf/doc и прочее. Форматы заточены под последовательное чтение. Даже тот же самый HTML хрен распараллелишь, а ведь построение из HTML полной DOM структуры и её рендер — это дикая нагрузка на одно ядро.
А в перспективе наличия сотни-двух ядер — будет глобальная переработка уже существующих API, форматов, протоколов.
Например обработка WM_PAINT, она для всех элементов управления сейчас выполняется в 99% в основном треде. А ведь можно каждому окну выдавать свой тред для обработки именно WM_PAINT.
Чтение документов pdf/doc и прочее. Форматы заточены под последовательное чтение. Даже тот же самый HTML хрен распараллелишь, а ведь построение из HTML полной DOM структуры и её рендер — это дикая нагрузка на одно ядро.
Для архиваторов и видео больше подходят спец инструкции в процессорах, т.к. распараллеливание тех же архиваторов требует экспоненциального роста буфера обработки, что дает нагрузку на шину и требует больше ОЗУ.
С видео понятно, видеокарты справятся с этим лучше.
WM-PAINT можно раскидать по ядрам, никто не мешает, только загружать для этого данные в кластер и ждать обработки — глупость.
DOM сильно ветвится и легко паралеллится, но опять таки имеет смысл грузит в кластер разве что очень сложные страницы, чтобы профит превышал время на IO с кластером.
С видео понятно, видеокарты справятся с этим лучше.
WM-PAINT можно раскидать по ядрам, никто не мешает, только загружать для этого данные в кластер и ждать обработки — глупость.
DOM сильно ветвится и легко паралеллится, но опять таки имеет смысл грузит в кластер разве что очень сложные страницы, чтобы профит превышал время на IO с кластером.
Про кодеки и архиваторы я привел пример — как существующего софта, который может на полную катушку использовать все 4-6 ядер, и дает заметный прирост в производительности. Да, текущие алгоритмы плохо лягут на 100-200 ядерные процессоры.
WM_PAINT раскидать по ядрам никто не мешает, просто этот «траходром» никому не нужен, т.к. на данный момент ядра всего 4-6, и профиту с этого чуть (отрисовка ускорится скажем с 1мсек до 0.25-0.4мсек), а сложные места, где много текста, различные динамические эффекты + простыни с километровым скроллингом — лучше перевести на гпу, как и делают сейчас браузеры. А если подобное улучшение производительности (пусть даже треть эффективности от ГПУ) будет доступно прямо из коробки для любого пользователя — это же замечательно.
DOM сильно ветвится, и легко параллелится? Дальнейшая работа с DOM может быть и да, но как вы представляете параллельный парсинг HTML в DOM?
WM_PAINT раскидать по ядрам никто не мешает, просто этот «траходром» никому не нужен, т.к. на данный момент ядра всего 4-6, и профиту с этого чуть (отрисовка ускорится скажем с 1мсек до 0.25-0.4мсек), а сложные места, где много текста, различные динамические эффекты + простыни с километровым скроллингом — лучше перевести на гпу, как и делают сейчас браузеры. А если подобное улучшение производительности (пусть даже треть эффективности от ГПУ) будет доступно прямо из коробки для любого пользователя — это же замечательно.
DOM сильно ветвится, и легко параллелится? Дальнейшая работа с DOM может быть и да, но как вы представляете параллельный парсинг HTML в DOM?
Я прекрасно представляю параллельный парсинг в DOM.
Параллельный рендеринг конечно маловероятен.
Но вы не ответили на вопрос:
Приведите пример софта для дома, который рассчитан на выполнение в кластере.
Не тот который рассчитан на выполнении в одном многоядерном процессоре на самом компьютере, а в кластере.
Параллельный рендеринг конечно маловероятен.
Но вы не ответили на вопрос:
Приведите пример софта для дома, который рассчитан на выполнение в кластере.
Не тот который рассчитан на выполнении в одном многоядерном процессоре на самом компьютере, а в кластере.
>> Я прекрасно представляю параллельный парсинг в DOM.
А я нет. Разработчики браузеров видимо тоже, раз при загрузке страницы валят одно ядро. Может поделитесь с разработчиками браузеров, или хотябы с нами, с народом (например статьей на хабре).
>> Приведите пример софта для дома, который рассчитан на выполнение в кластере.
>> Не тот который рассчитан на выполнении в одном многоядерном процессоре на самом компьютере, а в кластере.
Давайте проследим цепочку нашей беседы:
Тут я говорю что процессор будет востребован
На что вы говорите что софта нет, т.к. это никому ненужно
Я сказал его нет, потому что профит от переписывания на N потоков слишком низкий
На что вы просите пример софта заточенного под кластеры.
А сейчас вы уточняете, что софт должен быть заточен именно под кластер:
>> Не тот который рассчитан на выполнении в одном многоядерном процессоре на самом компьютере, а в кластере.
Вы не понимаете почему нет именно такого софта? Какой смысл затачивать софт под кластеры, который будет исполнятся на домашнем ПК с одним процессором в 4 ядра?
Это прямо противоречит тому что вы говорите тут:
>> Возможности есть, хоть и не много.
>> Одно дело когда софта почти нет, потому что мало возможностей, а другое когда его вообще нет, потому что не нужен.
>> А его нет вообще…
Значит у нас нет возможности, ибо один 4-х ядерный процессор != этой возможности:
>> Не тот который рассчитан на выполнении в одном многоядерном процессоре на самом компьютере, а в кластере.
А я нет. Разработчики браузеров видимо тоже, раз при загрузке страницы валят одно ядро. Может поделитесь с разработчиками браузеров, или хотябы с нами, с народом (например статьей на хабре).
>> Приведите пример софта для дома, который рассчитан на выполнение в кластере.
>> Не тот который рассчитан на выполнении в одном многоядерном процессоре на самом компьютере, а в кластере.
Давайте проследим цепочку нашей беседы:
Тут я говорю что процессор будет востребован
На что вы говорите что софта нет, т.к. это никому ненужно
Я сказал его нет, потому что профит от переписывания на N потоков слишком низкий
На что вы просите пример софта заточенного под кластеры.
А сейчас вы уточняете, что софт должен быть заточен именно под кластер:
>> Не тот который рассчитан на выполнении в одном многоядерном процессоре на самом компьютере, а в кластере.
Вы не понимаете почему нет именно такого софта? Какой смысл затачивать софт под кластеры, который будет исполнятся на домашнем ПК с одним процессором в 4 ядра?
Это прямо противоречит тому что вы говорите тут:
>> Возможности есть, хоть и не много.
>> Одно дело когда софта почти нет, потому что мало возможностей, а другое когда его вообще нет, потому что не нужен.
>> А его нет вообще…
Значит у нас нет возможности, ибо один 4-х ядерный процессор != этой возможности:
>> Не тот который рассчитан на выполнении в одном многоядерном процессоре на самом компьютере, а в кластере.
Поясню вопрос на пальцах:
Вычислительный кластер это отдельная единица оборудования, в которую на обработку подаются задания.
Интерфейс для загрузки и выгрузки заданий далеко не самый быстрый.
Т.е. накладные расходы на выгрузку и загрузку данных, на латентность линка и т.д. должны быть меньше чем ускорение обработки на кластере.
Т.е. чтобы был от этого хоть какой-то выигрыш.
Если же вы готовите задание для кластера 0.5 секунды, грузите блок данных в кластер 1 секунду, потом он обрабатывается 1мс в кластере и потом отдаете его 1 секунду, то быстрее обработать за 1 секунду этот блок на самом компьютере.
Подумайте какой объем данных должен быть у архиватора чтобы превысить издержки на передачу данных, скорее мизерный чем большой.
А с мизерным прекрасно справится сам компьютер.
Вычислительный кластер это отдельная единица оборудования, в которую на обработку подаются задания.
Интерфейс для загрузки и выгрузки заданий далеко не самый быстрый.
Т.е. накладные расходы на выгрузку и загрузку данных, на латентность линка и т.д. должны быть меньше чем ускорение обработки на кластере.
Т.е. чтобы был от этого хоть какой-то выигрыш.
Если же вы готовите задание для кластера 0.5 секунды, грузите блок данных в кластер 1 секунду, потом он обрабатывается 1мс в кластере и потом отдаете его 1 секунду, то быстрее обработать за 1 секунду этот блок на самом компьютере.
Подумайте какой объем данных должен быть у архиватора чтобы превысить издержки на передачу данных, скорее мизерный чем большой.
А с мизерным прекрасно справится сам компьютер.
Вышеупомянутый процессор на RISC архитектуре, это значит что он посути ничем не отличается от текущих 4-х ядерных. Грубо говоря его можно считать одним многоядерным процессором, а не кластером. Напомню, выше вы писали:
>> Не тот который рассчитан на выполнении в одном многоядерном процессоре на самом компьютере, а в кластере.
А это именно такой процессор, и сейчас мы говорим о целесообразности его на рынке, а не о каком-то абстрактном кластере.
>> Не тот который рассчитан на выполнении в одном многоядерном процессоре на самом компьютере, а в кластере.
А это именно такой процессор, и сейчас мы говорим о целесообразности его на рынке, а не о каком-то абстрактном кластере.
Можете считать обычным 4-хядерных, хотя не понятно откуда такие выводы.
Но учитывайте скорость и латентность линков к нему.
И так же помните что это отдельное устройство, которому нужно объяснить что делать, отдать данные и дождаться результата, а не просто взять и обработать данные на нем как это можно сделать на ЦП.
Но учитывайте скорость и латентность линков к нему.
И так же помните что это отдельное устройство, которому нужно объяснить что делать, отдать данные и дождаться результата, а не просто взять и обработать данные на нем как это можно сделать на ЦП.
>> Можете считать обычным 4-хядерных, хотя не понятно откуда такие выводы.
Из-за архитектуры RISC. Если на данном этапе он и будет выступать в роли сопроцессора — то это только временные технические трудности (из-за большой базы уже написанного софта), и в будущем я думаю они либо допилят эмуляцию CISC, либо софт начнет потихоньку перебираться на RISC (и давно бы пора). У этого процессора есть свой стек, на шине будет своя память, код может находится в ней неограниченно долго, и крутить там потоки, хранить там данные и там же обрабатывать. Т.е. это проблема только софта.
Из-за архитектуры RISC. Если на данном этапе он и будет выступать в роли сопроцессора — то это только временные технические трудности (из-за большой базы уже написанного софта), и в будущем я думаю они либо допилят эмуляцию CISC, либо софт начнет потихоньку перебираться на RISC (и давно бы пора). У этого процессора есть свой стек, на шине будет своя память, код может находится в ней неограниченно долго, и крутить там потоки, хранить там данные и там же обрабатывать. Т.е. это проблема только софта.
Архитектура RISC подразумевает простые инструкции и отсутствие микрокода.
С какого перепугу сетевой кластер станет вдруг процессором все же не понятно.
Под RISC софт прекрасно перекомпилируется без особых изменений.
У каждого процессора здесь есть своя шина, а дальше это интерконнект.
И я повторю еще раз учитывайте скорость того что вы называете шиной.
Здесь это всего 8Гбит/сек, в Intel QPI 204,8 Гбит/сек.
Хреновый процессор получается, но неплохой кластер.
С какого перепугу сетевой кластер станет вдруг процессором все же не понятно.
Под RISC софт прекрасно перекомпилируется без особых изменений.
У каждого процессора здесь есть своя шина, а дальше это интерконнект.
И я повторю еще раз учитывайте скорость того что вы называете шиной.
Здесь это всего 8Гбит/сек, в Intel QPI 204,8 Гбит/сек.
Хреновый процессор получается, но неплохой кластер.
10-ядерные Xeon E7 вышли весной 2011 года.
Отсчитываем 5 (не 10) лет назад — попадаем в Xeon серии 5000. Два ядра (Pentium-4, даже не Core2), правда частоты повыше раза в полтора.
За эти пять лет: стало в 5 раз больше ядер и стало в ~4 раза больше флопсов на такт (У westmere 2 SSE операции на такт, а P4 одно SSE-сложение или умножение делал за два такта). Делим на полтора (тактовая), получаем что серверные CPU за 5 лет ускорились в ~12 раз на массовых операциях.
Если мотать вперед от E7 (к 16-му году) — то предсказывать конечно сложно, но 4x по флопсам на такт предсказать можно уже сейчас (т.к. AVX удлинил вектор вдвое, а FMA — удвоило флопсы одной операции). Но скорее всего к 16-му году будет уже 512-битный AVX (как он уже есть в Xeon Phi)
Отсчитываем 5 (не 10) лет назад — попадаем в Xeon серии 5000. Два ядра (Pentium-4, даже не Core2), правда частоты повыше раза в полтора.
За эти пять лет: стало в 5 раз больше ядер и стало в ~4 раза больше флопсов на такт (У westmere 2 SSE операции на такт, а P4 одно SSE-сложение или умножение делал за два такта). Делим на полтора (тактовая), получаем что серверные CPU за 5 лет ускорились в ~12 раз на массовых операциях.
Если мотать вперед от E7 (к 16-му году) — то предсказывать конечно сложно, но 4x по флопсам на такт предсказать можно уже сейчас (т.к. AVX удлинил вектор вдвое, а FMA — удвоило флопсы одной операции). Но скорее всего к 16-му году будет уже 512-битный AVX (как он уже есть в Xeon Phi)
Ну так если учитывать SSE/AVX, то лучше уж податься в сторону видеокарт, это их путь, там идея похожая, а производительность на пару порядков выше теоретическая. А вот если без SSE, тогда мы ваши 12 раз делим на 4 и получаем ~1.5 раз о которых я и говорил.
Видеокарты имеют смысл, если количество операций на элемент — большое. Потому что у них горлышко (PCIe) узкое, пересылать два вектора на видеокарту чтобы их там сложить — нет смысла.
Но таки да — хотите эффективно использовать CPU — используйте SSE/AVX. Благо, кроме векторных сложений-умножений-итп, туда постепенно много всего интересного суют (strcmp, crc32, aes, dot product и так далее).
Но таки да — хотите эффективно использовать CPU — используйте SSE/AVX. Благо, кроме векторных сложений-умножений-итп, туда постепенно много всего интересного суют (strcmp, crc32, aes, dot product и так далее).
Горлышко PCIe не узкое. Латентность большая. Если подготовить данные заранее, и залить их одним блоком — то будет все очень даже быстро. А если лить кучу данных по одному вектору — то понятное дело…
Я когда фонтаны на частицах делал пришел к выводу что заливка данных вообще неощутима. У меня там мегабайты данных по 30-50 раз в секунду ездили, и профилирование показало что почти не влияет узость PCIe.
Я когда фонтаны на частицах делал пришел к выводу что заливка данных вообще неощутима. У меня там мегабайты данных по 30-50 раз в секунду ездили, и профилирование показало что почти не влияет узость PCIe.
Ну как не узкое? ~6Gb/sec на практике. Ну может сейчас уже 8.
А два вектора можно складывать со скоростью памяти. На socket 2011 — около 50Gb/sec.
А два вектора можно складывать со скоростью памяти. На socket 2011 — около 50Gb/sec.
Побольше 6 явно
На практике латентность сильнее мешает.
На практике латентность сильнее мешает.
Реальные карты упираются в собственные ограничения, а не в пропускную способность шины.
Реально я видел чуть меньше 6Gb/sec на PCIe2 (x16) на AMD6990 и чуть больше 5 на GTX480. Все — PCIe2.
На новом поколении карт/шины намеривают больше, но смысл от этого не меняется. Для задач низкой арифметической интенсивности (вроде сложения векторов), прочитать из памяти — сложить — записать в память *всегда* будет эффективнее чем «прочитать из памяти в PCIe — что-то поделать на внешнем устройстве — прочитать из PCIe в память».
Смысл в таких упражнениях все равно может быть, но не ради скорости, а ради offload: читаем туда-сюда через DMA, CPU свободен, может показывать скринсейвер.
Реально я видел чуть меньше 6Gb/sec на PCIe2 (x16) на AMD6990 и чуть больше 5 на GTX480. Все — PCIe2.
На новом поколении карт/шины намеривают больше, но смысл от этого не меняется. Для задач низкой арифметической интенсивности (вроде сложения векторов), прочитать из памяти — сложить — записать в память *всегда* будет эффективнее чем «прочитать из памяти в PCIe — что-то поделать на внешнем устройстве — прочитать из PCIe в память».
Смысл в таких упражнениях все равно может быть, но не ради скорости, а ради offload: читаем туда-сюда через DMA, CPU свободен, может показывать скринсейвер.
>> Реально я видел чуть меньше 6Gb/sec
А я пришел к выводу, что для GPGPU оно под микроскопом там не разобрать. Скорость шины играет роль, если заливаются очень большие блоки памяти. Например во всяких крузисах текстуры. Такие большие блоки заливаются в первую очередь потому, что от текстуры может быть видно 10 пикселей, а заливается она один фиг вся, т.к. заранее не определишь, какой кусок текстуры будет виден.
Для общих же вычислений такими вагонами данных как правило не оперируют, хотя это не исключает возможность упереться в шину.
>> может показывать скринсейвер.
Который выводится через ГПУ. lol
В общем то да, операцию сложения нет смысла делать на GPU, а вот штук 5 операций сложения, или парочка операций умножения для 100500 векторов — уже могут оправдать расходы.
А я пришел к выводу, что для GPGPU оно под микроскопом там не разобрать. Скорость шины играет роль, если заливаются очень большие блоки памяти. Например во всяких крузисах текстуры. Такие большие блоки заливаются в первую очередь потому, что от текстуры может быть видно 10 пикселей, а заливается она один фиг вся, т.к. заранее не определишь, какой кусок текстуры будет виден.
Для общих же вычислений такими вагонами данных как правило не оперируют, хотя это не исключает возможность упереться в шину.
>> может показывать скринсейвер.
Который выводится через ГПУ. lol
В общем то да, операцию сложения нет смысла делать на GPU, а вот штук 5 операций сложения, или парочка операций умножения для 100500 векторов — уже могут оправдать расходы.
В вычислениях памяти регулярно не хватает.
Оттого во всякие теслы ставят больше памяти, чем в игровые карты.
Оттого во всякие теслы ставят больше памяти, чем в игровые карты.
Я вам даже больше скажу. Памяти всегда будет не хватать (не только в tesla), и всегда будут ставить больше памяти. Текущая же пропускная способность (тут я говорю только про десктопы) PCIe уже догнала работу с оперативной памятью, и передать большой кусок памяти в GPU на десктопе по времени по сути тоже самое что сделать memcpy этого куска в оперативке. Так что как только возникает ситуация, когда данных много, и распараллеливание на GPU даст профит больший, чем 2 дополнительных копирования этого куска памяти — то есть смысл задуматься о том чтобы поехать на GPU.
Где догнала?
PCIe3 текущий — 16Gb/sec по спекам, 11Gb/sec намеривают на реальных картах.
Память: 24-27Gb/sec на двухканальном 1155, под 50Gb/sec — на 4-канальном 2011.
PCIe3 текущий — 16Gb/sec по спекам, 11Gb/sec намеривают на реальных картах.
Память: 24-27Gb/sec на двухканальном 1155, под 50Gb/sec — на 4-канальном 2011.
Смотрю в вики. Вижу 19200 МБ/с на DDR3-2400. Лгут?
> Пиковая скорость передачи данных при 64-битной адресации в одноканальном режиме
Угу, не заметил, но сути не меняет.
Умножаем на 2, получаем 38400 (это топовая память в дуале), смотрим PCIe 3.0x16, 128/256. В одну сторону 128 = 16Гб/с, а в 2 стороны 32Гб/с.
На практике же зачастую без микроскопа не разобраться в разнице скоростей.
~2Gb/sec… до заявленных 10667 * 2 (в дуале) как пешком до пентагона :(
Умножаем на 2, получаем 38400 (это топовая память в дуале), смотрим PCIe 3.0x16, 128/256. В одну сторону 128 = 16Гб/с, а в 2 стороны 32Гб/с.
На практике же зачастую без микроскопа не разобраться в разнице скоростей.
Замерил скорость записи для своей памяти из под винды
{$APPTYPE CONSOLE}
uses
Windows;
procedure DoTest;
const MEMORY_SIZE = 1024 * 1024 * 1024; // 1GB
var start_cnt: Int64;
end_cnt : Int64;
freq : Int64;
memory : Pointer;
elapsed : Double;
begin
GetMem(memory, MEMORY_SIZE);
try
QueryPerformanceFrequency(freq);
QueryPerformanceCounter(start_cnt);
FillChar(memory^, MEMORY_SIZE, $FF);
QueryPerformanceCounter(end_cnt);
elapsed := (end_cnt - start_cnt) / freq * 1000;
WriteLn('msec elapsed: ', Trunc(elapsed));
WriteLn('speed: ', 1000/elapsed:3:3, ' Gb/sec');
finally
FreeMem(memory);
end;
end;
begin
SetThreadAffinityMask(GetCurrentThreadId, 1);
DoTest;
ReadLn;
end.
~2Gb/sec… до заявленных 10667 * 2 (в дуале) как пешком до пентагона :(
У меня в тестах на двух каналах DDR-1800 получалось 22761Mb/sec: blog.lexa.ru/2011/09/08/opyat_pro_movntps.html
Примерно столько же получается тестированием AIDA64, потому я этой бенчмарке доверяю.
Что вдвое больше реальной скорости вылива данных в GTX680.
Примерно столько же получается тестированием AIDA64, потому я этой бенчмарке доверяю.
Что вдвое больше реальной скорости вылива данных в GTX680.
На аиде вышло 6.3ГБ/с, но собственно заявленных 20 нет и в помине :(
p.s. Глянул свой асм, копирование там вот так:
0040331A fst qword ptr [edx+eax]
0040331D fst qword ptr [edx+eax+$08]
00403321 add edx,$10
00403324 jl $0040331a
Неужто из-за того что копируется по 64 бита за раз (вместо 128 с movntps. movaps) скорость падает в 3 раза о_О
p.s. Глянул свой асм, копирование там вот так:
0040331A fst qword ptr [edx+eax]
0040331D fst qword ptr [edx+eax+$08]
00403321 add edx,$10
00403324 jl $0040331a
Неужто из-за того что копируется по 64 бита за раз (вместо 128 с movntps. movaps) скорость падает в 3 раза о_О
Кстати, а что ты там такого интересного разрабатываешь?
Я почитал комментарии, и теперь мне интересно стало :) Какой-то софтварный рендер? Или просто мат. библиотека?
Я почитал комментарии, и теперь мне интересно стало :) Какой-то софтварный рендер? Или просто мат. библиотека?
Всякий странный софт для цифровых фотографов. www.libraw.su/ и www.rawdigger.ru/ из видимого публично.
Ну так каналов то больше одного.
В десктопных процессорах — два, в сокете 2011 — четыре.
В десктопных процессорах — два, в сокете 2011 — четыре.
Больше OLAPов, дешевых и быстрых =)
Похоже, на хабре конкретный кризис видения будущего. В эпоху нового этапа закона Мура, неотвратимого параллелизма, да что там — нового технологического уклада, BigData, интернета вещей и НБИК пользователи ведущего ИТ-ресурса искренне удивляются, для чего вообще могут быть нужны терафлопсы в каждом доме?
Речь не о текущих недостатках конкретного железа — первый Apple тоже был убогим, но Стив и Стив изначально видели больше, чем неуклюжий ящик с железом, а Билл с Полом — больше, чем басик для тогдашних холодильников. Прошло время, и компы выросли, стали мощнее, удобнее, дешевле, и уже никто не задается неуместным вопросом, для чего может вообще понадобиться компьютер дома. Первые хакеры, которые возились с PC, рассматривали этот вопрос как конструктивную задачу — и благодаря им появились файловые менеджеры, текстовые процессоры, сети и множество элементарного теперь, привычного нам железа и софта. Уже никто не вспоминает те времена, когда применение ПК для прослушивания музыки, просмотра видео или чтения газет казалось буйной научно-фантастической фантазией. Забыли и то, с каким скепсисом многие относились к прогнозам о будущем интернета.
Я не говорю сейчас о тривиальных параметрах, увеличивающихся по ходу действия закона Мура, — о разрешении видео и тому подобном. Я хотел бы предложить подумать о том, в какое качество можно преобразовать количество терафлопс, которое становится доступным, — что-нибудь из разряда гражданской науки, распределенных вычислений, обработки данных, моделирования еще более сложных био- или наносистем. И о том, как в этом качестве можно было бы совместить научный или технический результат с бизнес-измерением. Давайте не зацикливаться на веб-сайтах, мультимедии и прочей банальщине, давайте смотреть в боле интересные области хакерства и раскрывать их потенциал в создании стартапов. Сегодня — довольно интересный период, когда наряду с чисто софтверными решениями из опостылевшей сферы SoLoMo все чаще возникают и аппаратно-программные. Взять те же 3D-принтеры, уже сейчас упрощающие многие этапы производства и, более того, позволяющие производить то, что вчера нельзя было произвести вообще. ИТ. развившиеся до того, что соединили миллиарды людей и позволили им создавать в цифровой форме глобально доступные социальные, деловые и прочие полезные информационные структуры, все активнее вторгаются и в материальный мир, производство, биомедицину, управление еще более сложными системами вплоть до целых городов и регионов и, более того, позволяют частным субъектам концентрировать ресурсы даже не освоении космоса. Задача настоящих хакеров — не топтаться вокруг того, что уже создано, доказано, исследовано, задача — открывать качественно новые применения терафлопсам, которые скоро превратятся в петафлопсы, и прочим открывающимся возможностям. Строить Будущее, черт возьми, как это делал Джобс. Помните iPad, как его настороженно встретили здесь же на хабре каких-нибудь 2 года назад, как задачились, для чего может вообще пригодиться этот бесклавиатурный айфон-переросток? Я говорил тогда, что это будет уникальный в своем роде социальный гаджет, что его будут использовать так, как мы себе сейчас представить не можем, и в считанные месяцы его освоили музыканты, врачи, официанты, проводники поездов, годовалые дети и вообще все кому не лень. Сейчас можно смело то же самое сказать о дешевых числодробилках. Ну не за месяцы, возможно, ибо тема скорее исследовательская, чем потребительская, но за годы они будут освоены хакерами и поставлены на пользу многомиллионному рынку.
Речь не о текущих недостатках конкретного железа — первый Apple тоже был убогим, но Стив и Стив изначально видели больше, чем неуклюжий ящик с железом, а Билл с Полом — больше, чем басик для тогдашних холодильников. Прошло время, и компы выросли, стали мощнее, удобнее, дешевле, и уже никто не задается неуместным вопросом, для чего может вообще понадобиться компьютер дома. Первые хакеры, которые возились с PC, рассматривали этот вопрос как конструктивную задачу — и благодаря им появились файловые менеджеры, текстовые процессоры, сети и множество элементарного теперь, привычного нам железа и софта. Уже никто не вспоминает те времена, когда применение ПК для прослушивания музыки, просмотра видео или чтения газет казалось буйной научно-фантастической фантазией. Забыли и то, с каким скепсисом многие относились к прогнозам о будущем интернета.
Я не говорю сейчас о тривиальных параметрах, увеличивающихся по ходу действия закона Мура, — о разрешении видео и тому подобном. Я хотел бы предложить подумать о том, в какое качество можно преобразовать количество терафлопс, которое становится доступным, — что-нибудь из разряда гражданской науки, распределенных вычислений, обработки данных, моделирования еще более сложных био- или наносистем. И о том, как в этом качестве можно было бы совместить научный или технический результат с бизнес-измерением. Давайте не зацикливаться на веб-сайтах, мультимедии и прочей банальщине, давайте смотреть в боле интересные области хакерства и раскрывать их потенциал в создании стартапов. Сегодня — довольно интересный период, когда наряду с чисто софтверными решениями из опостылевшей сферы SoLoMo все чаще возникают и аппаратно-программные. Взять те же 3D-принтеры, уже сейчас упрощающие многие этапы производства и, более того, позволяющие производить то, что вчера нельзя было произвести вообще. ИТ. развившиеся до того, что соединили миллиарды людей и позволили им создавать в цифровой форме глобально доступные социальные, деловые и прочие полезные информационные структуры, все активнее вторгаются и в материальный мир, производство, биомедицину, управление еще более сложными системами вплоть до целых городов и регионов и, более того, позволяют частным субъектам концентрировать ресурсы даже не освоении космоса. Задача настоящих хакеров — не топтаться вокруг того, что уже создано, доказано, исследовано, задача — открывать качественно новые применения терафлопсам, которые скоро превратятся в петафлопсы, и прочим открывающимся возможностям. Строить Будущее, черт возьми, как это делал Джобс. Помните iPad, как его настороженно встретили здесь же на хабре каких-нибудь 2 года назад, как задачились, для чего может вообще пригодиться этот бесклавиатурный айфон-переросток? Я говорил тогда, что это будет уникальный в своем роде социальный гаджет, что его будут использовать так, как мы себе сейчас представить не можем, и в считанные месяцы его освоили музыканты, врачи, официанты, проводники поездов, годовалые дети и вообще все кому не лень. Сейчас можно смело то же самое сказать о дешевых числодробилках. Ну не за месяцы, возможно, ибо тема скорее исследовательская, чем потребительская, но за годы они будут освоены хакерами и поставлены на пользу многомиллионному рынку.
Кошки тоже освоили айпад. А по делу добавить нечего.
Как мне кажется (я уже это писал выше) с появлением google glasses (и других аналогичных носимых дисплеев) повится больший спрос на системы дополненной реальности. Например я бы не отказался от adblock'а для такой штуки, который бы замазывал рекламные баннеры поле моего зрения. Да и значение данной технологии нельзя предугадать заранее (так же как и почти никто из фантастов начала 20-го века не предсказал появление мобильных телефонов и интернета).
От замазывать толку никакого, мне лично такой гаджет ненужен. Вот если бы он позволял видеть сквозь рекламный щит, да еще в тоже самое время не позволял бы мне в него врезаться когда я иду, то да
Кстати, фантасты всегда обгоняли время =)
Почитайте Юрия Никитина «Трансчеловек» там присутствуют подобные очки =)
Почитайте Юрия Никитина «Трансчеловек» там присутствуют подобные очки =)
По-моему, обсуждение зашло куда-то не туда. На десктопе (обработка фотографий) 60 гигафлопс не смотрятся. В «мае 2013» у Haswell этих гигафлопсов будет под 400 на CPU и сколько-то (по порядку — еще столько же) на его GPU. В ~70 ваттах.
Да, флопсов на ватт меньше, зато самих флопсов — на порядок больше.
То есть эти большие флопсы на ватт интересны там, где ~100 ватт на системный блок не подашь. Или нет столько питания, или нет столько охлаждения. То есть это мобильные решения во всех смыслах (носимые с аккумулятором, возимые вроде автомобильных). Ну и «встроенные в кухонный шкаф»
И таки да, всякий продвинутый Computer Vision для автомобилей, систем видеонаблюдения — будет востребован. На носимых решениях — не знаю, на тех же планшетах (мне) не хватает в первую очередь RAM, а не CPU.
Да, флопсов на ватт меньше, зато самих флопсов — на порядок больше.
То есть эти большие флопсы на ватт интересны там, где ~100 ватт на системный блок не подашь. Или нет столько питания, или нет столько охлаждения. То есть это мобильные решения во всех смыслах (носимые с аккумулятором, возимые вроде автомобильных). Ну и «встроенные в кухонный шкаф»
И таки да, всякий продвинутый Computer Vision для автомобилей, систем видеонаблюдения — будет востребован. На носимых решениях — не знаю, на тех же планшетах (мне) не хватает в первую очередь RAM, а не CPU.
Количество флопсов на ватт как раз главный показатель в случае если планируется длительное и постоянное использование.
Но не на десктопе же!
А на десктопе у вас есть безлимитное и бесплатное электричество?
Можно я от вашего десктопа ДЦ запитаю?
Можно я от вашего десктопа ДЦ запитаю?
На десктопе время пользователя дороже поэкономленных 75 ватт (77 хасвелловских на полном ходу минус 2 ватта этого чипа).
Потому что 75 ватт-часов стоят, грубо, один цент в час. А время пользователя — десятки баксофф т.е. в *тысячи* раз дороже.
То есть если 77-ваттный CPU экономит несколько секунд юзерского ожидания в рабочий час — он уже окупился.
Потому что 75 ватт-часов стоят, грубо, один цент в час. А время пользователя — десятки баксофф т.е. в *тысячи* раз дороже.
То есть если 77-ваттный CPU экономит несколько секунд юзерского ожидания в рабочий час — он уже окупился.
Да вы что сдурели нет будущего ?! Да тут… от применение в космических технологиях, до применения на даче для умной теплицы =)
у ZiiLABS уже давно есть подобное железо
www.ziilabs.com/products/processors/welcome.php
ZMS-40 (quad Cortex-A9 with 96 StemCell cores)
ZMS-20 (dual Cortex A9 with 48 StemCell cores)
ZMS-08 (single Cortex-A8 with 64 StemCell cores)
ZMS-05 (dual ARM9 with 24 StemCell cores)
на последнем в 2009 выпустили Media Player
но что-то у них не выстреливает
возможно, с усилением мобильных вычислений (Renderscript, OpenCL в новых поколениях ARM-ов) оно и взлетит, но… зачем оно в пользовательских мобильниках? новые рилтайм фильтры для инстаграмов?
у этих вроде как GFlops побольше будет, может Ватт поменьше… но… осталось меньше года, а они обещают платформу и СДК… как-то это… готовые процы от вендоров обкатываются девелоперами год-два
P.S.
тут сравнивают GFlops от суперкомпьютеров и PC с GPU-шными и ARM-овскими
суперкомпьютеры и x86(говоря о CPU) принято оценивать в GFlops двойной точности
GPU-шные обычно говорят про одинарную. Двойную уточняют. Да и двойная точность по GFlops у них обычно в 4+ раз меньше чем одинарная
ARM-овские GFlopsы идут одинарной точности. Для двойной у них только сопроцессор, который не оч. С появлением ARMv8(64-бит), возможно, будут упоминать о двойной
www.ziilabs.com/products/processors/welcome.php
ZMS-40 (quad Cortex-A9 with 96 StemCell cores)
ZMS-20 (dual Cortex A9 with 48 StemCell cores)
ZMS-08 (single Cortex-A8 with 64 StemCell cores)
ZMS-05 (dual ARM9 with 24 StemCell cores)
на последнем в 2009 выпустили Media Player
но что-то у них не выстреливает
возможно, с усилением мобильных вычислений (Renderscript, OpenCL в новых поколениях ARM-ов) оно и взлетит, но… зачем оно в пользовательских мобильниках? новые рилтайм фильтры для инстаграмов?
у этих вроде как GFlops побольше будет, может Ватт поменьше… но… осталось меньше года, а они обещают платформу и СДК… как-то это… готовые процы от вендоров обкатываются девелоперами год-два
P.S.
тут сравнивают GFlops от суперкомпьютеров и PC с GPU-шными и ARM-овскими
суперкомпьютеры и x86(говоря о CPU) принято оценивать в GFlops двойной точности
GPU-шные обычно говорят про одинарную. Двойную уточняют. Да и двойная точность по GFlops у них обычно в 4+ раз меньше чем одинарная
ARM-овские GFlopsы идут одинарной точности. Для двойной у них только сопроцессор, который не оч. С появлением ARMv8(64-бит), возможно, будут упоминать о двойной
32 килобайта локальной памяти на ядро и медленная шина говорят нам: забудьте о десктопном и, тем более, серверном применении! Только мобильные штуки с низким потреблением, причём приложения не должны быть требовательными к скорости доступа к данным в памяти.
Мне кажется, что вы не правы. Учитывая популярность облачных вычислений, эта плата очень хороша.
Вычисления в вебе благодаря этому железу пойдут намного лучше. Редко я вижу облачные сервисы хорошо задействующие видеокарту
Вычисления в вебе благодаря этому железу пойдут намного лучше. Редко я вижу облачные сервисы хорошо задействующие видеокарту
А что вы подразумеваете под облачными вычислениями?
Вообще, очень мало кому надо что-то в облаке считать именно на видеокарте. Вы сходу можете такую задачу придумать? Кому надо было — те давно собрали себе кластерки с видюхами или теслами, ну или у амазона арендуют.
Вообще, очень мало кому надо что-то в облаке считать именно на видеокарте. Вы сходу можете такую задачу придумать? Кому надо было — те давно собрали себе кластерки с видюхами или теслами, ну или у амазона арендуют.
Вот именно арендуют. А зачастую проще купить вот такую плату и считать на ней, чем отдавать на амазон данные.
Видеокарта на порядок! мощнее, а стоят всего в 3 раза дороже. Это если надо матрицы умножать, или биткоины майнить. Но это редко кому надо.
А вы кстати так и не сказали, что такое облачные вычисления.
А вы кстати так и не сказали, что такое облачные вычисления.
Извиняюсь, отвлекся. Возьмем к примеру биоинформатику, а в частности анализ ДНК, его расшифровка, моделирование синтеза новой ДНК цепочки. Там нужны достаточно мощные процессоры. Допустим вы нашли единомышленников, но в разных городах, не имеете большого бюджета. И тут на арену выходит вот эта плата. Процессор(ы) — достачно мощные. Места занимает — мало. Энергии потребляет — не очень много.
Вспомним сколько потребляет видеокарта. Вспомним сколько выделяет тепла. Да это в конце концов видеокарта, она по определению производится для графических вычислений.
А про облачные вычисления я и правда погорячился, не слишком они подойдут. Куда им до видеокарт :-)
Вспомним сколько потребляет видеокарта. Вспомним сколько выделяет тепла. Да это в конце концов видеокарта, она по определению производится для графических вычислений.
А про облачные вычисления я и правда погорячился, не слишком они подойдут. Куда им до видеокарт :-)
Массовый параллелизм должен вызвать переворот в парадигмах программирования. Радуются адпеты функциональных языков — там параллелить легче. Но и ООП прекрасно параллелится, если с головой делать. Сигналы-слоты Qt например, прекрасно вписываются.
А вот почти все фундаментальные алгоритмы написаны под последовательную реализацию. Видимо придется теоретикам хорошенько над ними поработать.
А вот почти все фундаментальные алгоритмы написаны под последовательную реализацию. Видимо придется теоретикам хорошенько над ними поработать.
в спецификациях любимых нам языков есть не особенно кому-то нужное предписание о том, что аргументы функции считаются последовательно. Разрешите их считать параллельно и будет вам шаг к возможности повсеместного распараллеливания.
Сказал человек далекий от низкоуровневого программирования…
и откуда вы меня так хорошо знаете? может мы в школе драйвера, вирусы с антивирусами вместе писали и игрушки в дебагере ломали? а может в универе мы компилятор с++ вместе пислали и векторные процессоры программировали?
>> в спецификациях любимых нам языков есть не особенно кому-то нужное предписание о том, что аргументы функции считаются последовательно.
1. Аргументы функции не считаются а передаются. Порядок передачи аргументов важное предписание
2. Если имелся ввиду порядок вычисления математических выражений, то это зависит от оптимизатора
>> Разрешите их считать параллельно и будет вам шаг к возможности повсеместного распараллеливания.
3а. Если имелись ввиду математические выражения — то будить потоки на каждое выражение? ^_^ т.е. A = B + C + D; вейкает парочку потоков? А синхронизиорвать их как? Ведь нужна промежуточная переменная для суммы
3б. Если имелось ввиду передача параметров в функцию — то еще более непонятно. По потоку на каждый push?
1. Аргументы функции не считаются а передаются. Порядок передачи аргументов важное предписание
2. Если имелся ввиду порядок вычисления математических выражений, то это зависит от оптимизатора
>> Разрешите их считать параллельно и будет вам шаг к возможности повсеместного распараллеливания.
3а. Если имелись ввиду математические выражения — то будить потоки на каждое выражение? ^_^ т.е. A = B + C + D; вейкает парочку потоков? А синхронизиорвать их как? Ведь нужна промежуточная переменная для суммы
3б. Если имелось ввиду передача параметров в функцию — то еще более непонятно. По потоку на каждый push?
Я думаю VAK имел ввиду именно выражения в качестве аргументов. Неважно как сработает оптимизатор — вычисления будут произведены в любом случае не параллельно. Но такая постановка вопроса конечно же не выдерживает критики — выражения могут оперировать общей памятью.
Хотя в функциональных языках это могло бы сработать. Как засинхронизировать результаты — вопрос уже чисто прикладной, так или иначе он решается.
Но. Функциональные языки дают нам не менее элегантную возможность — вообще не вычислять эти выражения, пока они не понадобятся
Хотя в функциональных языках это могло бы сработать. Как засинхронизировать результаты — вопрос уже чисто прикладной, так или иначе он решается.
Но. Функциональные языки дают нам не менее элегантную возможность — вообще не вычислять эти выражения, пока они не понадобятся
2013 год, но даже не Cortex A15, всего лишь A9.
Похоже, не взлетит. Им за 17 дней осталось 450 тысяч собрать
Сама идея «кластер в кладовке/кармане» вызывает слюноотделение и желание взять пару. Но прочитав спеки я так и не смог придумать ни одной задачи для которой это было бы лучше, чем другие решения.
Какие варианты пришли мне ввоспаленный мозг голову (по степени безумности):
Помогите помочь (масленно, но по сути) людям — подскажите зачем оно может понадобится? Даже в качестве хобби :)
Какие варианты пришли мне в
- Несколько видеокамер+realtime оцифровка в 3д модели окружающей среды (робототехника и системы дополненной реальности) — имхо, не хватит каналов входа/выхода на плату/с платы и скорости входа/имхо с/на процессоры.
- полноценный веб сервер — не хватит памяти или пропускной способности.
- SQL база данных — чудовищно не хватит памяти.
- кеширующий числодробящий веб сервер… — не знаю зачем мне это в кладовке :)
- портативный биржевой анализатор — не представляю как такой собрать :) И куда выводить информацию. (Но это хоть близко к потенциальному смыслу, хотя и дальше от него чем серверная ферма брокерской компании).
- управление роем роботов двигающихся вокруг пользователя — no comments ;)
- кластерное первичное каталогизирование лиц (или как это назвать) размера города. То есть opencv строит сетку и посылает её дальше на большие сервера для сравнения с базой данных. — не в кладовку, а в экономичный (по потреблению) датацентр. Но в моей кладовке/кармане — опять нет места для датацентров, да и доступа ко всем камерам москвы/нью-йорка нет.
- ваши идеи? :)
Помогите помочь (масленно, но по сути) людям — подскажите зачем оно может понадобится? Даже в качестве хобби :)
Наверное основная идея в том, что вот она — настоящая предтеча к новому виду компов, заточенных под массовый паралеллизм. Первые энтузиасты обеспечат первичный спрос и с них пойдут деньги на доработку решения,
у которого и памяти будет больше… и стоить оно будет дороже :[
у которого и памяти будет больше… и стоить оно будет дороже :[
Многопоточный компилятор.
Я бы не отказался от такой штуковины как приставке к нетбуку — в поездках ну очень долго компилировать приходится, пишу на C++.
Я бы не отказался от такой штуковины как приставке к нетбуку — в поездках ну очень долго компилировать приходится, пишу на C++.
А еще наверно можно в изысканиях искусственного интеллекта использовать =)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Карманный кластер за $99