This time, we're positioning the PS3 as a "supercomputer." But people won't recognize it as a computer unless we call it a computer, so we're going to run an OS on it. In fact, the Cell can run multiple OSes. In order to run the OSes, we need an HDD. So in order to declare that the PS3 is a computer, I think we'll have [the PS3's HDD] preinstalled with Linux as a bonus.
Ого!То співтовариству вільного ПЗ Linux й переносити на Cell не треба
Як сказав Бабаян правильний шлях бінарна перекомпіляція з оптимізацією під нову архітектуру. Створювати принципово нові платформи без бінарної сумісності з старими та переписувати компілятори і софт, або старатись зберегти сумісність програм і тим самим гальмувати розвиток архітектури -- тупікові шляхи...
Про компіляцію - правильно. А от про двійкову сумісність - ні. Відновити алгоритм з коду значно важче і значно менш ефективніше
ніж просто перекомпілювати.
Додати нову функціональність - ніяк. Який сенс запускати аплікацію для MS DOS на суперкомп'ютері, якщо вона не використає і десятої долі функціональності, яка з'явилася після її написання?
Який сенс запускати аплікацію для MS DOS на суперкомп'ютері, якщо вона не використає і десятої долі функціональності, яка з'явилася після її написання?
Ну ліцензія у них як і в усіх BSD-шників крива
Колего, обережніше на поворотах з провокаціями. З.І. Я -- не BSD-шник.
як я зрозумів там просто "емулюються" команди котроїсь з архітектур в іншу архітектуру (в Е2К надзвичайно хороший мікрокод для x86 для SPARC кажуть гірший). Ефективність менша, але архітектура така складна що компілятор написати важко і тим більше під неї писати...
Згода, але на написання прог траба час і фінанси (кажуть розробка RedHat 6.2 з нуля для x86 коштує ~10 млрд$) а про сьогоднішній лінух взагалі мовчу. Замовник хоче повну сумісність бо ті хто писатиме софт писатимуть його на тому що зараз мають -- x86! Коли зявляться в програмістів IA64 і вони вилежуть код під них, для Е2К напишуть мікрокод для "емуляції" перекомпіляції з IA64 в Е2К ітд... це вірний шлях!
Я в попередні постах погано формулював думки...Тут ще моменти є в архітектурі явного паралелізму. Процесор за такт виконує (теоретично) 23 команди. Одночасно можуть працювати багато програм. Я так зрозумів, що у випадку коли запускається бінарник х86 то одразу можуть створюватись 3 паралельні процеси:1. програмна емуляція х86 для моментальної роботи програми (як ви казали неефективна)
2. швидка бінарна перекомпіляція х86 в Е2К яка зберігатиметься в оперативці і наступний запуск програми виконає саме цей "оптимізований код".
3. повільна статична перекомпіляція х86 в Е3М для максимальної оптимізації під дану програмно-апаратну платформу, яка і запишеться на вінт для використання в майбутньому.
На кінець скомпілений паралельний код може запускатись паралельно на всіх 128 процах ЕЗМ
Бінарний компілятор в них є компілятора с, с++, foltran нема і невідомо коли буде, як і немає ОС (бо архітектура дуже складна) ними скомпіленої яка і буде використовувати максимум з архітектури явного паралелізму.
Так що процесор буде використовуватись ефективно навіть при запуску х86 бо зайнятий і іншими задачами... Оптимізований (бінарно скомпілений) для Е3М код покаже кращий результат ніж звичайний х86 на звичайному х86 проці. Вони вважають що (приріст функціональності)/(час, ресурси, як на створення архітектури так і на порт програм для неї) свого максимуму досягає саме при використанні програмної статичної бінарної перекомпіляції!
Видно один бінарний компілятор написати їм набагато швидше, простіше і дешевше ніж компілятор с, с++, foltran...
А тепер що до сонних. Гальманули розвиток архітектури зберігши сумісність з РРС -- зменшили функціональність; добавили нові фітчі під які треба писати компілятор, портувати і оптимізувати софт -- збільшили час та вартість!
Ще раз Сказочнік сказав: вірний шлях це плювати на будь яку апаратну сумісність з старими архітектурами, плювати на проблеми з створенням компіляторів для надскладних нових архітектур та написання під них оптимізованих програм, а розвивати ідеально досконалу архітектуру (простий і швидкий проц за рахунок нових математичних моделей і алгоритмів - любий оптимізатор програє кращому по швидкості алгоритму) і для неї написати програмні перекомпілятори бінарників із старих архітектур. Потрібно зробити тільки проц і перекомпілятор бінарників зі старої архітектури.
Саме тому вони вирішили "спростити" завдання - написати компілятор з двійкового коду і, до того ж, в залізі. :-)
Qemu робить те ж саме за суму на шість порядків меншу. А розробникам я би порадив писати не на x86, а на Сі чи Яві - при дотриманні елементарних правил, код стає придатним для десятків архітектур.qemuqemu з jitc
gccЖаба дусить додати підтримку своєї платформи в gcc?І в той час, як всі інші вже давно перенесли gcc на свою платформу, вони все ще пишуть свій компілятор...
Уявляю однопотокову БД чи апач, який працює паралельно на всіх 128-ми процах.
Трансмета напевно вже завоювала світ.
А головне - скільки мільярдів заробили на PS2 (для PS2 треба на асмі ваяти), сволочі! І ще скільки мільярдів хочуть заробити на PS3...
А мені уявити важко, але я так розумію що проц проводить аналіз самих команд, і ті які можна виконувати паралельно (навіть в одному багатопотоковому проці) розпаралелює...
Трансмета використовує динамічну перекомпіляцію - не ефективну бо один і той же код перекомпільовується багато разів; запхали його в залізо це взагалі їх похоронило бо сильно збільшило кількість транзисторів - вартість проца
The typical behavior of Code Morphing software is to execute a loop that decodes and executes x86 instructions. The first few times a specific x86 code sequence is executed, Code Morphing software interprets the code by decoding the instructions one at a time and then dispatches execution to corresponding VLIW native instruction subroutines. Once the x86 code has been executed several times, Code Morphing software translates the x86 instructions into highly optimized and extremely fast VLIW native instructions, executes the translated code, and caches the native instruction translations for future use. If the same x86 code is required to execute again, the high-performance cached translations are executed immediately and no re-translation is required.
