С архитектурами — не совсем «бог», т.к. как вы сами понимаете, софтовая обработка будет медленнее железной :)
Я лично, в силу недостатка знаний и опыта в этой области свое отношение к LLVM сформулировать не могу. То, что Интел этой технологией интересуется — безусловно. В дополнение к открытой информации (спасибо Дима) приведу кусочек закрытой (в надежде, что меня не уволят) :)
Недавно я изучала внутренний список «предложений к реализации» следующей версии компилятора Интел. В числе прочих, там было и предложение, связанное с LLVM. Но будет ли там в итоге поддержка LLVM, и в каком объеме — сказть не могу.
ru.wikipedia.org/wiki/Crusoe — ну да,
«Для исполнения команд х86 используется программная эмуляция в виде виртуальной машины» Еще раз — программная. Мёдозаменитель :).
Понимаете, обычная однопроцессорная настольная машина уже лет пятнадцать (или больше — не помню, когда появились соответствующие ОС) способна вести себя как истинно многозадачная — выполнять «одновременно» столько потоков (процессов), сколько скажет разработчик (хотя и тормозя при этом), и это оно и есть — эмулятор многопоточности :)
Другое дело, что ошибки параллельного программирования на этом эмуляторе не отловишь, ибо на самом деле все не параллельно.
Это должно ответить на ваш вопрос.
Преимущества Интел — изначально в географии :) Фактически, это единственная компания мирового уровня, в которой я хотела бы работать, занимающаяся разработкой софта в моем родном Нижнем Новгороде. Но не только. Еще — в разнообразии доступных возможностей \видов деятельности — и это не только программирование — от решения проблем с железом до написания блогов :), в отличных технических тренингах, некоторых возможностях влиять на решения других крупных компаний (как будет работать их софт :) и в замечательных коллегах.
Программированием, я конечно же, занимаюсь. Иначе-нельзя. Один из недавних проектов — оптимизация части библиотеки IPP для Larrabee.
Рекламировать Larabee пока не буду — сейчас есть только инженерные образцы, судить по которым преждевременно. Скажу только, что до ноутбуков еще очень далеко. Первые Larabee — это не просто десктоп, а hi-end desktop.
Я вас очень хорошо понимаю. И признаю и без того очевидную для многих вещь :) — развитие драйверов Интел почти ко всем встроенным видеокартам, а не только к вашей, увы, отстает от самих карт.
Чипсет -актуальный, в смысле с производства не снят. Но упомянутый вами ASUS Eee PC T91 — с Windows XP. Другие модели с «родным» Ubuntu мне неизвестны. Так что никакой информации о развитии Intel GMA 500 драйверов для Ubuntu мне, увы, найти не удалось.
Никакого проприетарного параллельного API для Larrabee не планируется. Основная идея — поддерживая последние версии OpenGL и DirectX, позволить неграфическим разработчикам программировать для Larrabee точно также, как и для обычных многоядерных ЦПУ, не прибегая ни к каким графическим абстракциям\аналогиям и тп.
Про поддержку OpenCL говорить пока рано. Хотя, _мое личное мнение_ -она нужна.
В компиляторах — прежде всего, это развитие встроенных отладчиков (диагностика возможных ошибок и проблем параллельного программирования). Далее — это развитие OpenMP, улучшение способностей компилятора автоматически вставлять прагмы OpenMP.
А про настоящее автоматическое распараллеливание кода — уверена, что единственно возможный выход — позволить компилятору лишь генерировать идеи — т.е. предлагать возможные варианты распараллеливания, а дальше дать программисту возможность посмотреть на сгенерированный код и решить, подойдут ли они.
Дополню ответ. В процесоорах семейства ARM изначально в архитектуре заложена возможность подключать сопроцессоры, которые и будут переводить байткод в RISK инструкции.
У Атома (x86) такой возможности нет, там придется менять весь CPU front-end — декодирование инструкций. Не уверена, что это технически достаточно просто\эффективно реализуемо. Поэтому о таких планах на ближайшие годы мне ничего неизвестно.
Добавлю к ответу izard только одно — то, что izard — мой коллега, и что с его ответом я абсолютно совместима даже без Linux/BSD и web-приложений :)
Отвечено!
В мелком, технически-бытовом смысле ничего бы менять не стала. Меня вполне устраивают условия труда.
Чтобы принимать глобальные решения, например, о покупке каких-то компаний, или о запуске в новой фабрики, у меня бы не хватило экономической компетенции (что, кстати, не исключает принятия правильного решения, т.к. вероятность тут 1\2 :).
Вообще, Интел декларирует прекрасный набор ориентиров-ценностей, среди которых есть «Ориентация на потребителя», «Ориентация на результат», «Разумный риск (фактически, поощрение инициативы)». Так вот, хотелось бы еще больше приблизить эти теоретические ориентиры к реальной жизни.
1)Насчет _аппаратной_ эмуляции процессором чего-то более сложного, чем он есть на самом деле — это очень странно. Вы не выдаете желаемое за действительное? «Мед -это очень странный предмет, он или есть, или его нет» :)
Что касается софтовой эмуляции различных многоядерных CPU Intel, то я не вижу ни одной причины, чтобы такие эмуляторы нельзя было бы запустить на Larrabee. Другое дело — это что именно они будут эмулировать и с какой точностью. Larrabee -это массив IA32 CPU, соответственно, эмулятор, если он хорошо написан, будет работать значительно быстрее, чем на обычном настольном CPU.
2) На тему аппаратного ускорения java-байткода в грядущих Atom у меня информации нет. Зато знаю, что крупные разработчики Java машин, и JIT в частности сотрудничают с Интел на предмет оптимизации их продуктов под платформы Интел.
В Нижнем Новогороде делались и делаются Инструменты Анализа Производительности — VTune, Thread Checker, Thread Profiler, новейшая разработка «Parallel Studio», а также библиотека Intel Threading Building Blocks, а также ряд интересных экспериментальных «продвинутых» инструментов, бесплатно доступных на whatif.intel.com. Если взять всю нижегородскую область(Саров), то к этому списку можно добавить библиотеки IPP и MKL.
Я лично, в силу недостатка знаний и опыта в этой области свое отношение к LLVM сформулировать не могу. То, что Интел этой технологией интересуется — безусловно. В дополнение к открытой информации (спасибо Дима) приведу кусочек закрытой (в надежде, что меня не уволят) :)
Недавно я изучала внутренний список «предложений к реализации» следующей версии компилятора Интел. В числе прочих, там было и предложение, связанное с LLVM. Но будет ли там в итоге поддержка LLVM, и в каком объеме — сказть не могу.
У меня — другой «полюс» программирования: в основном, это C\C++, местами — ассемблер, местами — фортран :)
«Для исполнения команд х86 используется программная эмуляция в виде виртуальной машины» Еще раз — программная. Мёдозаменитель :).
Понимаете, обычная однопроцессорная настольная машина уже лет пятнадцать (или больше — не помню, когда появились соответствующие ОС) способна вести себя как истинно многозадачная — выполнять «одновременно» столько потоков (процессов), сколько скажет разработчик (хотя и тормозя при этом), и это оно и есть — эмулятор многопоточности :)
Другое дело, что ошибки параллельного программирования на этом эмуляторе не отловишь, ибо на самом деле все не параллельно.
Это должно ответить на ваш вопрос.
Программированием, я конечно же, занимаюсь. Иначе-нельзя. Один из недавних проектов — оптимизация части библиотеки IPP для Larrabee.
Рекламировать Larabee пока не буду — сейчас есть только инженерные образцы, судить по которым преждевременно. Скажу только, что до ноутбуков еще очень далеко. Первые Larabee — это не просто десктоп, а hi-end desktop.
Чипсет -актуальный, в смысле с производства не снят. Но упомянутый вами ASUS Eee PC T91 — с Windows XP. Другие модели с «родным» Ubuntu мне неизвестны. Так что никакой информации о развитии Intel GMA 500 драйверов для Ubuntu мне, увы, найти не удалось.
Про поддержку OpenCL говорить пока рано. Хотя, _мое личное мнение_ -она нужна.
А про настоящее автоматическое распараллеливание кода — уверена, что единственно возможный выход — позволить компилятору лишь генерировать идеи — т.е. предлагать возможные варианты распараллеливания, а дальше дать программисту возможность посмотреть на сгенерированный код и решить, подойдут ли они.
Про java — см. выше
У Атома (x86) такой возможности нет, там придется менять весь CPU front-end — декодирование инструкций. Не уверена, что это технически достаточно просто\эффективно реализуемо. Поэтому о таких планах на ближайшие годы мне ничего неизвестно.
Отвечено!
Чтобы принимать глобальные решения, например, о покупке каких-то компаний, или о запуске в новой фабрики, у меня бы не хватило экономической компетенции (что, кстати, не исключает принятия правильного решения, т.к. вероятность тут 1\2 :).
Вообще, Интел декларирует прекрасный набор ориентиров-ценностей, среди которых есть «Ориентация на потребителя», «Ориентация на результат», «Разумный риск (фактически, поощрение инициативы)». Так вот, хотелось бы еще больше приблизить эти теоретические ориентиры к реальной жизни.
Подробнее — ищите в блоге Интел здесь же, на хабре
А очень полный ответ на этот вопрос я не так давно дала аж в трех постах в блоге на ISN:
software.intel.com/ru-ru/blogs/2009/08/10/arm-atom-x86-pda-umpc/
software.intel.com/ru-ru/blogs/2009/08/12/ii/
software.intel.com/ru-ru/blogs/2009/08/13/iii/
Про аппаратьное ускорение java ответила выше.
Что касается софтовой эмуляции различных многоядерных CPU Intel, то я не вижу ни одной причины, чтобы такие эмуляторы нельзя было бы запустить на Larrabee. Другое дело — это что именно они будут эмулировать и с какой точностью. Larrabee -это массив IA32 CPU, соответственно, эмулятор, если он хорошо написан, будет работать значительно быстрее, чем на обычном настольном CPU.
2) На тему аппаратного ускорения java-байткода в грядущих Atom у меня информации нет. Зато знаю, что крупные разработчики Java машин, и JIT в частности сотрудничают с Интел на предмет оптимизации их продуктов под платформы Интел.
software.intel.com/ru-ru/articles/intel-next-generation-intel-core-i7-processor-family-sdk/