Java-процессор на FPGA

[Sanyok]

Недели 2 назад пришла идея, что можно было бы такую штуку сделать. Прогуглил - оказалось такая идея людям приходила еще в 1999 г, когда я о Java только краем уха слышал. Казалось бы, перспективная штука, но большинство найденных мной документов по данной теме датированы 2004 г. или раньше. Единственное более позднее сообщение, которое я смог найти - A methodology for Java/FPGA co-design Это только автореферат... Хотелось бы почитать саму работу, тока пока не понятно, как с авторами связаться. Судя по тому, что в автореферате написано, в создании "java-процессора" имеются существенные успехи.

[e2e4]

О Ява-процессоре не знаю, но знаю, что в железе существует (и не один) процессор, моделирующий n-ое кол-во нейронов.

Насчет Ява-процессора - возникает вопрос - а нафига?

[Sanyok]

e2e4 писал(а):

Насчет Ява-процессора - возникает вопрос - а нафига?

Нужно Меня бы устроило, если бы Java-программы выполнялись быстрее, чем программы на C++. Думаю, это понравилось бы многим. Если создать процессор, непостредственно выполняющий байт-код Java, это будет вполне реально. Вы кстати, ссылку не смотрели? А зря! Тогда бы вопроса "на фига" не появилось бы.
Вот цитата оттуда:

Цитата:

As a frst demo application, we have accelerated a
Java application for comparing protein sequences. We
use a Java implementation of the Smith-Waterman-
Gotoh [5], [9] algorithm, based on [8]. We calculated
the cost function for the alignment of one fxed protein
sequence with each sequence in a database of 1000.
This operation took 49.35s on an AMD Athlon MP
2600+ machine for a Java implementation on the
JikesRVM 2.3.5 (a JVM formerly known as Jalapeño
[1]). When we accelerate the application on the same
machine with an Altera PCI Development Board with a
Stratix 1s25 FPGA, we can execute the same operation
in 1.24s, which is a performance gain of almost a
factor 40.

Если учесть, что обычно java-проги медленнее аналогичных, реализованных на компилируемых языках примерно в 10-20 раз, получается что от отставания по скорости по сравнению с компилируемыми языками у Java можно избавиться совершенно.

Имхо, на Java программы писать проще и быстрее, чем на C++. И уж никто не станет спорить с тем, что Java изучить проще, чем C++.

[e2e4]

Цитата:

Нужно Меня бы устроило, если бы Java-программы выполнялись быстрее, чем программы на C++. Думаю, это понравилось бы многим. Если создать процессор, непостредственно выполняющий байт-код Java, это будет вполне реально. Вы кстати, ссылку не смотрели? А зря! Тогда бы вопроса "на фига" не появилось бы.

Просмотрел наискосок. Они сравнили выполнение байт-кода на ява-машине под архитектуру PC, и на оптимизированной ява-машине, реализованной на программируемой логике. Получили некоторый выигрыш. Что это меняет?

Существует две концепкии построения программ и архитектур с точки зрения совместимости:
1. Своя программа под свою архитектуру и окружение. Финалом этого подхода (пока) являются программы, написанные на высокосовместимых реализациях языков высокого уровня (С++ доминирует).
2. Одна программа под любую архитектуру, но между программой и железом - прослойка в виде, по сути, интерпретатора (разного для каждой конкретной архитектуры и окружения), который для языка Ява называется Ява-машиной.

Еще то ли Кнут, то ли Вирт писали (цитата моя, вольная): "По-моему, создается слишком много интерпретаторов и эмуляторов. Если бы силы, вложенные в создание этих прослоек, направить на создание самого прикладного программного обеспечения, это принесло бы несравненно больше пользы".

Ява-программа может выполняться быстрее, чем программа на Си++, только если ей дать фору. В данном случае фора - это программируемая логика. Реализуйте часть критический функций обычной программы аппаратно, и получите еще больший выигрыш в производительности.

[незваный гость]

Sanyok в сообщении #140603 писал(а):

Если учесть, что обычно java-проги медленнее аналогичных, реализованных на компилируемых языках примерно в 10-20 раз,

моим опытом не подтверждается. Возможно, для честного сравнения надо загрузить JDK и запускать в режиме -server (JRE такого эффекта не даёт, похоже, просто игнорирует указание режима).

Добавлено спустя 10 минут 47 секунд:

e2e4 в сообщении #140833 писал(а):

Ява-программа может выполняться быстрее, чем программа на Си++, только если ей дать фору.

Это сильное утверждение. Я так понимаю, за доказательством дело не станет?

Кстати, а кто-нибудь сравнивал GCJ (native) с GCC С++? Было бы весьма любопытно сравнить.

[AlexNew]

Цитата:

Java-процессор на FPGA ... Меня бы устроило, если бы Java-программы выполнялись быстрее, чем программы на C++

какой-то бред! вы совсем ничего похоже не попнимаете....

хотите нормальныю скорость ну так напишите компилятор для джавы например для x86 процессоров, будет не хуже C++

сеичас используется виртуальная машина, которая работает также быстро как любая виртуальная машина. Однако джава для этого и создавалась...

O! уже готово GCJ (the GNU Compiler for the Java language) быстро работаете...
должно быть примерно тоже самое, хотя C++ дает больше вожможностей обьяснить компилятору чего от него хотят поэтому GCJ скорее всего проиграет, но не в тысячи раз как без компилятора думаю для 99,9% приложении разницы в скорости не будет

Добавлено спустя 9 минут 7 секунд:

Цитата:

Существует две концепкии построения программ и архитектур с точки зрения совместимости:
1. Своя программа под свою архитектуру и окружение. Финалом этого подхода (пока) являются программы, написанные на высокосовместимых реализациях языков высокого уровня (С++ доминирует).
2. Одна программа под любую архитектуру, но между программой и железом - прослойка в виде, по сути, интерпретатора (разного для каждой конкретной архитектуры и окружения), который для языка Ява называется Ява-машиной.

все что нужно это стандартный набор API для ОС и язык вроде Java или C++ , а производители плотформ пускай клепаят компиляторы под них, нас это волновать не должно...

инструкции х86 - это жудкое убожество, хотя сеичас сам процессор это фактически компилятор инструкции х86 во внутренние ... цирк одним словом...

реально сеичас программа вжимается в рамки х86 (очень ограниченное колличество регистров, и куча не нужных команд) потом компилятор процессора пытается совместить эти инструкции со своим бнутренним миром... сеичас это уже далеко не премитивнай х86 процессор....

Добавлено спустя 7 минут 8 секунд:

CUDA - пример правельного подхода

[e2e4]

незваный гость писал(а):

e2e4 в сообщении #140833 писал(а):

Ява-программа может выполняться быстрее, чем программа на Си++, только если ей дать фору.

Это сильное утверждение. Я так понимаю, за доказательством дело не станет?

Вы наверное догадались, что я говорил о тех применениях Ява, для которых этот язык создавался, а именно - работа в виртуальной Ява-машине, прослойке между байт-кодом и реальной архитектурой. По определению, лишнее звено - Ява-машина - вносит замедление.

Если же скомпилировать Ява-программу, т.е. сделать ее аппаратно-зависимой, то существенных отличий в скорости работы, при условии грамотного компилятора, быть вроде бы не должно. Хотя Ява не позволяет напрямую использовать логику указателей для адресации памяти, имеет дополнительные замедляющие работу блоки (автоматическая сборка мусора например).

AlexNew писал(а):

все что нужно это стандартный набор API для ОС и язык вроде Java или C++ , а производители плотформ пускай клепаят компиляторы под них, нас это волновать не должно...

Ну и чем тогда Ява будет кординально отличаться от того же Си++?

AlexNew писал(а):

инструкции х86 - это жудкое убожество, хотя сеичас сам процессор это фактически компилятор инструкции х86 во внутренние ... цирк одним словом...

Инструкции как инструкции... Какая собственно, сейчас, в эпоху языков высокого уровня, разница?

AlexNew писал(а):

реально сеичас программа вжимается в рамки х86 (очень ограниченное колличество регистров, и куча не нужных команд) потом компилятор процессора пытается совместить эти инструкции со своим бнутренним миром... сеичас это уже далеко не премитивнай х86 процессор....

Батенька, на тему кол-ва регистров и команд уже столько копий сломано... К чему такая безапелляционность?

[Sanyok]

незваный гость писал(а):

:evil:

Sanyok в сообщении #140603 писал(а):

Если учесть, что обычно java-проги медленнее аналогичных, реализованных на компилируемых языках примерно в 10-20 раз,

моим опытом не подтверждается. Возможно, для честного сравнения надо загрузить JDK и запускать в режиме -server (JRE такого эффекта не даёт, похоже, просто игнорирует указание режима).

Вот тут народ всячески тестировал Java и С/С++. Мои слова о разнице в 10-20 раз - оттуда.

e2e4 писал(а):

Если же скомпилировать Ява-программу, т.е. сделать ее аппаратно-зависимой, то существенных отличий в скорости работы, при условии грамотного компилятора, быть вроде бы не должно. Хотя Ява не позволяет напрямую использовать логику указателей для адресации памяти, имеет дополнительные замедляющие работу блоки (автоматическая сборка мусора например).

Вот, уже теплее
Теперь подумайте - почему бы не сделать наоборот - создать "железную" java-машину, которая будет непосредственно выполнять байт-код аналогично тому, как процессор выполняет машинные инструкции? Тут есть, конечно, препоны - наверняка, байт-код не очень-то оптимизирован для непосредственного машинного выполнения.
Вспомните, первые процессоры x86 вообще не поддерживали операции с плавающей точкой. Сначала были программные эмуляторы. Потом - математические сопроцессоры, ставившиеся в гнездо материнки. Почему не быть java-сопроцессору? Втыкаешь его куда-нибудь на шину PCI-Express, ставишь дрова, и Java-проги перестают тормозить Это конечно, пока фантазии, но имхо, реальностью они стать вполне могут.
Теперь о том, почему на FPGA. Я думаю, это не принципиальное требование - имхо, Java машина вполне может быть сделана целиком в "жестком" виде, как обычный процессор, но это еще вопрос, конечно. Если удастся ее сделать на FPGA без перепрограммирования FPGA "на лету", то и в "жестком виде" ее сделать будет можно. Просто сначала это лучше сделать на FPGA, поскольку это более доступно, можно все отладить. Кое-кто это даже у себя дома делает - покупаешь evaluation board от Altera, к примеру - и вперед.

[e2e4]

Sanyok писал(а):

Теперь подумайте - почему бы не сделать наоборот - создать "железную" java-машину, которая будет непосредственно выполнять байт-код аналогично тому, как процессор выполняет машинные инструкции? Тут есть, конечно, препоны - наверняка, байт-код не очень-то оптимизирован для непосредственного машинного выполнения.
Вспомните, первые процессоры x86 вообще не поддерживали операции с плавающей точкой. Сначала были программные эмуляторы. Потом - математические сопроцессоры, ставившиеся в гнездо материнки. Почему не быть java-сопроцессору? Втыкаешь его куда-нибудь на шину PCI-Express, ставишь дрова, и Java-проги перестают тормозить Это конечно, пока фантазии, но имхо, реальностью они стать вполне могут.

Уважаемый Sanyok, то, о чем Вы говорите, естественно теоретически возможно.
Я даже оцениваю эту идею как классную - еще бы, она ведь создаст еще столько рабочих мест и фирм, производящих Ява-сопроцессор, который пройде множество эволюционных стадий, и за каждый экземпляр которого конечный пользователь заплатит деньги. Хороший маркетинговый ход, тем более что почва - раскрученность языка и немалое кол-во приложений под него - уже имеется.

Однако, с точки зрения эволюции программно-аппаратных комплексов эта идея вряд ли имеет какой-то интерес, ибо корифеи, например Кнут, исследовали эти и подобные идеи еще в далеких 60-х .

[AlexNew]

Цитата:

Батенька, на тему кол-ва регистров и команд уже столько копий сломано... К чему такая безапелляционность?

имел удовольствие писать програмы для х86 и RISC процессоров на ассемблере... регистров не хватает для элементарных операций, тут либо стек надо использовать либо ссылки на на память.. поэтому кэш и дуется в процессорах... подумаите как это коряво делает компилятор и убогость х86 возводится в квадрат. В топку эти процессоры.

Цитата:

Ну и чем тогда Ява будет кординально отличаться от того же Си++?

C++ больше средст для обяснения компилятору чего от него хотят, если компиляторы нормальные разницы не должно быть при стандартных задачах.

Цитата:

почему бы не сделать наоборот - создать "железную" java-машину, которая будет непосредственно выполнять байт-код аналогично тому

совсем не понимаете что говорите...

[e2e4]

AlexNew писал(а):

имел удовольствие писать програмы для х86 и RISC процессоров на ассемблере... регистров не хватает для элементарных операций, тут либо стек надо использовать либо ссылки на на память.. поэтому кэш и дуется в процессорах... подумаите как это коряво делает компилятор и убогость х86 возводится в квадрат. В топку эти процессоры.

Были уже попытки множить регистры. Если не ошибаюсь, Spark'и обладали множеством регистровых файлов, образующих своего рода стек регистров - вход в функцию - старые регистры не видны, новые - видны и так далее, несколько уровней вложенности допускалось.
Однако, довольно скоро люди поняли, что для компиляторов с языков высокого уровня нужно не множество регистров, а большой и быстрый стек.

[AlexNew]

возможно, я плохо разбираюсь в особенностюх работы компиляторов

в любом случае узкое место сеичас софт вроде windows, и пока 90% народа его использует менять что-то нет смысла

мне нравится наблюдать за эволюцией видео карт, они начинают с нуля, и "ядер" там уже сотни ... возможно это и есть будущее

[kpierre]

Такое уже было и даже работало -- http://en.wikipedia.org/wiki/PicoJava. Было заброшено т.к. особой скорости такими усилиями программам на яве не надо. А лисп-машины когда-то были самым краем hi-end'a. Вот они пришлись как раз ко двору, а сейчас куда это применять -- не ясно, компьютеры и так-то мощные, можно позволить себе эмулировать хоть пять лисп-машин сразу.

добавлен тег [url] вокруг ссылки // нг

[AlexNew]

Wikipedia does not have an article with this exact name

[kpierre]

Цитата:

Wikipedia does not have an article with this exact name

Там точку в конце надо убрать