Российские инженеры разрабатывают транслятор из x86 в ARM
ну да, остается вопрос насколько все это хорошо и быстро будет работать, ибо в данном случае весьма критично
Молодцы. Сложно загадывать, насколько успешен (= востребован) будет такой продукт, но какие-то ниши он займёт, как занимает qemu. По поводу инженеров, по крайней мере в Питере были ребята из «Эльбруса», купленного Intel'ом, осевшие в Intel или Sun (Oracle), занимались разработкой и оптимизацией виртуальных машин Java, у них должна быть требуемая экспертиза.
Пробовали, не хотят питерцы в москву 
Ну, это-то объяснимо, в Питере жить комфортнее. Открывайте маленький центр разработки в Питере, это не так дорого.
что значит "разрабатывают"?
эльбрус изначально так реализован был, они (или тут уместно сказать "вы"?) просто хотят поднять эффективность трансляции и получить на это бабла.
эльбрус изначально так реализован был, они (или тут уместно сказать "вы"?) просто хотят поднять эффективность трансляции и получить на это бабла.
скажите главное - в виндовые игрухи на андроиде можно будет играть?
Ну, это-то объяснимо, в Питере жить комфортнее.Как-то сомнительно, что в этой уныло-дождливой дыре жить комфортнее.
нет конечно. вообще довольно странная затея - вроде есть JVM и ARM Compiler. Зачем же этот костыль нужен - мне пока не очень ясно.
в какие-то уже щас играть можно - qemu/bochs тебе в помощь
Там работается быстрее и бодрее. И отдыхается красочнее.
Зачем им унылая Москва?
Зачем им унылая Москва?
Официально QEMU работает только на х86 и PowerPC, лишь тестовые версии есть для ARM и Sparc, плюс убогого bionic наверняка не хватит, чтобы собрать и запускать QEMU на Android. Другое дело, что с некоторой достаточно большой вероятностью компании Elbrus Technologies имело бы смысл допилить QEMU под ARM, чем писать свой велосипед, если в приоритетах time to market и экономия времени и бабла на разработку.
Если же хочется чего-то своего, тем более закрытого, то да, весь QEMU так просто единолично не присвоить, придётся писать что-то своё. Вообще же что-то закрытое под ARM долго не существует, очень велика конкуренция, если продукт будет востребован, то быстренько появятся открытые аналоги, тот же QEMU на ARM хосте, но, может быть, бизнес-модель такова, что весь продукт с потрохами, патентами, копирайтом и т.д. будет продан в ARM Holdings, который в свою очередь его откроет, кто знает.
Если же хочется чего-то своего, тем более закрытого, то да, весь QEMU так просто единолично не присвоить, придётся писать что-то своё. Вообще же что-то закрытое под ARM долго не существует, очень велика конкуренция, если продукт будет востребован, то быстренько появятся открытые аналоги, тот же QEMU на ARM хосте, но, может быть, бизнес-модель такова, что весь продукт с потрохами, патентами, копирайтом и т.д. будет продан в ARM Holdings, который в свою очередь его откроет, кто знает.
плюс убогого bionic наверняка не хватит, чтобы собрать и запускать QEMU на Androidс новым годом!
я на арме qemu гоняю ещё со времён винмобайл 5, а ты какие-то теории тут строишь
есть сборки (ну, одна точно) под андроид, уже давно
заброшенная правда
Вынужден строить теории, так как у самого желания собирать QEMU под Android ради теста нет, спасибо что сэкономил время. Если он на ARM/bionic работает хорошо, то ещё более удивительным становится начинание, описанное у топик-стартера. Вообще же повторю, что в самом проекте QEMU сказано, что официальной поддержки ARM хостов нет, то есть если что-то «вдруг не работает» на ARM, то всем будет на это пофиг в текущей стадии развития проекта. Были бы у меня инженерные ресурсы, как у какого-нибудь начальника отдела в Elbrus Technologies, я бы «захватил» кусочек власти в QEMU, выделив пару человек на разработку/тестирование и maintenance QEMU на ARM.
удивительное рядом: времени воспользоваться гуглом нет, но нахерачить постов в форуме - сколько угодно
сдаёццо мне ты пиздишь где-то
сравнивать не с чем, кроме досбокса или bochs
работает, по отзывам, быстрее чем досбокс, но настраивается сложнее; c bochs паритет
если транслятор будет работать ещё быстрее, то это будет ваще отлично
сдаёццо мне ты пиздишь где-то
работает хорошо
сравнивать не с чем, кроме досбокса или bochs
работает, по отзывам, быстрее чем досбокс, но настраивается сложнее; c bochs паритет
если транслятор будет работать ещё быстрее, то это будет ваще отлично
Официально QEMU работает только на х86 и PowerPCЩито?
Вообще-то поддерживаются хосты arm, hppa, x86(32 и 64), ia64, mips, ppc(32 и 64), s390, sparc. Плюс все что угодно в режиме TCI.
Элсо "под ARM" не обязательно означает "под Android".
В документации ошибка? Пошли патч.
Working on x86, x86_64 and PowerPC32/64 hosts. Being tested on ARM,
HPPA, Sparc32 and Sparc64. Previous versions had some support for
Alpha and S390 hosts, but TCG (see below) doesn't support those yet.
Этот кусок документации с 2008 года не обновлялся.
998a0501 (Blue Swirl 2008-10-09 18:52:04 +0000 90) @item
998a0501 (Blue Swirl 2008-10-09 18:52:04 +0000 91) Working on x86, x86_64 and PowerPC32/64 hosts. Being tested on ARM,
998a0501 (Blue Swirl 2008-10-09 18:52:04 +0000 92) HPPA, Sparc32 and Sparc64. Previous versions had some support for
998a0501 (Blue Swirl 2008-10-09 18:52:04 +0000 93) Alpha and S390 hosts, but TCG (see below) doesn't support those yet.
Это не доказательство неправильности утверждения из официальной документации. Ещё раз, пошли патч, если у тебя есть более свежие сведения. Пока же в официальной документации проекта написано то, что написано.
Да я собственно никому ничего доказывать не собираюсь. Какие патчи посылать я тоже уж как-нибудь сам решу. Список, который я привел, я взял из кода (tcg/<target_name>/, еще они все в MAINTEINERS есть). Ты можешь и дальше настаивать, что документация лучше знает, чем код, что же есть в коде. Тем более, что я на этих хостах QEMU не запускал, так что имеешь полное право, теоретег.
Там работается быстрее и бодрее. И отдыхается красочнее.Требуется пояснение.
В документации ошибка? Пошли патч.линукс головного мозга
Как раз наоборот! Всё хорошо у него с головным мозгом. Документация должна быть без ошибок, а пользователи должны ошибки не игнорить, а репортить.
Линукс головного мозга выражается в императиве "погугли". В нормальном продукте документация должна быть как минимум верной, как максимум исчерпывающей. Но в современном линукс-мире разработчики на документацию кладут хуй, и пользователи тоже. Я уж не знаю, кто начал первый. Но к 2012 году мы уже приехали к такой ситуации, которая иллюстрируется данным тредом, когда информация из Web 2.0 уже воспринимается не только как более доступная, но и как более верная, чем документация.
Линукс головного мозга выражается в императиве "погугли". В нормальном продукте документация должна быть как минимум верной, как максимум исчерпывающей. Но в современном линукс-мире разработчики на документацию кладут хуй, и пользователи тоже. Я уж не знаю, кто начал первый. Но к 2012 году мы уже приехали к такой ситуации, которая иллюстрируется данным тредом, когда информация из Web 2.0 уже воспринимается не только как более доступная, но и как более верная, чем документация.
Видимо, проблема в том что в условиях ограниченного времени разработчик встаёт перед дилеммой: реализовать или задокументировать.
Видимо, проблема в том что в условиях ограниченного времени разработчик встаёт перед дилеммой: реализовать или задокументировать.Скорее дело в том, что тысяча пользователей, ведущие блоги, напишут больше, чем один человек, пишущий книгу, тем более что ему нужно же ещё и код фигачить (в богатой компании, где есть техписатели, может быть и по-другому).
Я тоже так думаю.
Сейчас между продуктами идёт конкуренция на количество фич. Разработчики гонятся за их количеством, а не за их завершённостью. Соответственно документация идёт в расход первой. Пользователи тоже сравнивают продукты по числу фич. Причём, самому пользователю такой широкий список может быть и не нужен, но хочется чтобы он был. За примерами далеко идти не надо, на флокал всё есть
И ситуация сложилась патовая для документации, так как сформировалось поколение "гуглящих", и даже у тех ортодоксов, которые поддерживают документацию актуальной, в итоге её читают только в том случае, если Google умудрился её выдать выше чем говнища из Web 2.0. А если Google ошибся, то в итоге получается, что документация пишется в стол.
Сейчас между продуктами идёт конкуренция на количество фич. Разработчики гонятся за их количеством, а не за их завершённостью. Соответственно документация идёт в расход первой. Пользователи тоже сравнивают продукты по числу фич. Причём, самому пользователю такой широкий список может быть и не нужен, но хочется чтобы он был. За примерами далеко идти не надо, на флокал всё есть
И ситуация сложилась патовая для документации, так как сформировалось поколение "гуглящих", и даже у тех ортодоксов, которые поддерживают документацию актуальной, в итоге её читают только в том случае, если Google умудрился её выдать выше чем говнища из Web 2.0. А если Google ошибся, то в итоге получается, что документация пишется в стол.
Скорее дело в том, что тысяча пользователей, ведущие блоги, напишут больше, чем один человек, пишущий книгу, тем более что ему нужно же ещё и код фигачитьА "больше" это хорошо? Хорошо когда немного, но точно и достоверно, что априори лучше всего получится у автора.
и даже у тех ортодоксов, которые поддерживают документацию актуальной, в итоге её читают только в том случае, если Google умудрился её выдать выше чем говнища из Web 2.0.ну типа поиск по интернету работает лучше, чем поиск по книжной полке (включая и её электронный вариант в виде свалки в /usr/doc или $HOME/vsyakaya-infa ) - поэтому быстрее получается, если искать ответ сначала в гугле, и только если понятно, что он неправильный, лезть в другие места
буквально сегодня, искал как называется нужная настройка mysql
гуглом
первой была ссылка на документацию, но могла бы быть и на блог - мне без разницы было, надо было только название скопировать оттуда
Хорошо когда немного, но точно и достоверно, что априори лучше всего получится у автора.Не априори. Авторы разные бывают, не все умеют понятно писать, и не все хорошо проверяют то, что пишут - не всегда даже сама возможность такая есть. А в блогах как правило описывают то, что сами видели и проверили - а когда другие пользователи повторили и тоже проверили - дают туда ссылку, и эта информация выходит в топ - так что с достоверностью обычно всё хорошо.
пользователи должны ошибки не игнорить, а репортить.Пользователь ничего не должен.
скажите главное - в виндовые игрухи на андроиде можно будет играть?При хорошем раскладе да. Но пока у нас приоритет - это серверный рынок.
По поводу QEMU.
Тормазнутый он, медленно работает. А в силу тяги к универсальности и не ориентированности на максимальную производительность, допилить его нам видеться более тяжёлой задачей
Тормазнутый он, медленно работает. А в силу тяги к универсальности и не ориентированности на максимальную производительность, допилить его нам видеться более тяжёлой задачей
Я так понимаю, QEMU при эмуляции неродной архитектуры замедляет минимум на порядок.
На что способна ваша штука? Скажем, 2x реально добиться?
На что способна ваша штука? Скажем, 2x реально добиться?
Если бы ты почитал исходную статью, то увидел бы, что сейчас у нас 40% от нативной. Планируем сделать 80%. То есть потери будут всего в 20%.
А про замедление на QEMU на порядок - это ты правильно понимаешь.
Авторы разные бывают, не все умеют понятно писать, и не все хорошо проверяют то, что пишут - не всегда даже сама возможность такая есть. А в блогах как правило описывают то, что сами видели и проверили - а когда другие пользователи повторили и тоже проверили - дают туда ссылку, и эта информация выходит в топ - так что с достоверностью обычно всё хорошо.Сейчас на конференции разработчик ZFS рассказывал про performance tuning и указал, что в Web 2.0 есть ряд т.н. "технических блогов", в которых самозваные иксперды рекомендуют отключать на ZFS checksums для ускорения, ичсх есть куча невинных пользователей, которые этому совету последовали, ведь они прочитали об этом в Интернет!
ичсх есть куча невинных пользователей, которые этому совету последоваличто с ними случилось?
Если на ZFS отключить чексуммы, то никаких гарантий нет что от данных что-то останется после power down.
как они этого добились, есть ссылка?
Чего добились? Отключения чексум? Это одной командой делается.
как добились, что без чексумов не работает запись?
как добились, что без чексумов не работает запись?Хорош тролить:
Если на ZFS отключить чексуммы, то никаких гарантий нет что от данных что-то останется после power down.
Для непонятливых кэп поясняет: power down - это не штатное выключение по питанию. Например свет пропал, а упсы нет.
Для непонятливых кэп поясняет: power down - это не штатное выключение по питанию. Например свет пропал, а упсы нет.я в курсе, но как результат зависит от наличия чексум?
я в курсе, но как результат зависит от наличия чексум?За подробностями лучше к Глебу, тем более он ссылался на "риальных
Могу только предположить, что оно может с ошибкой записать данные и ты никак не поймёшь это. А когда надо будет к данным получить доступ, то будет тебе на выходе не то, что ты туда писал и ZFS ничем не поможет. При включенных чексуммах все ошибочные блоки будут выявлены ранее и, если у тебя ZFS с избыточностью, то они будут восстановлены из "правильных" копий.
> Могу только предположить, что оно может с ошибкой записать данные и ты никак не поймёшь это.
Я всё-таки считаю, что это подозрительно, так как должен быть журнал.
Но учитывая качество кода, допускаю вероятность странностей.
---
"И, как сказал философ Ю. Карякин,
Не разберёшь, где трасса, где объезд..."
Я всё-таки считаю, что это подозрительно, так как должен быть журнал.
Но учитывая качество кода, допускаю вероятность странностей.
---
"И, как сказал философ Ю. Карякин,
Не разберёшь, где трасса, где объезд..."
Да, всё примерно так, как ты объяснил.
Могу только предположить, что оно может с ошибкой записать данные и ты никак не поймёшь это.Ну как бы все ФС, в которых нет чексум (то есть большинство из распространённых) таковы, разве нет? Я бы сказал, что это осознанный риск.
Насколько я понял, ZFS возлагает на чексуммы часть проблем сохранения консистентности, которые в других ФС реализованы как-то ещё, типа счётчиков ссылок и прочее. То есть по вырубанию питания классическая ФС делает fsck и высчитывает инварианты проходя весь диск, журналируемая ФЧ сопоставляет содержимое журнала с теми блоками на которые журнал ссылается, а ZFS же делает последнее но с использованием чексумм.
Вообще у меня очень поверхностное понимание всего этого, я просто хотел обратить внимание на конкретный факт о рассогласованности сведений в Web 2.0 с мнением майнтейнеров кода.
Вообще у меня очень поверхностное понимание всего этого, я просто хотел обратить внимание на конкретный факт о рассогласованности сведений в Web 2.0 с мнением майнтейнеров кода.
журналируемая ФЧ сопоставляет содержимое журнала с теми блоками на которые журнал ссылается,вроде нет, накатывает журнал и всё
конкретный факт о рассогласованности сведений в Web 2.0 с мнением майнтейнеров кодапока что больше похоже, что авторы обиделись, что их любимая фича не всем пользователям нравится
Окей, будем считать что тебе виднее. Если когда нибудь доведётся увидеть ZFS, то конечно отключи чексуммы, чтобы не тормозила.
Если когда нибудь доведётся увидеть ZFS, то конечно отключи чексуммы, чтобы не тормозила.я вот поискал в гугле про ZFS tuning
чтобы убедиться, что вредные советы будут в топе
в первых двух ссылках ничего нет про отключение чексум
в третьей есть, но сначала там говорят, что тюнинг не нужен
но дальше таки написано, как их отключить, если у тебя несбалансированная система: очень много дисков при очень медленном по современным меркам процессореОставить комментарий
onairika
Российские инженеры разрабатывают транслятор из x86 в ARMARM gets weapon in server battle vs. Intel
Rick Merritt
10/2/2012 12:51 PM EDT
SAN JOSE, Calif. – Russian engineers are developing software to run x86 programs on ARM-based servers. If successful, the software could help lower one of the biggest barriers ARM SoC makers face getting their chips adopted as alternatives to Intel x86 processors that dominate today’s server market.
Elbrus Technologies has developed emulation software that currently delivers 40 percent of native ARM performance. The company believes it could reach 80 percent native ARM performance or greater by the end of 2014. Analysts and ARM execs described the code as a significant, but limited option.
[Get a 10% discount on ARM TechCon 2012 conference passes by using promo code EDIT. Click here to learn about the show and register.]
A growing list of companies—including Applied Micro, Calxeda, Cavium, Marvell, Nvidia and Samsung—aim to replace Intel CPUs with ARM SoCs that pack more functions and consume less power. One of their biggest hurdles is their chips do not support the wealth of server software that runs on the x86.
The emulation code from Elbrus Tech could help lower that barrier. The team will present a paper on its work at the ARM TechCon in Santa Clara, Calif., Oct. 30-Nov. 1.
The team’s software uses 1 Mbyte of memory. “What is more exciting is the fact that the memory footprint will have weak dependence on the number of applications that are being run in emulation mode,” Anatoly Konukhov, a member of the Elbrus Tech team, said in an e-mail exchange.
The team has developed a binary translator that acts as an emulator, and plans to create an optimization process for it.
"Currently, we are creating a binary translator which allows us to run applications," Konukhov said. "Implementation of an optimization process will start in parallel later this year--we're expecting both parts be ready in the end of 2014."
"The major concern for us is lack of software developers with binary translation expertise," he added. "This is also the reason for us to estimate project release in late 2014."
The Elbrus Tech software uses a parallel compilation process and stores translations in volatile memory to decrease overhead when starting up. The binary translator will have "several levels of optimization for 'cold' and 'hot' regions of code," said Konukhov.
Work on the software started in 2010. Last summer, Elbrus Tech got $1.3 million in funding from the Russian investment fund Skolkovo and MCST, a veteran Russian processor and software developer. MCST also is providing developers for the project.