Релиз JRuby 1.0.1

ява - не айс хотя будет интересно посмотреть на "интерактивное взаимодействие со средой Java"...

Мдя... Руби и так не способствует высокой производительности, так тут ещё и его интерпретатор на жабе... Куда катится мир?...

>Мдя... Руби и так не способствует высокой производительности, так тут ещё и его интерпретатор на жабе... Куда катится мир?...

В сторону управляемых и предсказуемых сред исполнения.

Кстати, все знают, что Java быстрее, чем C/C++. ;)

Операционная система запускает оболочку, оболочка запускает Java-машину, Java-машина запускает интерпретатор Ruby, интерпретатор выполняет программу на Ruby, в итоге ваш Core 2 duo работает как двойка, а потребляет энергии как сварочный аппарат, к глобальному потеплению катимся...

Одному мне кажется, что жаба, сцуко, зохавывает мир?

>Кстати, все знают, что Java быстрее, чем C/C++. ;)

Это ты пошутил? Да?

зато Тихналагично, Саврименно, Актуально! и пофиг, что каждые 10 минут память кончается или ошибка вылазит.

>так тут ещё и его интерпретатор на жабе

http://ola-bini.blogspot.com/2007/04/on-activerecord-jdbc-performance.html

По теме: руби гофно, anonymouslang наше все.

>Одному мне кажется, что жаба, сцуко, зохавывает мир?

Не! Только половину. Остальную захватит .net...

хорошая новость, но я больше жду Ruby 2.0

Реально всё по другому:
1. Запускается Ruby компилятор и компилирует Ruby скрипт в байт код для Java.
2. Запускается JIT компилятор и компилирует Java байт код в машинные коды (при этом он учитывает какой процессор и сколько памяти, так что результат компиляции работает быстрее, чем C\C++ приложение откомпилирование с параметрами _по-умолчанию_).
3. Откомпилированные машинные коды (считайте asm) запускаются уже на процессоре.

Компиляция как мы понимаем кешируется и при следующем запуске будут запущены уже машинные коды.
В результате JRuby получается быстрее, чем интерпретатора Ruby (который конечно же хуже JIT компилятора Java).

ХА! Вставка ста записей из двух полей это показатель. Ну уморил. Это даже не тест, а предварительное впечетление.

>Реально всё по другому:

А ты откуда это знаешь?

>>Кстати, все знают, что Java быстрее, чем C/C++. ;)

>Это ты пошутил? Да?

Какие шутки? http://www.kano.net/javabench/data

Это была Java 1.4.2, а сегодня актуальна Java 1.6 с оптимизированным сборщиком мусора и инлайнером кода в JIT.

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

если забыть про кеширование, получается

получить параметры для проги, собрать Makefile скомпилировать прогу запустить отдать отдать рузультат

тоесть вся надежда на кеширование? стоит учитывать что сам механизм кеширования тоже кушать любит а если чтото изменяется в этой схеме то опять перекомпиляция? опять кеширование?

лишь бы делом не заниматься, вот к чему я

Ишь ты, любопытно.. Надо глянуть.. ;-)

>ога, ну ты правильно подметил, скушай сникерс. он питателен. еще на дату поста глянь

Ребята о чем вы тут спорите. У меня на машине стоит и Java 1.6 и Qt. Я запускал примеры и там и там. А на работе клиент-банк на жабе. Глазам я своим пока больше верю чем, гистогармма из инета от заинтересованных лиц. А для особо упертых предлагаю написать компилятор математических формул, на жабе и на плюсах, а потом запустить расчет точках так в 100 000, на такой задаче плюсы порвут жабу как тузик тряпку(ИМХО). Дело в том что я как раз имею опыт написания таких прог. А примеры с базами данных не очень корректны, т.к. там очень много факторов посторонних, вплоть до расположения звезд в момент теста.

Добавлю..сборщик мусора как раз и помешает жабе.

ждем javascript на jruby :) (жруби или как там читается:)

Сходите по этой ссылке http://www.w3sys.com/pages.meta/benchmarks.html Посмеётесь.

сходил. причем тут к теме о jruby cpp vs java? если вы про свой ответ "java быстрее cpp", я его не комментировал. запишитесь к окулисту

Эти тесты нужно прогонять не на g++, а на Visual C++. Тогда можно будет смеятся, как Ява "быстрее" С++.

>я его не комментировал. запишитесь к окулисту

Ушел к окулисту ... Скоро буду.

угу, и посмотрите на пожирание памяти,
потом уменьшаем hash до 10 (хитрожопый блин тест) и продолжаем смеятся,
вот правдивый тест - http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=gpp&...
c байткодами еще может тягаться, но достали "доказательства" что жаба скростная типа C++ (т.е. мы почти как С!)

А где флейм "питона vs руби"?

Я уже затарился поп-корном )

> А для особо упертых предлагаю написать компилятор математических формул, на жабе и на плюсах, а потом запустить расчет точках так в 100 000, на такой задаче плюсы порвут жабу как тузик тряпку(ИМХО). Дело в том что я как раз имею опыт написания таких прог.

Дело в том, что жаба создана не для таких задач.

> А примеры с базами данных не очень корректны

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

Java с дотнетом не должна быть быстрее c++ чисто теоретически. Все зависит от стиля программирования. В Java просто существуют готовые классы и бибиотеки, которые рассчитаны на определенный способ использования и при правильном использовании обеспечивают производительность, сопоставимую с c++. А на c++ можно не продумать структуру программы и написать так, что будет меденнее работать, чем на java ;)

Хотя нужно учитывать, что в java используются ускоряющие фичи оптимизируемое выполнение байт-кода, распараллеливание при выполнении и т.д.

Там есть как я понимаю компилятор в байткод (jrubyc). Так что называть его интерпретатором не корректно, если я не ошибаюсь.

Для танкистов: JRuby придуман чтобы использовать jvm из более человеческого языка. А не чтобы было быстро (все равно все съедят БД и передача данных по сети)

> А где флейм "питона vs руби"?

так пока не будет следующего питона (как там он называется..) и ruby2 -- флеймить не о чем.

кстати, потрогал ruby 1.9 давеча, куда байт-код компилятор/vm уже добавили, и ничего так, шустренько. на моей задаче, где много-много ввода/вывода и оччень много регэкспов, а на долю собственно руби остаются циклы и работа с хешами -- в три раза шустрее бегает чем 1.8. притом что ничего в плане совместимости не поломалось.

> Одному мне кажется, что жаба, сцуко, зохавывает мир?

Последние 10 лет провели в криокамере или программируя на Дельфи? Она его уже проглотила, теперь отрыгивает для .НЕТ то, что осталось.

> А где флейм "питона vs руби"?А где флейм "питона vs руби"?

А не будет, поскольку JPython помер. Должен быть флейм JRuby vs Groovy, вотъ.

> А где флейм "питона vs руби"?

> Я уже затарился поп-корном )

А чё тут флеймить? Питон с таким барахлом не сравнивается. Питонщики уверенно програмят пока рубисты новых фьючерсов ждут. Только через пару лет можно будет смотреть до чего руби дойдёт.

не понимаю ценность Руби

тот же питон, только немного хуже по нескольким параметрам =/

П'цаны, я не знаю, о какой мега-яве вы тут говорите, но та, которая у всех - работает медленнее среднего приложения на C/С++. Велкам, что называется, ту зе риал ворлд: http://shootout.alioth.debian.org/

Ну, и тест на базах данных - тоже возможен, но только в ряду *других* тестов. И то, что я вижу на шутауте - вполне укладывается в мою картину мира - то есть, возможны ситуации, когда ява быстрее C, а, скажем, питон быстрее явы и плюсов (зуб даю: http://shootout.alioth.debian.org/gp4/benchmark.php?test=chameneos&lang=all ), но среди общей массы тестов таких наберётся от силы пара.

> А не будет, поскольку JPython помер.

Зато ЖелезноЗмей шеволится :-). Да и Буу как настоящий. Если бы последний не позиционировался исключительно в CLR, интересный зверек бы вышел. С другой стороны, вне CLR и питон себя неплохо чувствует.

> 2. Запускается JIT компилятор и компилирует Java байт код в машинные коды (при этом он учитывает какой процессор и сколько памяти, так что результат компиляции работает быстрее, чем C\C++ приложение откомпилирование с параметрами _по-умолчанию_).

Вот потому и имеем маразматические тексты, явно писанные вендузятнегами типа тебя, и не менее маразматичсескую производительность программ, что особо одарённые личности типа тебя же не осилили параметров отличных от "-pg3 -O0", которые идут по умолчанию. А потом ещё эти самые особо продвинутые типа тебя радостно и публично мастурби^W пишут, что мол жабка быстрей всего и вся.

>Вот потому и имеем маразматические тексты, явно писанные вендузятнегами типа тебя, и не менее маразматичсескую производительность программ, что особо одарённые личности типа тебя же не осилили параметров отличных от "-pg3 -O0", которые идут по умолчанию. А потом ещё эти самые особо продвинутые типа тебя радостно и публично мастурби^W пишут, что мол жабка быстрей всего и вся.

Мальчик, прочитай что такое HotSpot (http://en.wikipedia.org/wiki/HotSpot) и почему его нельзя использовать в языках типа С++.

Потом прочитай что такое "escape analysis" и "lock elimination".

Потом подумай почему в Java динамическое выделение памяти сильно быстрее, чем в С++.

А потом только открывай рот.

>Потом подумай почему в Java динамическое выделение памяти сильно быстрее, чем в С++.

Только меня одного утомили Java теоретики ???

пример один С.
#include "stdio.h"
#include <stdlib.h>
#include <sys/time.h>
#include <string.h>

#define elap(t0,t1) \
  ((1000*t1.tv_sec+0.001*t1.tv_usec) - (1000*t0.tv_sec+0.001*t0.tv_usec))

#define SIZE 1000000

int main( void ) {
  struct timeval tv0,tv1;
  double timeOut1, timeOut2;
  gettimeofday(&tv0,0);

  void *pTT = malloc( SIZE );

  gettimeofday(&tv1,0);
  timeOut1 = elap(tv0,tv1);

  memset(pTT, 0, SIZE );

  gettimeofday(&tv0, 0);
  timeOut2 = elap(tv1, tv0);

  printf("time1=%6.2fms\ntime2=%6.2fms\n", timeOut1, timeOut2);
  return 0;
}

Без оптимизаций.
time1=  0.04ms
time2=  1.21ms

Через -O2
time1=  0.04ms
time2=  0.98ms

Java
public class Test {
  private final static int OBJECT_SHELL_SIZE = 8;
  private final static int size = 1000000;

  public static void main(String[] args) {

    final long time = System.currentTimeMillis();
    final Object[] objects = new Object[size / OBJECT_SHELL_SIZE];
    System.out.println("time = " + (System.currentTimeMillis() - time)/1000.0 );

  }
}
времена
time = 0.0020.

И то и другое примерно типично для C и Java кода. Платформа 32 битная поэтому OBJECT в 1.4 java занимает 8 байт.

da, nuzhno vse na Hardware Lisp-Machines zapuskat'. Net prosloek. :-)

>Потом подумай почему в Java динамическое выделение памяти сильно быстрее, чем в С++.

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

> И ещё замечание теоретик. в с++ выделение памяти очень эффективным заточенным под один проц, под много процов, выделять сразу и т.п. оптимизазия под задачу. В Java ты как обычно. Поэтому совет дня - займись делом, а не теоретически газофицируй лужи.

> можно сделать

можно много чего сделать, но почему не сделано? ;) короче, фонатег. Смирись - цепепе то ещё говнище.

> Мальчик, прочитай что такое HotSpot
> (http://en.wikipedia.org/wiki/HotSpot)
> и почему его нельзя использовать в языках типа С++.
> Потом прочитай что такое "escape analysis" и "lock elimination".
> Потом подумай почему в Java динамическое выделение памяти
> сильно быстрее, чем в С++.
> А потом только открывай рот.

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

Для подобных феерических лузиров поясню: в курсе чем "adaptive
optimization designed to improve performance" отличается от "adaptive
optimization designed to achieve highest/outstanding performance"?
Видать такие как ты в своё время не осилили корректно прочитать (а те
бездари, кто и аглицкого не знает - ещё и кривым переводом загрузились),
и к настоящему времени мутировали в непрерывно апгрейдящих свои
газификаторные агрегаты неразумных человекоподобных жабофилов.

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

>И то и другое примерно типично для C и Java кода. Платформа 32 битная поэтому OBJECT в 1.4 java занимает 8 байт.

Смеешься?

Во-первых, это нифига не типичный подход - ты распределеяешь один большой массив null'ов. Естественно, он попадет в отдельную кучу для больших объектов - она работает в точности как и обычная С++-ная куча.

Во-вторых, в этом тесте HotSpot просто не успеет включится - классы будет работать в режиме интерпретации.

>И ещё замечание теоретик. в с++ выделение памяти можно сделать очень эффективным заточенным под один проц, под много процов, выделять сразу и т.п. оптимизазия под задачу.

Еще одно замечение, теоретик. В SUN JVM память выделяется из thread-local арен. Выделение памяти на БУКВАЛЬНО состоит из двух машинных команд (two-instructions allocator на Sparc V8, на x86 еще пара команд требуется) - смещение указателя на конец кучи. Никакой лишней синхронизации.

Это НЕВОЗМОЖНО сделать в С++, так как требует уплотняющего garbage collector'а.

Кстати, если речь зашла про многопроцессорность - то в Sun JVM 1.6 реализован спекулятивный lock elision, использующий механизм HotSpot. В С++, опять же, невозможно.

Да, и прежде чем брызгать соплями - я профессиональный программист на С/С++, контрибьютор в Boost, у меня на моем счету три встроенных девайса с Линуксом на борту. А еще я знаю детали функционирования JVM в мельчайших подробностях.

> профессиональный программист на С/С++, контрибьютор в Boost

Вкупе с "оптимизациями" и "скоростью" - "убило и порвало труп" (ТМ)

Напоминает презентации с тестами АМД-шных процессоров, писанные для манагеров, что мол "наш новый процессор будет в 2 раза быстрее равночастотной корки дуба №2 согласно по тестам", а где-то в конце дописка, что тесты - по скорости чтения из памяти. Хрен ли толку с того, дядя-профессионал?

>Эти тесты нужно прогонять не на g++, а на Visual C++. Тогда можно будет смеятся, как Ява "быстрее" С++.

Бугага. Код, сгенеренный компилятором от микрософт гораздо быстрее кода, сгенеренного g++. Тут MS C++ compiler рвет gcc как тузик грелку, лучше него код строит только оптимизирующий компилятор Intel. Cреди этих трех, gcc - явный аутсайдер, по крайней мере по скорости выполнения откомпилированных им программ

И часто ты, сынок, получаешь нативные ELF'ы при помощи "компелятора" (ТМ) от майкрософт? Или благодаря бескомпромиссной оптимизации faith-блоков мозга ты и почитать тесты не осилил, где явно показывается, что MSVC сливает __вообще всем__, а gcc по интегральным характеристикам чуть хуже icc, кое-где его рвёт, кое где отстаёт, но в целом, учитывая склонность icc время от времени глючить, генерить левый код, залоченностью на конкретную архитектуру, а также - сегфолититься вкупе с закрытостью, то ИМХО gcc ещё и вперёд капитально вырывается.

>Напоминает презентации с тестами АМД-шных процессоров, писанные для манагеров, что мол "наш новый процессор будет в 2 раза быстрее равночастотной корки дуба №2 согласно по тестам", а где-то в конце дописка, что тесты - по скорости чтения из памяти. Хрен ли толку с того, дядя-профессионал?

Я разве утверждаю, что Java ВСЕГДА быстрее C++? Нет, конечно. Сравнима ли Java по скорости с С++ - да, без сомнения.

Я умею писать программы на С++, которые пока что работают быстрее аналогичных на Java. Однако, это требует огромного внимания, аккуратности и высокой квалификации прораммистов. Что окупается только в редких случаях.

Поэтому при выборе между C++ и Java/.NET в большинстве случаев скоро будут выбирать .NET/Java. Так как лишние 15-20% скорости нафиг никому не сдались в какой-нибудь бухгалтерской программе по учету пирожков.

Да, а по поводу тормозных GUI - есть SWT, который используется в Eclipse. Там все контролы - нативные, тормозить нечему.