Ada_Ru форум

Обсуждение языка Ада

java & realtime

Оставить новое сообщение

Сообщения

Alexey Veselovsky
java & realtime
2010-10-23 15:46:55

http://www.opennet.ru/opennews/art.shtml?num=28744

 

"Разработчики чудо-автомобиля утверждают, что Java RTS и Solaris

гораздо лучше подходят для работы над подобными проектами, по

сравнению с другими инструментами, с точки зрения надёжности,

прозрачности, возможностей отладки, модели программирования,

предсказуемости времени реакции и стоимости."

 

Как бэ намекают что Ада не нужна :-)

On Tue, 23 Nov 2010 18:46:55 +0300, you wrote:

 

http://www.opennet.ru/opennews/art.shtml?num=28744

 

"Разработчики чудо-автомобиля утверждают, что Java RTS и Solaris гораздо лучше подходят для работы над подобными проектами, по

сравнению с другими инструментами, с точки зрения надёжности,

прозрачности, возможностей отладки, модели программирования,

предсказуемости времени реакции и стоимости."

 

А что они должны по-вашему написать? (:-))

 

Т.к. я имею некоторое отношение к обоим конторам, от дальнейших

комментариев воздержусь.

 

Могу только сказать, что в серию R&D код разумеется не идет, серийный код пишется/генерируется с нуля. Частично, серийный код сертифицирован на разные SIL (Safety Integrity Level) номера.

 

Как бэ намекают что Ада не нужна :-)

 

Ни тот, ни другой код все равно не на Аде.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Похоже это просто рекламная акция вышеназванных технологий. В противном случае смысл выбора солярки от меня ускользает. Они там вообще в автопроме почему-то жабу любят неподетски. Нафига городить монстроидальные фреймфорки вроде MOCCA на С++ имитируя жабскую модель я до сих пор понять не могу. Если бы писали просто на крестах руками без всех этих генерируемых ужасов то софт бы был раза в три меньше и работал бы даже не знаю во сколько раз быстрее. А главное понять его было бы проще.

 

23.11.10, 18:46, "Alexey Veselovsky" <alexey.veselovsky@...>:

 

http://www.opennet.ru/opennews/art.shtml?num=28744

 

"Разработчики чудо-автомобиля утверждают, что Java RTS и Solaris гораздо лучше подходят для работы над подобными проектами, по

сравнению с другими инструментами, с точки зрения надёжности,

прозрачности, возможностей отладки, модели программирования,

предсказуемости времени реакции и стоимости."

 

Как бэ намекают что Ада не нужна :-)

 

 

------------------------------------

 

Yahoo! Groups Links

 

 

 

 

 

 

--

Good luck!

Alexander Molchevsky jolly-fellow@...

Похоже это просто рекламная акция вышеназванных технологий. В противном случае смысл выбора солярки от меня ускользает. Они там вообще в автопроме почему-то жабу любят неподетски. Нафига городить монстроидальные фреймфорки вроде MOCCA на С++ имитируя жабскую модель я до сих пор понять не могу. Если бы писали просто на крестах руками без всех этих генерируемых ужасов то софт бы был раза в три меньше и работал бы даже не знаю во сколько раз быстрее. А главное понять его было бы проще.

 

Я не знаю что там делают с С++. Но наивные реализации на java работают существенно быстрее чем наивные же реализации на С++/Аде просто за счет умного рантайма, который на лету смотрит какой код можно не

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

On Wed, 24 Nov 2010 16:06:30 +0300, you wrote:

 

Я не знаю что там делают с С++.

 

Ничего. Из того, что я знаю, все: С, MISRA-C и разнообразные языки моделирования. Не помню чтобы Java вообще упоминалась в разговорах, хотя всего знать конечно нельзя.

 

Но наивные реализации на java работают

существенно быстрее чем наивные же реализации на С++/Аде просто за счет умного рантайма, который на лету смотрит какой код можно не выполнять где и что можно распараллелить и т.п.

 

Да? Откуда информация? Есть ссылка на опубликованный результат в

peer-reviewed журнале, а не в "могильнике"? Т.к. утверждение мягко говоря сомнительно.

 

А вот касательно Ады, можно сравнить GPS и GNATbench для Eclipse, чтобы увидеть весь ум "рантайма", так сказать...

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Но наивные реализации на java работают

существенно быстрее чем наивные же реализации на С++/Аде просто за счет умного рантайма, который на лету смотрит какой код можно не выполнять где и что можно распараллелить и т.п.

 

Да? Откуда информация? Есть ссылка на опубликованный результат в peer-reviewed журнале, а не в "могильнике"? Т.к. утверждение мягко говоря сомнительно.

Про что именно? Про sse? Про автоматическое распараллеливание? Это из личного опыта. Надеюсь к понедельнику осилю таки дописать пост в свой бложик (там правда будет побольшей части про конвертацию float->int, вы наверняка это всё знаете и вам будет не интересно).

 

Правда не сказал бы что автоматическое распараллеливание на моих

тестах помогло жабе, скорее наоборот. Может в реальных задачах оно и рулит где-нибудь. Надо будет ещё поэкспериментировать в эту сторону.

А вот касательно Ады, можно сравнить GPS и GNATbench для Eclipse, чтобы увидеть весь ум "рантайма", так сказать...

Системы сильно не равнозначные. Eclipse существенно гибче и, строго говоря, IDE не является.

On 11/24/2010 04:06 PM, Alexey Veselovsky wrote:

Похоже это просто рекламная акция вышеназванных технологий. В противном случае смысл выбора солярки от меня ускользает. Они там вообще в автопроме почему-то жабу любят неподетски. Нафига городить монстроидальные фреймфорки вроде MOCCA на С++ имитируя жабскую модель я до сих пор понять не могу. Если бы писали просто на крестах руками без всех этих генерируемых ужасов то софт бы был раза в три меньше и работал бы даже не знаю во сколько раз быстрее. А главное понять его было бы проще.

 

Я не знаю что там делают с С++. Но наивные реализации на java работают существенно быстрее чем наивные же реализации на С++/Аде просто за счет умного рантайма, который на лету смотрит какой код можно не выполнять где и что можно распараллелить и т.п. Ну и всякое разное sse применяет на лету же, если это доступно.

 

Можно про SSE поподробнее? Это же SIMD для x86 процессоров?

 

Мой опыт использования SSE показывает, что нифига быстрее не будет если не прыгать с бубном. И не только мой, я натыкался на подтверждение своих наблюдений. Но если это не так, то ОЧЕНЬ интересно поглядеть и познать непознанное.

Мой опыт использования SSE показывает, что нифига быстрее не будет если не прыгать с бубном. И не только мой, я натыкался на подтверждение своих наблюдений. Но если это не так, то ОЧЕНЬ интересно поглядеть и познать непознанное.

 

sse в моем случае это пребразование float->int, там есть буквально инструкция для этого (конкретно для trunc'a), также есть в принципе инструкция для одновременного конвертирования сразу двух float'ов. но с этим я ещё не игрался.

 

Без sse (сишненький код) у меня времена отработки теста порядка

0.7-1.5 секунды. Ява сразу дает 0.2 секунды. Если включить sse в gcc, то имеем те же 0.2 секунды. Если руками перевести fpu в правильный режим (а не дергать его каждый раз из режима в режим как это делается по умолчанию в приведении типов в сях), то без sse у меня получилось что-то вроде 0.5 секунды. Это на интеле. На АМД картина несколько иная (в частности там хреновей работает sse).

Да, а ява в моих тестах при некоторых параметрах пыталась раскидать (автоматически) вычисления по разным ядрам машины.

On 11/24/2010 04:53 PM, Alexey Veselovsky wrote:

Мой опыт использования SSE показывает, что нифига быстрее не будет если не прыгать с бубном. И не только мой, я натыкался на подтверждение своих наблюдений. Но если это не так, то ОЧЕНЬ интересно поглядеть и познать непознанное.

 

sse в моем случае это пребразование float->int, там есть буквально инструкция для этого (конкретно для trunc'a), также есть в принципе инструкция для одновременного конвертирования сразу двух float'ов. но с этим я ещё не игрался.

 

Для float->int компилятор gcc действительно умеет генерировать

мистическую команду:

 

my_c:

cvttss2si %xmm0, %eax

ret

 

GNAT же на эквивалентном преобразовании ведёт себя более вывороченно:

_ada_my:

ucomiss .LC0(%rip), %xmm0

jae .L8

fldt .LC1(%rip)

movss %xmm0, -28(%rsp)

flds -28(%rsp)

fsubp %st, %st(1)

fisttpl -12(%rsp)

movl -12(%rsp), %eax

ret

.L8:

fldt .LC1(%rip)

movss %xmm0, -28(%rsp)

flds -28(%rsp)

faddp %st, %st(1)

fisttpl -12(%rsp)

movl -12(%rsp), %eax

ret

 

начав мутить с SSE быстренько переползает на FPU

 

Вывод - нужно жаловаться :-)

 

Без sse (сишненький код) у меня времена отработки теста порядка

0.7-1.5 секунды. Ява сразу дает 0.2 секунды. Если включить sse в gcc, то имеем те же 0.2 секунды. Если руками перевести fpu в правильный режим (а не дергать его каждый раз из режима в режим как это делается по умолчанию в приведении типов в сях), то без sse у меня получилось что-то вроде 0.5 секунды. Это на интеле. На АМД картина несколько иная (в частности там хреновей работает sse).

 

Видимо Ваша задача достаточно специфическая и специально подобранная инструкция даёт преимущество. Случай Java тут как бы даже и не

интересен, это не способность что-то не выполнять, а просто

использование соответствующей аппаратной инструкции, что в Java делается автоматически. Думаю если виртуальной машине Java "подсказать" некоторый старый CPU, в котором соответствующая команда отсутствует, то и она "завалится". Если Вы знаете как сделать такое, было бы интересно

сравнить результаты.

On Wed, 24 Nov 2010 16:41:30 +0300, you wrote:

 

Но наивные реализации на java работают

существенно быстрее чем наивные же реализации на С++/Аде просто за счет умного рантайма, который на лету смотрит какой код можно не

выполнять где и что можно распараллелить и т.п.

 

Да? Откуда информация? Есть ссылка на опубликованный результат в peer-reviewed журнале, а не в "могильнике"? Т.к. утверждение мягко говоря сомнительно.

 

Про что именно? Про sse? Про автоматическое распараллеливание?

 

Про все. Я как Станиславский - не верю!

 

(Впрочем, к automotive все это вообще никакого отношения, очевидно, не имеет.)

 

А вот касательно Ады, можно сравнить GPS и GNATbench для Eclipse, чтобы увидеть весь ум "рантайма", так сказать...

 

Системы сильно не равнозначные. Eclipse существенно гибче и, строго говоря, IDE не является.

 

Ага, только мне на эту липовою гибкость плевать, мне работающая система нужна. Так вот, GPS на сегодняшний день самое быстрое, удобное, и, даже, стабильное что есть на рынке. И это не смотря на гнилое ядро GTK и питоновые скрипты. А было бы все на Аде, так вообще бы летало.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Для float->int компилятор gcc действительно умеет генерировать

мистическую команду:

 

my_c:

       cvttss2si       %xmm0, %eax

       ret

 

Ну, это sse и есть :-)

 

GNAT же на эквивалентном преобразовании ведёт себя более вывороченно: начав мутить с SSE быстренько переползает на FPU

Вывод - нужно жаловаться :-)

А я в плане Ады ещё не курил. Там, по стандарту, как должно

происходить преобразование float->int? Отбрасывание дробной части (Trunc)? Округление (Round)? Или же какой-нибудь Floor?

 

Видимо Ваша задача достаточно специфическая и специально подобранная инструкция даёт преимущество. Случай Java тут как бы даже и не

интересен, это не способность что-то не выполнять, а просто

использование соответствующей аппаратной инструкции, что в Java делается автоматически. Думаю если виртуальной машине Java "подсказать" некоторый старый CPU, в котором соответствующая команда отсутствует, то и она "завалится". Если Вы знаете как сделать такое, было бы интересно сравнить результаты.

Ну, если sse инструкций нет, то завялятся все. Чудес ведь не бывает :-) А выкидывание кода, это другая песня. Мне пришлось несколько

помучаться с кодом теста, чтобы ява не выкидывала цикл целиком, чтобы она не выносила из цикла переменную, сразу инициализировав её

вычисленным значением, и т.п.

 

С т.з. sse тут ява интересна тем, что на этапе компиляции программы не нужно думать есть у нас sse или нет. Т.е. не нужно делать разные

сборки для машин с sse и машин без sse. В отличае от gcc того же.

On 11/23/2010 06:46 PM, Alexey Veselovsky wrote:

http://www.opennet.ru/opennews/art.shtml?num=28744

 

"Разработчики чудо-автомобиля утверждают, что Java RTS и Solaris гораздо лучше подходят для работы над подобными проектами, по

сравнению с другими инструментами, с точки зрения надёжности,

прозрачности, возможностей отладки, модели программирования,

предсказуемости времени реакции и стоимости."

 

Как бэ намекают что Ада не нужна :-)

 

Я заставил себя прочитать статью. Цитата:

 

"Java RTS, в случае с Audi TT-S, используется для получения координат с датчиков GPS, и дальнейшей передачи этих данных на другие узлы системы, а также для обеспечения безопасности "управления" автомобилем, так, например, в случае выхода их строя одного из основных узлов, автомобиль полностью останавливается."

 

на мой взгляд это есть ключевой момент. Обратите внимание, что делает эта самая Java ;-) Вот если бы она управляла фокусированием луча лазера или координацией работы узлов двигателя... :-)

Про что именно? Про sse? Про автоматическое распараллеливание?

Про все. Я как Станиславский - не верю!

 

Эмм.. У меня были галлюцинации? :-) Ява же jit'ит байткод в машкод на лету. По сути на машине где выполняется программа и происходит

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

 

Там же, в рантайме, идет статистический анализ исполняемого кода, в процессе выполнения какие-то, часто вызываемые, функции могут быть заинлайнены. Какой-то код, не вляющий ни на что, не будет исполняться вообще. Какие-то переменные (в т.ч. объекты), если это возможно, будут размещены на стэке а не в куче ну и т.п. Это всё лично мне, в

принципе, не удивительно.

 

А вот попытка автоматически раскидать вычисление по разным ядрам -- меня откровенно удивила.

 

(Впрочем, к automotive все это вообще никакого отношения, очевидно, не имеет.)

Угу.

 

Системы сильно не равнозначные. Eclipse существенно гибче и, строго говоря, IDE не является.

 

Ага, только мне на эту липовою гибкость плевать, мне работающая система нужна. Так вот, GPS на сегодняшний день самое быстрое, удобное, и, даже, стабильное что есть на рынке. И это не смотря на гнилое ядро GTK и питоновые скрипты. А было бы все на Аде, так вообще бы летало.

 

Eclipse как IDE для жабы очень и очень не плох. Хотя мне лично

netbeans больше нравится. Eclipse в купе с плагином для ады, как

адовая среда программирования -- полное Г.

 

Кроме того, мне тут давеча довелось поучаствовать в леплении АРМа (автоматизированное рабочее место) на базе Eclips'ы, и не сказал бы что именно с еклипсой возникли какие-то там проблемы. Собственно и тормозов тоже нет.

 

PS. А в линуксах (собственно там АРМ и лепился) Eclipse использует ту же Gtk, так что...

On 11/24/2010 05:56 PM, Alexey Veselovsky wrote:

 

А вот попытка автоматически раскидать вычисление по разным ядрам -- меня откровенно удивила.

 

Может она второй нитью мусор выгребала? :-)

On Wed, 24 Nov 2010 17:54:09 +0300, you wrote:

 

"Java RTS, в случае с Audi TT-S, используется для получения координат с датчиков GPS,

 

Если мне не изменяет память GPS-ов они не делают, тот, что я знаю, мы с ним баловались, то он фирмы Bosch. И подключен, конечно, безо всякой Жабы, а через CAN-шину. Они, наверное, просто драйвер для CAN-контроллера написали под RTS, что явилось предметом гордости. Мы стандартный драйвер пользовали.

и дальнейшей передачи этих данных на другие узлы системы,

 

Ничего никуда передавать не надо, координаты лежат на шине, читай, кто хочет.

 

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

 

Наверное имели ввиду, что они через CAN пишут что-нибудь. Может педаль газа ставят, или бортовую панель меняют, и т.п. Много, что можно сделать, особенно, если не серийная машина, но не все. Не знаю, можно ли так crash-assistant включить, надеюсь, что нельзя. (:-)) Но скорее всего, там просто Fahrroboter устанавливался, вот им они и управляли, а не агрегатами автомобиля, т.к. "by-wire" не все можно.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Новое сообщение:
Страницы: 1

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти