Member
Статус: Не в сети Регистрация: 16.09.2006 Откуда: Санкт-Петербург
А то, что уже давно существуют распараллеливающие компиляторы для модульных и многопроцессорных систем - это ничего? Или вот, например, работа NEC, у которой много наработок в данной сфере - http://www.fcenter.ru/online.shtml?hard ... l_id=15980
Member
Статус: Не в сети Регистрация: 16.09.2006 Откуда: Санкт-Петербург
Неа, не провалится... Работают-же их компиляторы на суперах.. Другое дело, что врятли удастся автоматически распаралелить последовательную задачу, но Larrabee-то наверняка предназначается под задачи с явным распараллеливанием потоков вычисления, а для таких вещей наработки всё-же есть. Тут главное прижать програмистов к стенке. Скоро исчезнут одноядерные процессоры, потом двухядерные - хошь-не-хошь, а придётся что-то делать...
Member
Статус: Не в сети Регистрация: 02.02.2007 Откуда: Казахстан
converблин, нафиг я программистом пошел, теперь мне все время про распараллеливание думать чтоли вообщето нынешние компиляторы неплохо оптимизируют под 2-дерность, у самой интел есть готовые профили для VS и Vtune. Думе\ается что со временем по крайне мере под 2-ядерность начнут все компилировать проги.
Member
Статус: Не в сети Регистрация: 16.09.2006 Откуда: Санкт-Петербург
Да-да, и спать с этой мыслью, и в сортир... а уж кондом надевать, так ни о чем другом и не думать..
Да уж скорей-бы начали компилировать, а то слов до фигищи, а как до дела, так только Q4 пока хоть что-то выдаёт вразумительное под двумя ядрами, да разработчики U3-engine грозят всем проходящим из-за забора палками со словами 'ужо мы вам... вот увидите..'.... Не все-же играют в моделлинг и рендер, некоторые хотят просто пострелять во что-нить движущееся и желательно с полноценным использованием вложенных в последний апгрейд денежков .
Junior
Статус: Не в сети Регистрация: 09.01.2007 Откуда: Москва
conver писал(а):
А то, что уже давно существуют распараллеливающие компиляторы для модульных и многопроцессорных систем - это ничего? Или вот, например, работа NEC, у которой много наработок в данной сфере - http://www.fcenter.ru/online.shtml?hard ... l_id=15980
"Верю сразу" (С) Рискну предположить, что эти компиляторы просто занимаются поиском логически изолированных блоков (тех блоков кода, которые можно без опаски выполнить другим ядром, без риска повредить целостность основного процесса). Т.е. распараллеливают то, что изначально может быть распараллелено. Однако интересно было бы взглянуть на результаты трудов этих компиляторов в задачах, где распараллеливание затруднено самим алгоритмом вычислений, где каждая новая итерация неочевидным способом рождает данные для следующей, и количество вариантов входных (и выходных) данных очень велико или бесконечно.
Member
Статус: Не в сети Регистрация: 02.02.2007 Откуда: Казахстан
PinkPanther это не чудо, скорее всего с такими задачами никто не справиться, и это в принципе и правильно, ну с нынешней архитектурой так и должно вроде получатся.
Junior
Статус: Не в сети Регистрация: 09.01.2007 Откуда: Москва
Me4tatelI> писал(а):
PinkPanther это не чудо, скорее всего с такими задачами никто не справиться, и это в принципе и правильно, ну с нынешней архитектурой так и должно вроде получатся.
Дело в том, что при некоторых усилиях некоторые линейные алгоритмы можно распараллелить. Но - вручную, несколько изменив базовый алгоритм программы (который, например, будет предусматривать определение на старте контрольные точки, своего рода кейфреймы, где код может быть разветвлен с минимальными издрежками) и часть ресурсов системы будет направлена именно на поиск этих кейфреймов. Это важно, если задача пишется не под определенную, конкретную систему, а предполагается, что количество ядер может быть плавающим. Для ряда задач на двухъядерных системах, например, такие расчеты могут оказаться избыточными и не дать прироста (прирост от второго ядра будет съеден затратами на поиск кейфреймов), в этом случае выгоднее оставить однопоточный вариант. Моя мысль, собственно, заключается в том, что на данный момент для того, чтобы сделать программу универсальной для любого количества ядер в системе, на которой она в данный момент запускается, потребуются специальные, предварительные расчеты по каждой задаче - единого алгоритма, ИМХО, не существует. Оптимальным также, ИМХО, было бы включение в сборку нескольких модификаций кода, под одно, два, четыре и бОльшее (огромное) количество ядер, алгоритм работы которых бы несколько отличался.
Member
Статус: Не в сети Регистрация: 02.02.2007 Откуда: Казахстан
PinkPanther если будет больашя необходимость, то придумают что то подобное (даже сейчас у ИНтела есть свои многопоточные библиотеки, которые енплохо используют ядра), тем более что хзгять новую нишу первым в таком бизнесе бумается очень привлекательно.
Member
Статус: Не в сети Регистрация: 31.03.2005 Откуда: То там, то сям.
А пчаму тема не закрыта? Тады скажу, вкратце А я думаю, что это будет Grid-архитектура на основе упрощенных, вероятно, суперскалярных вычислительных блоков. С общим, не разделяемым кэшем и мощным межядерным планировщиком. Плюс, всё это могут добавить и наверняка добавят, сигнальные процессоры, функциональность которых будет определятся микропрограммой драйвера (либо звуковой кодек, либо кодер-декодер AES или других систем шифрования, либо вывод видеосигнала) Соответственно драйвером будет определяться тип назначения этого самого Larrabee. Физику ускорять, звук играть, числа считать/массивы сортировать, видео выводить. А еще, наверняка, нагрузка и тип задач будет варьироваться между ядрами и свободно смешиваться(например, звук не будет выводиться пока ящики в гаме не стукнутся, а ящики не стукнутся пока модели не поимеют общих точек координат в области видеопамяти). Задумка хорошая, но гимору с дровами у Ынтеля будет дохвига
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 34
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения