Clojure - lisp для JVM

а вы думаете разрядной сетки хватит? у меня только 32 :-( и времени вечно не хватает :-(

если всё писать на c++ возникает два вопроса

- кто будет покупать квад-коре ксеоны?
- куда девать индусов?

потому жяво взаимовыгодна как производителям железа так и софта. а клиенту объясняется что решения на жябе - secure, powerful, reliable & flexible! это такой себе заговор. пока /me не клиент - /me доволен

>вам поможет backtrace_this и libsegfault

Ну а как такой реальный правда хрестоматийный баг: из-за выхода за границу массива переписывался первый элемент соседней структуры, лежащей в стеке (указатель), который потом... (6 уровней) из-за чего в конечном итоге программа в Debug-сборке была работоспособной, а в Release - неработоспособной? При модели в которой память - это огромный массив unsingned char'ов таких подарков может быть сколько угодно.

Гошпода идеалисты, а есть ли где-нибудь в природе язык с VM, доступный для всего многообразия аппаратных архитектур и нужен ли такой язык вообще? IMHO вопросы риторические.

По subj пока не смотрел пристально, но звучит многообещающе. По крайней мере, этот проект интереснее всяких Mono.

P.S. Такое ощущение, что кто-то очень хочет водрузить джаву на свою поделку на базе i8051, но ему "не даюд".

Во-во. Я никогда не устанавливаю JRE и Mono, и чувствую, что комп с каждым годом работает быстрее) Так что служил 4 года, еще 4 прослужит (если ноут не куплю).

не понял, а что Java исправляет налезшие на друг друга данные? кроме того стек есть? - есть core есть - есть ковыряйся в трупике сколько влезет. Debug работает Release не работает встречал только в Win, но не исключаю конечно описанный баг из за align-ов хитрых.

Точнее 5 лет служил.

>не понял, а что Java исправляет налезшие на друг друга данные?

В Джаве данные друг на друга не налезают - гарантировано архитектурой.

>кроме того стек есть? - есть core есть - есть ковыряйся в трупике сколько влезет.

Эту ботву с нормальным Джавовским стектрейсом сравнивать даже неприлично. Хотя и в Джавовском стектрейсе порой черт ногу сломит.

>луниксе

Ну ты понял, да?

>В Джаве данные друг на друга не налезают - гарантировано архитектурой.

Дык речь идет не о C vs Java, а о C+gcc как замене JRE. Если компилятор написан правильно, то в том же Gambit-C ничего никуда не залезет, как бы ни старался программер в своем исходнике на Scheme. А если в компиляторе (который компилит в С) баги, то чем они принципиально отличаются от багов в _реализации_ JRE ?

> Да. Очень неплохой подход. Пример: http://live.gnome.org/Vala

Красиво и понятно. И главное - никакой жавы или дотнета не нужно!

>Наверно я нечётко указал, к чему относился мой пост. Я предлагал при написании новых языков программирования компилировать их не в код Java-машины, а транслировать в сишный код, который потом можно скомпилить любым коспилятором на любой платформе. А об утечках памяти и работоспособности пусть заботятся авторы транслятора.

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

Вот подтверждение из описания Sun-овской JVM: Adaptive compiler - Applications are launched using a standard interpreter, but the code is then analyzed as it runs to detect performance bottlenecks, or "hot spots". The Java HotSpot VMs compile those performance-critical portions of the code for a boost in performance, while avoiding unnecessary compilation of seldom-used code (most of the program). The Java HotSpot VMs also use the adaptive compiler to decide, on the fly, how best to optimize compiled code with techniques such as in-lining. The runtime analysis performed by the compiler allows it to eliminate guesswork in determining which optimizations will yield the largest performance benefit.

>> Наверно я нечётко указал, к чему относился мой пост. Я предлагал при написании новых языков программирования компилировать их не в код Java-машины, а транслировать в сишный код, который потом можно скомпилить любым коспилятором на любой платформе. А об утечках памяти и работоспособности пусть заботятся авторы транслятора.

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

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

И ещё подход со специализированным языком хорош тем, что можно выкинуть неиспользуемые фишки Java(например, рефлексию) и тем самым ускорить скорость работы кода.

чточто выкинуть, рефлексию?
/me сполз под стол %)

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

Ну это все реклама, а есть результаты измерений, что это дает в реальных программах (я имею ввиду "анализирует выполнение этого кода и если надо перекомпилирует с нужной оптимизацией") ?

> чточто выкинуть, рефлексию? /me сполз под стол %)

Вы прямо-таки даже в "Hello, world" используете рефлексию? Она же не всегда нужна...

> Ну это все реклама, а есть результаты измерений, что это дает в реальных программах (я имею ввиду "анализирует выполнение этого кода и если надо перекомпилирует с нужной оптимизацией") ?

А можно какие-нибудь результаты какие приемущества дает написание какого-нибудь скучного бизнес-приложения для ввода/запроса данных в БД и печатания отчетов на языке ассемблера?

чем? GCC? Этим отмороженным компилятором? Да в нем оптимизации мало того что неэффективны, они еще и опасны. Мой знакомый работает в одной крутой фирме, где разрабатывают встраиваемые системы для автомобилей. Так они исползуют закрытые коммерческие компиляторы, а не это быдло-поделье. Я у него спросил, а почему вы используете GCC, так он сказал, что для Лынуха и Гимпа он может сойдет, а для таких систем это гибель тысяч людей. А то шо ГЦЦ применяется в научных расчетах, да эти расчеты на хуй кому нужны. Это какие-то быдло-квази-профессоришки, решают СЛАУ и потом кончают на нее и засовывают себе в задницу после выступления на очередной быдло-конференции таких-же придурков. А системы моделирования термодинамических, электромагнитных и прочих процессов пишутся на Visual C++. На нем же пишется программа для визуализации этих процессов. И никакого там на хуй ГЦЦ нет. На скольких заводах был везде проги на Visual C++ написаны (+ MFC или WinAPI, а не этот Qt). Так что ГЦЦ используют бомжи, быдлы и lsocket-извращенцы.

MFC? Насмешил. Ты бы еще про блокнот сказал.

А использование Visual C++ предполагает Венду, и "для таких систем это гибель тысяч людей".

сотен тысяч

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

Возможно, но: 1. Промышленные системы критические к скорости исполнения обычно запускаются один раз и надолго; 2. Заранее скомпилировать ты можешь только с определенными настройками оптимизации, JVM же по ходу может неоднократно, на основании многих различным причин перекомпилировать код, чтобы обеспечить оптимальную производительность. Причем со временем критерии оптимальности ведь могут меняться, и статическая компиляция этого не учитывает. Один из примеров работы адаптивного компилятора следующий: если в ходе выполнения выясняется, что механизм вызова методов через таблицу виртуальных методов не нужен, класс будет перекомпилирован и методы будут вызываться напрямую; 3. То что должно запускаться часто, на яве не пишут (обычно); 4. Заранее скомпилировать можно только для определенной платформы; 5. При улучшении JVM не нужно перекомпилировать приложение, достаточно его перезапустить на новой JVM; 6. и т.д.

>Ну это все реклама, а есть результаты измерений, что это дает в реальных программах (я имею ввиду "анализирует выполнение этого кода и если надо перекомпилирует с нужной оптимизацией") ?

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

>И ещё подход со специализированным языком хорош тем, что можно выкинуть неиспользуемые фишки Java(например, рефлексию) и тем самым ускорить скорость работы кода. Так Adaptive compiler этим и занимает, причем постоянно. Т.е. если в данный момент классу или приложению в целом что-то не нужно, он при компиляции это не будет включать в код, но если со временем что-то понадобиться, компилятор перекомпилирует код с поддержкой этих возможностей;

PS: Я долгое время разрабатывал на C++ и сейчас иногда этим занимаюсь, но в основном конечно сейчас приходится на Java разрабатывать. Тоже одно время задавался вопросом производительности и после долгих экспериментов могу сказать, что на современных JVM, если не брать в расчет скорость запуска приложения (нетривиального), то при всех остальных равных условиях JVM ничуть не уступает по производительности предварительной компиляции с C++, а иногда даже превосходит ее. Почему так? Об этом можно почитать здесь: http://blogs.sun.com/vmrobot/.

>чем? GCC? Этим отмороженным компилятором? Да в нем оптимизации мало того что неэффективны, они еще и опасны. Мой знакомый работает в одной крутой фирме, где разрабатывают встраиваемые системы для автомобилей. Так они исползуют закрытые коммерческие компиляторы, а не это быдло-поделье.

Да что вы говорите, в детский садик давно перестали ходить? :)

PS. Прямо таки кроме встраиваемых систем для автомобилей ничего больше в этом мире не существует.

> Но компилировать на лету при каждом запуске(если запускать не один раз :) ) выйдет дороже
Не факт.

> чем один раз в спокойной обстановке скомпилировать, а потом уже запускать готовый бинарник на целевой архитектуре.
Статические компиляторы не в курсе run-time и поэтому не могут провести все необходимые оптимизации. JIT-компилятором доступно больше информации
(к примеру о потоках) и поэтому генерируемый ими код лучше оптимизирован.

> ...и тем самым ускорить скорость работы кода.
И как вы себе это представляете?
Это как: давайте сделаем установку Oracle без поддержки VIEW и строенных процедур, они ведь в _моем_ коде не используются - значит не нужны и Oracle будет работать быстрее :)

> Ну это все реклама, а есть результаты измерений, что это дает в реальных программа...?

Google в помощь.

Либо запускайте Java-приложения в режиме -client / -server и посмотрите на скорость запуска / выполнения.

Поправлюсь: ПО для встроенных критических систем писать на Java я не призываю :-) да и лицензия Java это запрещает

>Да? А ты не в курсе, что jedit на какой-нибудь неLinux-неMac-неWin-неСолярис ОС хрен запустишь?! А долбаная Sun официально и своевременно поддерживает FreeBSD, NetBSD, OpenBSD, Tru64, HP-UX, BeOS, NeXTstep, IRIX, AIX и кучу других операционок???? "Кроссплатформенность" Явы - это фикция, пиар, очередное зомбирование народа аля-Майкасофт. И с безопасностью тоже самое. Пустой треп. А те же gcc и clisp работают на таких платформах, которые Sun и не снились. А Qt? Разве не кроссплатформенность? А FreePascal/Lazarus? Фтопку это быдло поделие (тормозное к тому же).

Иди и скомпили JVM под свою архитектуру и не воняй

Да, есть многое другое. Но и это другое не использует ГЦЦ. ГЦЦ опасен, неэффективен, уродец внутри (а то ж, орава быдл пишет компилятор, без всяких знаний о разработке компиляторов, вдохновляемая только возгласами Столмана). Читай хотя бы это http://habrahabr.ru/blog/os/27641.html

>ГЦЦ опасен, неэффективен, уродец внутри

Чем он опасен то, ядовитый что ли? Насчет неэффективности (скорость работы сгенерированного кода) могу,сказать что да, icc лучше, иногда в 2 раза. Уродец внутри, ну может быть, это вопрос не ко мне, a к его разработчикам. Тем не менее это вполне приличный многоплатформенный компилятор, icc же поддерживает всего 2 архитектуры. А по ссылке, очередной быдлотреп в стиле круто/некруто. Мне на это насрать.

> Вы прямо-таки даже в "Hello, world" используете рефлексию? Она же не всегда нужна...

А кого интересуют средства разработки, которые позволяют сделать ТОЛЬКО hello world? И кто будет тратить на них деньги? ОО язык без рефлексии идет фтопку сразу и быстро. Страуструп это понимает - и пытается протащить рефлексию в плюсы. Но под ногами путается совместимость с С. Жаль его, беднягу (но это другая история).

Достал своими воплями, разработка компилятора для ANSI С под конкретную платформу - наверное соответствует нынешнему уровню дипломной работы.

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

И вообще gcc - это коллекция компиляторов GNU, а не только для С/С++.

>Мой знакомый работает в одной крутой фирме, где разрабатывают встраиваемые системы для автомобилей. Так они исползуют закрытые коммерческие компиляторы

Дык ясен хрен, что заправляет всем там банда старых программистов на Коболе (читай идиотов), которые вынуждены тащить за собой всю эту кучу унаследованного говна написанного на С. И я так думаю несовместимого вообще ни с чем, отсюда и все песни про "супермегакрутые" и "закрытые" коммерческие компиляторы.

И вообще вектор развития направлен в сторону виртуализации. И common runtime platform в виде .Net или JVM - это будущее.

Сейчас на ЛОРе поднимется волна народного гнева и падет на тех, которые модным словечком "виртуализация" не дает людям выжать последний нанофлоп производительности из разогнанного до покраснения 7-ядерного процессора.

Там используется Visual C++ 6/2005

В последнии дни на ЛОРе очень много лисповых тем.
К чему бы это...

> И вообще вектор развития направлен в сторону виртуализации. И common runtime platform в виде .Net или JVM - это будущее.

+много

>Я долгое время разрабатывал на C++ и сейчас иногда этим занимаюсь, но в основном конечно сейчас приходится на Java разрабатывать. Тоже одно время задавался вопросом производительности и после долгих экспериментов могу сказать, что на современных JVM, если не брать в расчет скорость запуска приложения (нетривиального), то при всех остальных равных условиях JVM ничуть не уступает по производительности предварительной компиляции с C++, а иногда даже превосходит ее. Почему так? Об этом можно почитать здесь: http://blogs.sun.com/vmrobot/.


Хе-хе.
Вместо придумывания элегантной схемы синхронизации разработчику советуют просто ПЕРЕсоздавать неизменяемый объект. Объект ImmutableNumberRange создаётся, инициализируется рядом значений в конструкторе (операция якобы атомарна), а для изменения его состояния нужно пересоздавать его заново:
"Организация многопоточных приложений"
http://blogs.sun.com/vmrobot/entry/%D0%BE%D1%80%D0%B3%D0%B0%D0%BD%D0%B8%D0%B7...

"...используя неизменяемый объект ImmutableNumberRange и volatile поле, мы смогли совсем избавиться от synchronized методов.

Возможно, кого-то может напугать, что каждый раз при вызове метода setNumberRange создаётся новый объект, и это может стать причиной снижения производительности. Эти опасения безосновательны. Во-первых, мы получаем выигрыш в производительности за счёт того, что не используем синхронизацию. Во-вторых, в современных виртуальных машинах цена создания нового объекта очень мала, и даже если новая копия NumberRange создаётся очень часто, время жизни создаваемых объектов невелико, и поэтому у современных сборщиков мусора, основанных на поколениях (generational garbage collectors), не возникнет серьёзных проблем при очистке памяти."

Но они не учли, что JVM может по-разному работать на различных аппаратных архитектурах: например, в мобильных устройствах GC не такой умный как в "современных" JVM для десктопов. Кроме того, частота пересоздания объектов может быть просто выше утилизации старых, тогда OutOfMemoryError гарантировано.

Товарищ, мы используем HI-TECH for ARClite microRISC C COMPILER http://www.htsoft.com/purchase/pricelist.php

Стоит $4995

Тогда причем здесь Visual C++ ??

>Concurrency and the multi-core support? Как с этим в С/С++?

о*уительно мистер. OpenMP (если интересует стандарртное решение) и куча разнообразных либ, включая Intel TBB c сопутствующими тулами.

stl + boost + asio или stl + ACE. попробуйте. мне например нравится.

однако соглашусь, что если хочется быстро и недорого, то жаба и .нет - вне конкуренции уже сейчас.

>Иди и скомпили JVM под свою архитектуру и не воняй

Ага. Товарисчи с http://www.freebsd.org/java/ уже несколько месяцев портируют jvm 6. Понаписали тучу патчей, и до сих пор не готово. Ты предлагаешь мне заняться этим вручную? А если бы у меня был Plan9? Молчи лучше, компилятор хренов.

Ну и каким образом, то что gcc не поддерживает эти 8-битные процессоры, реализуемые в FPGA, делает его говном?

Примитивные процессоры --- это отдельная область со своими специфическими проблемами, и причем здесь gcc не понятно. Я бы еще понял наезды на gcc при использовании его для чего-нибудь типа AT9200RM.

>Либо запускайте Java-приложения в режиме -client / -server и посмотрите на скорость запуска / выполнения.

Смотрел уже: http://www.linux.org.ru/view-message.jsp?msgid=1901952

>В последнии дни на ЛОРе очень много лисповых тем. К чему бы это...

Настает что-нибудь_капец.

>>Мой знакомый работает в одной крутой фирме, где разрабатывают встраиваемые системы для автомобилей. Так они исползуют закрытые коммерческие компиляторы

>Дык ясен хрен, что заправляет всем там банда старых программистов на Коболе (читай идиотов), которые вынуждены тащить за собой всю эту кучу унаследованного говна написанного на С. И я так думаю несовместимого вообще ни с чем, отсюда и все песни про "супермегакрутые" и "закрытые" коммерческие компиляторы.

+1, Жжош

>> В последнии дни на ЛОРе очень много лисповых тем. К чему бы это...

> Настает что-нибудь_капец.

Хм... лиспокапец? 8)

>Товарищ, мы используем HI-TECH for ARClite microRISC C COMPILER http://www.htsoft.com/purchase/pricelist.php

>Стоит $4995

Ну и сколько человек им реально занимается? Что это за люди - Боги? Ph.D ? Сколько из этого полчиркана тыс. баксов идет не на разработку, а на быдлолицензии и проч. бумажки?

>Ага. Товарисчи с http://www.freebsd.org/java/ уже несколько месяцев портируют jvm 6. Понаписали тучу патчей, и до сих пор не готово. Ты предлагаешь мне заняться этим вручную? А если бы у меня был Plan9? Молчи лучше, компилятор хренов.

Так в BSD есть какая-то прослойка для нативного запуска линуксовых проложений, вот пусть линуксовую JVM и запускают. А если не могут JVM на интеле скомпилить, так это их ручки.

>И вообще вектор развития направлен в сторону виртуализации. И common runtime platform в виде .Net или JVM - это будущее.

>Sun-ch # (*) (18.10.2007 18:42:21)

С первым утверждением трудно поспорить :)
А вот второе ... я вот лично вижу моЩЩный трэнд засунуть все в vmWare/XEN/хреналысого виртуальную машину а не в .net/jvm ....
Нате вам ось и приложение настроенные и готовые к употреблению, ип- такой то и го ахеад. Проблемы тормозов решаются _предсказуемо_ - больше рамы, больше корок, FC SAN(Clarion) :)

Как тебе Sаныч вот такое видение? Айс?