fk0, легенда (22.08.2013 14:14, просмотров: 125) ответил =AlexD= на Да, современные процы с out-of-order и register reordering|renaming устроены примерно по такому же принципу, но они вынуждены использовать кучу аппаратуры для трансляции регистрового кода в нечто похожее на триплеты (операнды + результат), на лету[ZX]
-
- да вот не пошла VLIW (как раз таки трансмета, да и DEC побаловался x86->alpha), как раз невозможность компилеру предсказать время поступления данных rd. ставит на EPIC|VLIW крест. были еще варианты, например, ultra sparc имел набор "зеркальных" ыыыы(722 знак., 22.08.2013 14:30)
- влив отстой, у них своих недостатков вышекрыши, проблема в том, что статический анализ идёт лесом, когда появляются не прогнозируемые задержки доступа в память. А так в любом Сишном коде парралелизма уровня выражений полно, хотя на верилоге было =AlexD=(23 знак., 22.08.2013 14:19)
- какие такие задержки, если шины у нормальных VLIWов будут широченные? к примеру 256 бит на код и 2х64 на данные. да к кэшу данных не одна шинка, а 8 по 32 бита. Mahagam(69 знак., 22.08.2013 14:46)
- Сделай мысленный эксперимент. У тебя кеш. У тебя работа с памятью по указателю (например список). Ты возьмёшься предсказать задержки в n-ном потоке исполнения? =AlexD=(356 знак., 22.08.2013 14:57)
- сделай мысленный эксперимент. возьми камень типа L138, где есть VLIW DSP и ARM9. запусти линукс на DSP и заставь ARM9 считать fft и прочую математику. Mahagam(377 знак., 22.08.2013 15:41)
- Это ваще не в тему, DSP код есть чем считать, это ваще не проблема, на крайнях есть GPU и FPGA. Проблема заключается в повышении производительности на совсем другом коде, именно на том, который на ARMах запускают. - =AlexD=(23.08.2013 07:31)
- щетаю, что под каждую задачу есть своя архитектура, подходящая под неё оптимальным образом. не вижу смысла требовать от VLIW особо шустрого исполнения кода общего назначения - Mahagam(23.08.2013 09:30)
- А кто требует? Эта ветка вообще-то была не про VLIW :-) , но даже первое упоминание -> о них касалось проблемы распараллеливания вычислений, =AlexD=(326 знак., 23.08.2013 09:39, ссылка)
- щетаю, что под каждую задачу есть своя архитектура, подходящая под неё оптимальным образом. не вижу смысла требовать от VLIW особо шустрого исполнения кода общего назначения - Mahagam(23.08.2013 09:30)
- Это ваще не в тему, DSP код есть чем считать, это ваще не проблема, на крайнях есть GPU и FPGA. Проблема заключается в повышении производительности на совсем другом коде, именно на том, который на ARMах запускают. - =AlexD=(23.08.2013 07:31)
- сделай мысленный эксперимент. возьми камень типа L138, где есть VLIW DSP и ARM9. запусти линукс на DSP и заставь ARM9 считать fft и прочую математику. Mahagam(377 знак., 22.08.2013 15:41)
- ну а если данные лежат в ячейках i и i+33 и обе они не закешированы, да и банк ddr нужно еще открыть... - ыыыы(22.08.2013 14:55)
- Сделай мысленный эксперимент. У тебя кеш. У тебя работа с памятью по указателю (например список). Ты возьмёшься предсказать задержки в n-ном потоке исполнения? =AlexD=(356 знак., 22.08.2013 14:57)
- какие такие задержки, если шины у нормальных VLIWов будут широченные? к примеру 256 бит на код и 2х64 на данные. да к кэшу данных не одна шинка, а 8 по 32 бита. Mahagam(69 знак., 22.08.2013 14:46)