Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 122
а про десктопы глухо?
Думаю, что на десктопный рынок так не выскочить, нужна поддержка со стороны ОС, например.
Cell тоже пока на десктопы не пошел.
В принципе кому-то надо такая вычислительная мощь? Сейчас даже в топовых видеокартах Ati и nVidia и то процессоры стоят на много мощнее чем от Intel и AMD
В принципе кому-то надо такая вычислительная мощь? Сейчас даже в топовых видеокартах Ati и nVidia и то процессоры стоят на много мощнее чем от Intel и AMD
Мощнее только в определенных задачах. Вот выпустит nVidia ЦП - тогда можно сравнивать.
В том-то и дело что в принципе центральній процессор мощній не нужен.
Помню когда Cell выпустили читал что планируют сделать десктоп у которого просто сетевой чип будет Cell, графический несколько Cellов, аудио тоже Cell.
Основная нагрузка в системе(десктоп, я не беру сервера, кластеры и т.д. для сложных мат расчетов) ведь происходит в играх и мультимедия приложениях: а это сеть, обработка и вывод звука ну и самое основное видеокарта
Помню когда Cell выпустили читал что планируют сделать десктоп у которого просто сетевой чип будет Cell, графический несколько Cellов, аудио тоже Cell.
Основная нагрузка в системе(десктоп, я не беру сервера, кластеры и т.д. для сложных мат расчетов) ведь происходит в играх и мультимедия приложениях: а это сеть, обработка и вывод звука ну и самое основное видеокарта
А кто обсчитывает поворот картинки в Фотошопе? Или перекодировку видео-потока?
Хотя если говорить об играх (не виляйте, какие еще такие "мультимедия приложения"?), то да, ЦП там не на первом месте.
Хотя если говорить об играх (не виляйте, какие еще такие "мультимедия приложения"?), то да, ЦП там не на первом месте.
Не центральный процессор... Центральный процессор нужен для чего? Просто распределять задачи в основном.
Перекодировку видео потока по идее видео карта может сделать... стоят же сейчас на видекартах всякие видео декодеры(по моему так называются) для поддержки HD видео. Этим самым снижая нагрузку на ЦП.
В PS3 стоят именно Cell(несколько штук) и игры ведь хорошие и HD видео играет.
Перекодировку видео потока по идее видео карта может сделать... стоят же сейчас на видекартах всякие видео декодеры(по моему так называются) для поддержки HD видео. Этим самым снижая нагрузку на ЦП.
В PS3 стоят именно Cell(несколько штук) и игры ведь хорошие и HD видео играет.
Центральный процессор нужен для чего? Просто распределять задачи в основном.
Мда. Ладно, идите играйте.
Забыл про образовательный эффект. Исправляюсь.
Почитайте на досуге, как на iXBT тестируют процессоры.
Почитайте на досуге, как на iXBT тестируют процессоры.
Во первых играть я не очень люблю и мне не очень сейчас хочется.
Не пойму причем тут ссылка ниже "Методика тестирования производительности
x86-64 процессоров".
Никто не запрещает если у вас нет аппаратного ускорителя на видеокарте использовать мощь ЦП. К тому же и графику можно так сказать обрабатывать как софтварно так и хардварно(даже в играх под винду есть)
Не пойму причем тут ссылка ниже "Методика тестирования производительности
x86-64 процессоров".
Никто не запрещает если у вас нет аппаратного ускорителя на видеокарте использовать мощь ЦП. К тому же и графику можно так сказать обрабатывать как софтварно так и хардварно(даже в играх под винду есть)
Ладно, всё, проехали.
Ok. Просто честно я не вижу не одной области применения на десктопе 2-4 и более ядерных процессоров.
:)
Упомянутые уже игры. Помню как после апгрейда процессора в Unreal стало сложнее играть - боты поумнели.
Обработка видео и звука.
Обработка изображений.
Математические расчёты - matlab, к примеру.
Работа в Firefox - когда он вдруг начинает использовать 100% одного ядра, мой двухядерный процессор продолжает спокойно работать дальше и я могу без проблем и тормозов снять взбесившийся браузер :) Такое у меня случается довольно часто.
Ну и вообще на двухядерном работать приятнее - можно поставить WinRAR паковать большой файл с максимальным сжатием, и/или VirtualDUB перекодировать видео и при этом комфортно смотреть фильм или писать в хабр :)
Упомянутые уже игры. Помню как после апгрейда процессора в Unreal стало сложнее играть - боты поумнели.
Обработка видео и звука.
Обработка изображений.
Математические расчёты - matlab, к примеру.
Работа в Firefox - когда он вдруг начинает использовать 100% одного ядра, мой двухядерный процессор продолжает спокойно работать дальше и я могу без проблем и тормозов снять взбесившийся браузер :) Такое у меня случается довольно часто.
Ну и вообще на двухядерном работать приятнее - можно поставить WinRAR паковать большой файл с максимальным сжатием, и/или VirtualDUB перекодировать видео и при этом комфортно смотреть фильм или писать в хабр :)
для этого достаточно двух вещей: приличная ОС и система приоритетов.
winrar кстати использует два ядра при зжатии.
winrar кстати использует два ядра при зжатии.
Больше ядер нужно там, где задача распараллеливается. Игры параллелятся довольно плохо: для того же AI или рендерера сцены есть данные только для ограниченного количества фреймов.
неправильно. в последнем, с позволения сказать, FEAR используется модель, которая нагружает второй процессор, если в системе не стоит "графического акселератора". и второе ядро выступает в его роли.
по сути, два ядра нужны и в играх и в оси для повседневных задач
по сути, два ядра нужны и в играх и в оси для повседневных задач
где б поучиться параллельному программированию?
всё что я делал - это запускал треды для каких-нибудь фоновых процессов, а было бы интересно посмотреть готовые фреймворки, или способы программирования под многопроцессорные системы.
правда, передо мной пока не стоит таких задач, просто интересно.
всё что я делал - это запускал треды для каких-нибудь фоновых процессов, а было бы интересно посмотреть готовые фреймворки, или способы программирования под многопроцессорные системы.
правда, передо мной пока не стоит таких задач, просто интересно.
не то чтобы готовый фреймворк, но всё равно интересно
http://u-pereslavl.botik.ru/~vadim/MCSha…
http://u-pereslavl.botik.ru/~vadim/MCSha…
используйте Опера:)
Хоть я и пользуюсь оперой by default, но хочу сказать, что она меня временами не радует тем, что в определенные моменты на ровном месте загружает процентов на 80 процессор.
с позволения добавлю. 9я опера стала совсем плоха. единственнополезные нововведения - подержка AJAX и Speed Dial. больше плюсов выделить не могу. а вот работает она не в пример плохо. общее использование памяти доходило и до 600мб (в сумме физич+вирт), проц грузит во время парсинга страниц... на хабре это отчётливо видно, когда комментов много. выход - правильная версия оперы. хоть я и на 9.20, хочу перейти на 8.54
но да ладно, это офтопик.
но да ладно, это офтопик.
600мб? Всего то ;)
У меня она в гугл адсенсе уходит на отметку в 2 гб :)
У меня она в гугл адсенсе уходит на отметку в 2 гб :)
вот это уже серьёзно. но это ведь в сумме:) на самом деле ,физически она занимает в оперативке не болье 80и мегов. причем остальной вес это моя почта - где-то гига на 2.5..
что бы ни говорили, она на голову лучше и удобнее для тех, кто знает как её готовить. это не религия, а просто средство для просмотра "интернета". и это средство для меня лучшее. и я готов вот с такими заглюками мериться.
к слову, такие загрузки в адсенсе могут быть вполне правдивы с подачи самого гугла. ну не любит от этот броузер - не пробашляли, видать.
а оперовцы постоянно вынуждены обновлять browser.js.
нет, точно, соберусь и выложу полезные js для оперы.
что бы ни говорили, она на голову лучше и удобнее для тех, кто знает как её готовить. это не религия, а просто средство для просмотра "интернета". и это средство для меня лучшее. и я готов вот с такими заглюками мериться.
к слову, такие загрузки в адсенсе могут быть вполне правдивы с подачи самого гугла. ну не любит от этот броузер - не пробашляли, видать.
а оперовцы постоянно вынуждены обновлять browser.js.
нет, точно, соберусь и выложу полезные js для оперы.
в опере есть Firebug?
нет. такого тайтла там нет.
а что он делает?
а что он делает?
отладчик
ах!
подозреваю, что в роли него может выступать Web Developer панель в Опере+пару скриптов и пользовательских кнопок
подозреваю, что в роли него может выступать Web Developer панель в Опере+пару скриптов и пользовательских кнопок
может быть, как её вызвать?
хоть ты уже и настоящий индеец, оглашу: появилась: http://help.opera.com/Windows/9.22/en/de…
а пользовать: http://dev.opera.com/tools/
а пользовать: http://dev.opera.com/tools/
А это оно самое умеет делать или нужно применять какие-нибудь утилиты? (да хотя бы вручную в диспетчере-задач менять)
а каким образом это лучше делать?
а каким образом это лучше делать?
что оно самое?
Работа в Firefox - когда он вдруг начинает использовать 100% одного ядра, мой двухядерный процессор продолжает спокойно работать дальше и я могу без проблем и тормозов снять взбесившийся браузер :) Такое у меня случается довольно часто.Вот это. Они же по-умолчанию сразу два ядра используют.
Ну и вообще на двухядерном работать приятнее - можно поставить WinRAR паковать большой файл с максимальным сжатием, и/или VirtualDUB перекодировать видео и при этом комфортно смотреть фильм или писать в хабр :)
Два ядра для десктопа очень удобно. Даже в Windows. На одном работает ОС на втором приложения. Это довольно выгодно.
Вот только windows размазывает работу приложений на оба ядра, т.е. процесс выполняется попеременно то на одном то на другом ядре, что не повышает его быстродействия, особено на AMD сраздельными кэшами ядер.
Ы? Что-то в первый раз про такое слышу. Обычно как-то на одном тусуется. Да и приложения с ядра на ядро во время работы не перекидываются.
В Диспечере задач можно указать на каком ядре приложению можно выполняться
не помогает. установил как-то я на новую свежеустановленну висту новую тольковышедшую уфо.
день поиграл спокойно, всё летало.
на следующий день включаю - игра нещадно тормозит. что такое, почему - не понятно. долго мучался, решил, что это от того, что приложение прыгает с ядра на ядро.
так как в первый день игры я заметил в диспетчере задач, что одно ядро загружено на 100%, а второе практически незагружено.
а потом, когда стало тормозить, игра загружала поровну два ядра, т.е. процесс "прыгал" между ядрами - это единственно объяснение, которое мне пришло в голову. запустить игру на одном ядре у меня так и не вышло, пришлось снести игрушку :)
день поиграл спокойно, всё летало.
на следующий день включаю - игра нещадно тормозит. что такое, почему - не понятно. долго мучался, решил, что это от того, что приложение прыгает с ядра на ядро.
так как в первый день игры я заметил в диспетчере задач, что одно ядро загружено на 100%, а второе практически незагружено.
а потом, когда стало тормозить, игра загружала поровну два ядра, т.е. процесс "прыгал" между ядрами - это единственно объяснение, которое мне пришло в голову. запустить игру на одном ядре у меня так и не вышло, пришлось снести игрушку :)
Стоп стоп. Скорее всего в игре есть поддержка многопоточности, но не очень прямая. В результате вместо повышения производительности вы словили понижение. Лучше поищите в настройках или в интернете как в этой игрушке отключить многопоточность.
все настройки я сразу перерыл.
к выводу о "прыгании" процесса между двумя ядрами я пришёл потому что когда-то раньше читал, быть может на ixbt, большую статью о двухядерных процессорах и о том, как "однотредовые " приложения могут очень сильно терять в производительности, если ОС начинает переключать процесс между ядрами.
больше мне ничего в голову не пришло, да и в первый день диспетчер процессов показывал загруженность одного ядра этой игрой на 100%, а на второй день, когда появились "тормоза", оба ядра были загружены примерно поровну на 50%
к выводу о "прыгании" процесса между двумя ядрами я пришёл потому что когда-то раньше читал, быть может на ixbt, большую статью о двухядерных процессорах и о том, как "однотредовые " приложения могут очень сильно терять в производительности, если ОС начинает переключать процесс между ядрами.
больше мне ничего в голову не пришло, да и в первый день диспетчер процессов показывал загруженность одного ядра этой игрой на 100%, а на второй день, когда появились "тормоза", оба ядра были загружены примерно поровну на 50%
Замечательный пример - обработка /сведение /мастеринг звука. Не секрет, что сейчас ноутбук+хорошая звуковая система уделывают приличный синтезаторный стек как по цене, так и по возможностям, как для студийной работы, так и в живом исполнении. Вот тут как раз процессорная "моща" и пригодится. А многоядерность - тем более.
Но всё-таки не могу не спросить. Только честно ответьте, пожалуйста.
Вы в разделе методики тестирования что-нибудь кроме заголовков и картинок посмотрели? Текст под картинками пробовали читать?
А ниже полистать, до середины страницы?
Вы в разделе методики тестирования что-нибудь кроме заголовков и картинок посмотрели? Текст под картинками пробовали читать?
А ниже полистать, до середины страницы?
Ну, в PS3 стоит только один Cell, или Вы имели в виду ядер?
чуть не подавился, честное слово :).
я вот видео перекодирую часто в самые разнообразные форматы (что ни один чип аппаратный делать не может, только если у него его собственный CPU не будет круче во всех этих задачах чем центральный на компе ;)). Ещё в силу специфики своей работы - часто софт компилирую. Ещё у меня тонна приложений постоянно работает. Ах да, и Java тоже...
Суть в том что задач для центрального CPU можно найти СТОЛЬКО, что аппаратный вариант для каждой из них если и сделать то стоить всё это будет в сотни, если не в тысячи, раз дороже чем один-единственный CPU.
Cell на такой уж крутой в операциях с плавающей запятой. 8+1 ядер из которых 1 отключено а 1 зарезервировано. Итого 6+1.
По поводу CPU Tilera в целом: слишком слабые ядра. Один поток 1080p в реальном времени - это не так уж серьёзно. Крайне проблематично найти столько параллельных задач не требующих высоких мощностей каждая.
я вот видео перекодирую часто в самые разнообразные форматы (что ни один чип аппаратный делать не может, только если у него его собственный CPU не будет круче во всех этих задачах чем центральный на компе ;)). Ещё в силу специфики своей работы - часто софт компилирую. Ещё у меня тонна приложений постоянно работает. Ах да, и Java тоже...
Суть в том что задач для центрального CPU можно найти СТОЛЬКО, что аппаратный вариант для каждой из них если и сделать то стоить всё это будет в сотни, если не в тысячи, раз дороже чем один-единственный CPU.
Cell на такой уж крутой в операциях с плавающей запятой. 8+1 ядер из которых 1 отключено а 1 зарезервировано. Итого 6+1.
По поводу CPU Tilera в целом: слишком слабые ядра. Один поток 1080p в реальном времени - это не так уж серьёзно. Крайне проблематично найти столько параллельных задач не требующих высоких мощностей каждая.
/* Крайне проблематично найти столько параллельных задач не требующих высоких мощностей каждая. */
«столько» это сколько? ;-)
вот несколько популярных: кодирование видео, рендеринг, мат.вычисления, любые *multiuser* сервера — все эти задачи «терпят» размазывание на 64 (хоть и относительно медленных) ядра
данный проц и не претендует на всеядность, но в своей нише параллельных вычислений у подобных решений, думаю, большое будущее — главное чтобы умножение ядер давало соответствующий прирост производительности, и будет «вычислителям» счастье :)
«столько» это сколько? ;-)
вот несколько популярных: кодирование видео, рендеринг, мат.вычисления, любые *multiuser* сервера — все эти задачи «терпят» размазывание на 64 (хоть и относительно медленных) ядра
данный проц и не претендует на всеядность, но в своей нише параллельных вычислений у подобных решений, думаю, большое будущее — главное чтобы умножение ядер давало соответствующий прирост производительности, и будет «вычислителям» счастье :)
Это все круто для задач с хорошей масштабируемостью. Для ворда или игр, которым более 3х-4х потоков уже за уши притягивать надо, это вся многоядерность бесполезна. Потом тут сетка плоская, а не как в модных кластерах 4D.
Чтож, возможно внесу некую ясность во всю дискусию.. Немного истории - Дело в том, что я об этом чипе знал уже год назад, т.к. мой брат работает непосредственно в вышеупомянутой компании над выше и нижеупомянутым чипом. Чип уникален. Intel к примеру, пыталась разработать подобный чип кажется 2 года назад, но их попытка скрылась в дыму и груде расплавленных микросхем. Главе компании понадобилось 16 лет изучения "микропроцессорности", чтобы придумать так называемую подсистему модемов на каждом чипе, дабы те могли независимо общаться друг с другом, в отличие от чипов Intel, общающихся через общую шину, что приводит к потере скорости и производительности. Над чипом рабоют кажется всего 6 инженеров.
Теперь что касается технической части.. В среднем частота чипа 700 МГц. Умножаем это на 64 или хотя бы на 32 получаем адский кусок производительности. Далее, как был упомянуто в статье чип имеет собственный кэш, равный 16 Кбайтам. На первый взгляд не особо впечатляет, но здесь нужно помнить что все запредельные 4 МБ у Intel - это кэш второго уровня - первый уровень кажется не превышает 512 Кбайт.
Теперь самое интересное - чип тестят под Linuxом - а это как всем известно Unix. Удивлению моего родственника не было предела, когда гостив у него в начале лета я купил Mac и показал, что все тесты для которых они используют удалённый терминал (все конечно же пользуются компьютерами Dell и Видновсом соответственно), можно делать на Маке natively. Выводы о возможном будущем этих чипов в десктопах делайте сами. Правда нужно учитывать силу Intel и AMD, а так же неслабый финансовый потенциал и влияние этих корпораций, а так же то, что потребуются нечеловеческие усилия дабы убедить инвесторов (не на свои же 6 инженеров и идейный доктор компьютерных наук всё это организовали), не продавать продукт и что чип на самом деле перспективный и может принести большую прибыль при правильном подходе.
Теперь что касается технической части.. В среднем частота чипа 700 МГц. Умножаем это на 64 или хотя бы на 32 получаем адский кусок производительности. Далее, как был упомянуто в статье чип имеет собственный кэш, равный 16 Кбайтам. На первый взгляд не особо впечатляет, но здесь нужно помнить что все запредельные 4 МБ у Intel - это кэш второго уровня - первый уровень кажется не превышает 512 Кбайт.
Теперь самое интересное - чип тестят под Linuxом - а это как всем известно Unix. Удивлению моего родственника не было предела, когда гостив у него в начале лета я купил Mac и показал, что все тесты для которых они используют удалённый терминал (все конечно же пользуются компьютерами Dell и Видновсом соответственно), можно делать на Маке natively. Выводы о возможном будущем этих чипов в десктопах делайте сами. Правда нужно учитывать силу Intel и AMD, а так же неслабый финансовый потенциал и влияние этих корпораций, а так же то, что потребуются нечеловеческие усилия дабы убедить инвесторов (не на свои же 6 инженеров и идейный доктор компьютерных наук всё это организовали), не продавать продукт и что чип на самом деле перспективный и может принести большую прибыль при правильном подходе.
в отличие от чипов Intel, общающихся через общую шину, что приводит к потере скорости и производительности.
Intel готовит CSI аналог Hypertransport, вместо того чтобы просто использовать HyperTransport. Ну создание своего велосипеда, даже при наличии такового на рынке это так скажем отличительная черта Intel. Процессоры же от AMD вполне можно сабрать в аналогичную матрицу, только это будет конечно не совсем то.
Теперь что касается технической части.. В среднем частота чипа 700 МГц. Умножаем это на 64 или хотя бы на 32 получаем адский кусок производительности.
Не получаем. Так как надо еще это все правильно утилизировать и распараллелить. Как правило линейного роста производительности при увеличении числа ядер не происходит.
Теперь самое интересное - чип тестят под Linuxом - а это как всем известно Unix.
Linux не Unix и никогда им не являлся. Он unix-like система.
Выводы о возможном будущем этих чипов в десктопах делайте сами.
Могу сразу сказать не особо то и нужны :)
Почитайте ради бога что-то серьезное о параллельном выполнении вычислений и больше никогда не умножайте "это на 64 или хотя бы на 32 получаем адский кусок производительности".
цитирую с одного форума:
В процессоре с тактовой частотой ядра 1800 МГц нет ни одной детали, работающей на частоте 3600 МГц. Тактовая частота - физический показатель ядра, если у Вас температура в левой подмышечной впадине 36,7, а в правой - 36,6, это значит, что общая температура тела 73,3 градуса?
В процессоре с тактовой частотой ядра 1800 МГц нет ни одной детали, работающей на частоте 3600 МГц. Тактовая частота - физический показатель ядра, если у Вас температура в левой подмышечной впадине 36,7, а в правой - 36,6, это значит, что общая температура тела 73,3 градуса?
По-моему, эта компания скорее пытается с IBM и их Cell конкурировать, а не с AMD и Intel.
Важное преимущество на мой взгляд, архитектурная масштабируемость такого решения, за ним чувствуется потенциал роста
"архитектурная масштабируемость" кроме как для довольно узкого круга задач не более чем модный слоган. Как, например, масштабировать ворд или браузер до 64 потоков без глобальных блокировок и гонок? А для сепецзадач мы еще в 98м 1024процессорные системы между прочим с 4х мерной сетью связей видели.
Не все задачи нужно распаралеливать. Часто достаточно просто паралельного исполнения задач, т.е. смотрим все это в более крупном масштабе. Для браузера наверное распаралеливание наверное более актуально, но для этого наверное и есть операционная система, ну и сами задачи уже пора писать под "паралельное" исполнение. Т.к. многоядерность факт уже случившийся.
"Параллельных задач", которым сколько-то ощутимо требуется процессор, на машине обычно 4-5, и именно по этому на 2х ядрах мы видим заметный рост. На 4х для повседневной жизни разница будет еле заметна, а 64 от 1024 отличаться будут в отрицательную сторону за счет оверхеда.
"Для браузера наверное распаралеливание наверное более актуально, но для этого наверное и есть операционная система" - не путайте Гоголя с Гегелем. ОС занимается обеспечением приемлемых условий выполнения для потоков и процессов, а вот как у нас браузер параллелит рендеринг странички внутри себя - задача даже не браузера, а программиста. Кроме того, чем больше потоков, тем сложнее вылавливать гонки, глобальные блокировки и синхронизовать это все хозяйство. Для того же браузера овчинка не будет стоить выделки.
"Для браузера наверное распаралеливание наверное более актуально, но для этого наверное и есть операционная система" - не путайте Гоголя с Гегелем. ОС занимается обеспечением приемлемых условий выполнения для потоков и процессов, а вот как у нас браузер параллелит рендеринг странички внутри себя - задача даже не браузера, а программиста. Кроме того, чем больше потоков, тем сложнее вылавливать гонки, глобальные блокировки и синхронизовать это все хозяйство. Для того же браузера овчинка не будет стоить выделки.
Я целиком с вами согласен, именно это имел в виду, просто очевидные вещи писать не хотелось, решил что мы и так поймем друг друга, но все равно спасибо заобмен мнениями. Отдельно спасибо что напомнили про Гоголя и Гегеля, пора отдохнуть и освежить знание русского языка и философской мысли :)
СуперМногоЯдерность вопрос решенный, задачи для этого есть. И писать приложения опираясь на это все же прийдется, какие бы гонки там не были. Кстати, уверяю вас , что при проектировании этого процессора, решение вопросов гонок сигналов по шинам тоже стояло очень остро, но преодолели же!
P.S. Я сам неоднократно отказывался от решения некоторых задач моделирования просто из-за невозможности получить решение в реальный промежуток времени. Например хотя бы за 3е суток:( В сети из 5 машин требовалось более 2х недель только на один вариантик прикидочный. И это для расчета нескольких минут процесса в реальном времени. На самом деле это была банальная , но хорошо подготовленая инженерная задачка. При этом не для самой высокобюджетной отрасли. Вы будите смеяться, но это было птицеводство. Это я отвлекся конечно же.
СуперМногоЯдерность вопрос решенный, задачи для этого есть. И писать приложения опираясь на это все же прийдется, какие бы гонки там не были. Кстати, уверяю вас , что при проектировании этого процессора, решение вопросов гонок сигналов по шинам тоже стояло очень остро, но преодолели же!
P.S. Я сам неоднократно отказывался от решения некоторых задач моделирования просто из-за невозможности получить решение в реальный промежуток времени. Например хотя бы за 3е суток:( В сети из 5 машин требовалось более 2х недель только на один вариантик прикидочный. И это для расчета нескольких минут процесса в реальном времени. На самом деле это была банальная , но хорошо подготовленая инженерная задачка. При этом не для самой высокобюджетной отрасли. Вы будите смеяться, но это было птицеводство. Это я отвлекся конечно же.
Ни ворд ни браузер в том виде, в каком они написаны на данный момент, никак не "смасштабируешь". Пока что ничего тут не поделаешь. Наиболее распространённые языки программирования не поддерживают простое распараллеливание задач. И наиболее распространённые прораммисты :) не умеют писать параллелльные приложения. А вот если бы "ворд и браузер" были написаны на чём-нибудь функциональном, то всем было бы щастье и они "смасштабировались" бы автоматически :).
... на этом месте задумываемся о всё бОльшем проникновении "функциональщины" во многие современные популярные языки программирования - от руби до сишарпа, не говоря уж о всяких там немерле-точка-нет. :)
... на этом месте задумываемся о всё бОльшем проникновении "функциональщины" во многие современные популярные языки программирования - от руби до сишарпа, не говоря уж о всяких там немерле-точка-нет. :)
" "ворд и браузер" были написаны на чём-нибудь функциональном, то всем было бы щастье и они "смасштабировались" бы автоматически :). " и данные из будущего брать для одновременного расчета зависящих друг от друга шагов? Проблема не в программистах и не в языках, а в том, что многие задачи принципиально не позволяют использовать параллельные вычисления. Просто потому, что данные каждого шага зависят от предыдущих или потому, что параллелить просто нечего. Пока пользователь пьет чай ворд стоит на месте, пока страничка не загрузилась рендерить нечего, пока игрок не сделал ход AI его ожидает, пока кто-то эксклюзивно затребовал ресурс - все 1023 процессора стоят и ждут. И это не прихоть и не неумение, а просто объективная реальность.
Зависящие друг от друга шаги - это норма в имеритивном программировании, все к этому привыкли и считают, что иначе и быть не может. Поэтому так трудно писать параллельные программы на империтивных языках. В фунциональных языках всё наоборот - чтобы сделать зависящие друг от друга шаги ещё сильно постараться надо.
Задач, где каждый шаг зависит от предыдущего не так уж и много. Мы просто привыкли их так программировать. Потому что это проще. Но если хорошо и долго думать, то распараллелить можно почти любую задачу. Да, это очень трудно. Да, этому надо специально учиться. Да, есть чуть более лёгкий путь - через функциональщину :).
Что касается простоя 1023 процессоров, то тут я с вами полностью согласен - если ваш процессор (даже единственный) не загружен на 100% - значит вы за него переплатили :). А теперь вспомните как народ хвастается - типа купил новую машину и теперь при одновременном простмотре кина, рендеренге 3д сцены и пережатии двд загрузка процессора - 2% :). Считатеся, что это хорошо. А на самом деле - пятидесятикрантая переплата :) если так считать, как вы предлагаете :).
На самом деле переплачивают не за недогрузку процессора, а за уменьшение времени отклика. Тут кучка процессоров однозначно рулит против одного единственного.
Задач, где каждый шаг зависит от предыдущего не так уж и много. Мы просто привыкли их так программировать. Потому что это проще. Но если хорошо и долго думать, то распараллелить можно почти любую задачу. Да, это очень трудно. Да, этому надо специально учиться. Да, есть чуть более лёгкий путь - через функциональщину :).
Что касается простоя 1023 процессоров, то тут я с вами полностью согласен - если ваш процессор (даже единственный) не загружен на 100% - значит вы за него переплатили :). А теперь вспомните как народ хвастается - типа купил новую машину и теперь при одновременном простмотре кина, рендеренге 3д сцены и пережатии двд загрузка процессора - 2% :). Считатеся, что это хорошо. А на самом деле - пятидесятикрантая переплата :) если так считать, как вы предлагаете :).
На самом деле переплачивают не за недогрузку процессора, а за уменьшение времени отклика. Тут кучка процессоров однозначно рулит против одного единственного.
Эти сказки оставьте для talks на linux.org.ru, там их любят. Если данных нет, потому, что их нет, то данных нет. Не сосчитали их или они с датчика-файла-пользователя-сети не поступили. Или еще время им не пришло. Какое программирование тут ни использовать - все равно. Еще есть такая вещь, как закон Амдаля, хоть какое программирование используй, выше него не прыгнешь.
1023 процессорах стоят не потому, что я за них переплатил, а потому, что gaint-lock произошел и вообще-то я говорил это к тому, что синхронизировать большое число потоков сложно, так как всегда найдутся неразделяемые данные или ресурсы.
1023 процессорах стоят не потому, что я за них переплатил, а потому, что gaint-lock произошел и вообще-то я говорил это к тому, что синхронизировать большое число потоков сложно, так как всегда найдутся неразделяемые данные или ресурсы.
Если данных нет потому что их нет, то мы подождём. Какие проблемы? В это время может выполниться что-нибудь ещё. Просто по факту. И совсем не потому, что программисту данного конкретного приложения не лень было заводить новый тред или форкать процесс для этого "чего-то".
Я ведь не делал утверждений о линейной масштабируемости любых приложений. И не пытался опровергнуть закон Амдаля :).
Я всего лишь о том, что в очень многих приложениях есть запас по ускорению за счёт распараллеливания. Но нам проще думать последовательно, поэтому мы можем даже не подозревать где можно параллелить.
Да сложно синхронизировать, кто ж спорит. Именно поэтому я немного в шутку и написал, что если бы ворд был написан на каком-нибудь хаскеле, то всё, что могло распараллелиться распараллелилось бы автоматически. Конечно, я отдаю себе отчёт, что микрософты не станут писать ворд на хаскеле. И воевать лисп vs сиплюсплюс - ни боже мой! Но помечтать ведь тоже не вредно :)
Кстати, думаю, что если даже раскидать по процессорам хотя бы процессы и треды операционки и пары-тройки рабочих приложений, то невостребованых процессоров из 1024, а тем более из этих 64 может и не остаться. Ну да, большУю часть времени бОльшая часть из них будет стоять и кого-нибудь ждать, но это ж фигня. Сейчас и один-единственный не на 100% загружен. Зато время отклика системы существенно уменьшится. Да и общее быстродействие. Даже не применяя специльных мер по параллельному программированию.
Я ведь не делал утверждений о линейной масштабируемости любых приложений. И не пытался опровергнуть закон Амдаля :).
Я всего лишь о том, что в очень многих приложениях есть запас по ускорению за счёт распараллеливания. Но нам проще думать последовательно, поэтому мы можем даже не подозревать где можно параллелить.
Да сложно синхронизировать, кто ж спорит. Именно поэтому я немного в шутку и написал, что если бы ворд был написан на каком-нибудь хаскеле, то всё, что могло распараллелиться распараллелилось бы автоматически. Конечно, я отдаю себе отчёт, что микрософты не станут писать ворд на хаскеле. И воевать лисп vs сиплюсплюс - ни боже мой! Но помечтать ведь тоже не вредно :)
Кстати, думаю, что если даже раскидать по процессорам хотя бы процессы и треды операционки и пары-тройки рабочих приложений, то невостребованых процессоров из 1024, а тем более из этих 64 может и не остаться. Ну да, большУю часть времени бОльшая часть из них будет стоять и кого-нибудь ждать, но это ж фигня. Сейчас и один-единственный не на 100% загружен. Зато время отклика системы существенно уменьшится. Да и общее быстродействие. Даже не применяя специльных мер по параллельному программированию.
В это время может выполниться что-нибудь ещё.
Ага клиент SETI к примеру :)))
Не могу с вами согласиться про полное распараллеливание. Сколько времени и ресурсов надо чтобы - создать, запустить, приостановить, продолжить, завершить поток? Например иногда лучше поток остановить не сразу, а подожать несколько тактов, и если данные не прийдут уложить его спать (потому что это всё достаточно дорогие операции). В принципе распараллелить можно многое, но где будет выигрышь во времени не известно.
Вспомнилась история девяностых («айдити», так кажется это называлось?).
Интересно сильно ли он греется. Ведьт если в нем каждый процессор довольно мощный, а когда их еще и 64 штуки, то кулер надо нехилый
НЕ куда эта компания не вмешается. Просто громкие слова для привлечения внимания. Возможно, найдут нишу в бытовой или скорее промышленной электронике и всё.
P.S. скоро обвешаемся ядрами. Интел тоже 80-ядерный сделала, если не ошибаюсь. Кто только из программистов будет распараллеливать свои программы под эти процессоры? Не смешите мои тапочки ;-)
P.S. скоро обвешаемся ядрами. Интел тоже 80-ядерный сделала, если не ошибаюсь. Кто только из программистов будет распараллеливать свои программы под эти процессоры? Не смешите мои тапочки ;-)
Партия прикажет - кудаж програмисты денутся...
Наращивание частоты в класической архитектуре близко к пределу, остается распаралеливать.
И моим тапочкам не смешно - из того, что я вижу в top-е и на десктопе, легко можно представить не один десяток активных процессов и потоков.
Наращивание частоты в класической архитектуре близко к пределу, остается распаралеливать.
И моим тапочкам не смешно - из того, что я вижу в top-е и на десктопе, легко можно представить не один десяток активных процессов и потоков.
Кто только из программистов будет распараллеливать свои программы под эти процессоры?
Есть мнение, что это задача компилятора. Или языка программирования (в том смысле, чтобы на нем было удобно писать многопоточный код).
Да вероятно они и смогут сделать наиболее технологичный проц, но не продавшись им не хватит денег на ПР наверно.
Мы ведь только "за" здоровую конкуренцию.
Кстати, почему при попытке написать в "я умный" редиректит в статью в хабравики о карме?
Кстати, почему при попытке написать в "я умный" редиректит в статью в хабравики о карме?
Брат, тут ведь какое дело... Оказывается, надо сначала выйти в плюс. А сделать это можно только через умный комментарий. За который тебе проплюсуют карму или как ее там прямо у тебя в профиле. Мол, отличный парень, личный риспект. А плюсы за комментарии в личном деле не засчитываются. Вот так вот...
Может быть, у них очень крутой инвестор, иначе непонятно, какие у них шансы занять хотя бы 0,1% рынка. Даже ИБМ не удается потеснить Интел и АМД, куда уж там это сделает новая фирма?
Тем более, процессор не дешевый - для корпоративного или гос. сектора - а там предпочитают проверенные решения и долгоиграющих поставщиков.
В общем, забавно и бессмысленно. Надеюсь, я нерав, и эта фирма не станет одной из первых жертв падения доткомов 2.0
Тем более, процессор не дешевый - для корпоративного или гос. сектора - а там предпочитают проверенные решения и долгоиграющих поставщиков.
В общем, забавно и бессмысленно. Надеюсь, я нерав, и эта фирма не станет одной из первых жертв падения доткомов 2.0
Вообще-то одно из "целевых" применений подобных процессоров - веб серверы и серверы приложений, если кто не в курсе.
ну и что? этих производителей встроенного железа - как блох. Freescale Infineon PMC-Sierra Broadcomm STMicroelectronics... к Intel и AMD вообще новость отношения не имеет, ибо не про x86 речь. стоимость вообще зашкаливает для embedded
Трудно представить, что в рыночную битву двух гигантов — Intel и AMD — может вмешаться совершенно неизвестная компания
Применять процессор планируется в бытовой электронике, цифровых тюнерах, сетевых концентраторах и прочих устройствах.
Имхо, первое высказывание не слишком корректно, ведь два гиганта - Intel и AMD работают в основном на рынок декстопов и серверов, и кроме них на этом рынке присутствуют хотя бы VIA(Cyrix) и IBM, ну а если брать бытовую электроннику и прочие устройства, то там присутствуют и другие фирмы-производители, например IBM, Motorola, SiS etc.
Другое дело, если бы эта фирма Tilera вдруг выпустила серверный или десктопный процессор.
Эхх, если бы такой камушек присобачить например к апачу - вообще конфетка получилась бы. Один поток - 1 процессор. Сказка...
я тоже так подумал. Такая удивительная мощность и всего ОДИН поток 1080p.
Кстати, почему нигде не говорится о его архитектуре?
Кстати, почему нигде не говорится о его архитектуре?
Архитектуре чего?
Вы говорите о декодировании 1080p потока, а в статье о кодировании в реальном времени. Поверьте, это совершенно разные вещи, в смысле нагрузки на процессор
...что позволяет Tile64 одновременно обрабатывать до восьми видеопотоков стандартной чёткости... Применять процессор планируется в бытовой электронике, цифровых тюнерах...
Полное впечатление того, что имеется ввиду декодирование.
Тогда дорога ему в студийное оборудование, а не бытовые тюнеры.
Интересно, а чем сейчас кодируется 1080p в реальном времени.
Полное впечатление того, что имеется ввиду декодирование.
Тогда дорога ему в студийное оборудование, а не бытовые тюнеры.
Интересно, а чем сейчас кодируется 1080p в реальном времени.
лучше б у видюшек конкурент появился...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Intel! AMD! Tilera?