Парни из Ричмонда разработали язык Fan на замену C# и Java

>Groovy

Надо будет отбенчить. Но был тормозной :)

>(+invokedynamic)?

Вот когда 1.7 (его в 1.7 ввели, или нет ещё?) будет на каждой машине - тогда будет другое дело... Хотя, опять же, что у него со скоростью? Не щупал...

о, так там уже есть аллокатор. Я гоню.

>Да, что-то тут не чисто. Я имею ввиду это:

Блин. Каждый раз одно и то же :) Этот тест - не на вычисление числа Фибоначчи. Поверь, для этого есть несравнимо более быстрые способы :D

Это тест на генерацию объектов и простейшие операции над ними.

Просто в современных объектных программных продуктах такого рода задачи на каждом шагу.

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

>Это ведь дополнительный системный вызов (new)

В нём и суть. Это тест на скорость жонглирования объектами.

о, я понял, спасибо. ТАк что, выходит ява впереди планеты всей?

> Единственная проблема жабы и дотнета - долгий старт. Вот об этом да, имеет смысл говорить.

Причём у моно он в три раза быстрее, чем у явы (тест на консольный хелло ворлд).

>Это тест на генерацию объектов и простейшие операции над ними.

Объекты генерируются и операции производятся. То, что объекты не в куче ничего не значит - они всё равно полноценные.

> А чем Qt хуже JVM и дотнета?

Крестовые исходники сложнее собирать, они несколько хуже портабельны. Плюс кутешный сборщик мусора довольно примитивный, память будет фрагментироваться и помаленьку течь.

Короче, для всякой десктопной фигни сойдёт, а на сервере и в ынтерпрайзе ему делать нечего.

> Причём у моно он в три раза быстрее, чем у явы (тест на консольный хелло ворлд).

Ну а чё вы хотите. Работа над ошибками. Ну и ваще хейльсберг писал шустрые среды разработки пока гослинг ещё бороду отращивал.

> Короче, для всякой десктопной фигни сойдёт, а на сервере и в ынтерпрайзе ему делать нечего.

А на Qt кто-то собирался писать серверную часть чего-то? >_<

> кутешный сборщик мусора

O_o Первый раз слышу про него. Можно подробнее?

> А на Qt кто-то собирался писать серверную часть чего-то? >_<

Слышал про каких-то чудаков, которые хотели вместо STL юзать QtCore.

>Слышал про каких-то чудаков, которые хотели вместо STL юзать QtCore.

А чем Qt хуже STL?

>ТАк что, выходит ява впереди планеты всей?

По этому тесту и на моей машине - получается да.

Причём у моно он в три раза быстрее, чем у явы (тест на консольный хелло ворлд).

$ time java Hello
Hello world!

real	0m1.418s
user	0m0.033s
sys	0m0.057s

$ time java Hello
Hello world!

real	0m0.116s
user	0m0.056s
sys	0m0.017s

$ time mono hello.exe 
Hello world!

real	0m1.857s
user	0m0.031s
sys	0m0.020s

$ time mono hello.exe 
Hello world!

real	0m0.079s
user	0m0.034s
sys	0m0.003s

В серии тестов для «hello world» результат воспроизводим. У mono немного более долгий холодный стартап и немного более быстрый тёплый. В целом - паритет.

>Объекты генерируются и операции производятся.

Поэтому Си++ с объектами на стеке у меня в тесте и присутствует :)

>То, что объекты не в куче ничего не значит - они всё равно полноценные.

Условно полноценные. Их нельзя передать никуда наружу из метода.

>Их нельзя передать никуда наружу из метода.

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

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

Я имею в виду передачу по ссылке. Передавать объекты по значению - это тот ещё мазохизм.

А по ссылке:

static Fib* getFib(int n)
{
    Fib x = Fib(n);
    return &x;
}

Что тебе на нечто подобное скажет компилятор? :) А что будет во время исполнения?

гм-гм.. ну по идее дело всё в том, что ты можешь попытаться сделать что-то вроде такого

class А {
  public:
    A() {
      echo "hello";//Да, ето юмор..
    }
}

class B {
  А * getA() {
    А a=А();
    return &a; //типо оптимизация, чтобы объект не копировался
  }
}

Ну и ясно-красно такой код работать правильно не будет, потому что объект находится в области видимости метода getA() и будет уничтожен, так как истечёт его время жизни. Если же передавать без &, то передаётся не сам объект, а его копия. Что, согласитесь, не одно и то же.

А вот собственно и крон.. я немного опоздал :)

я немного опоздал :)

Ты раньше отписал, только пока делал репостинг с исправленным сообщением, я тоже успел ответить :)

Но по сути - одно и то же написали.

...

Я не поленился забенчить копирование:

#include <stdio.h>

class Fib
{
  private:
     int _value;

  public:
    Fib(int n) { _value = n; }

    int value()
    {
        if(_value <= 2)
            return 1;

        Fib f1 = getFib(_value - 1);
        Fib f2 = getFib(_value - 2);

        return f1.value() + f2.value();
    }

    static Fib getFib(int n)
    {
        Fib x = Fib(n);
        return x;
    }
};

int main()
{
    for(int i=0; i<5; i++)
    {
        Fib x = Fib::getFib(40);
        printf("n=%d\n", x.value());
    }
    return 0;
}

Вышло 3,3 сек. на цикл. В семь раз медленнее чисто стекового варианта, на одной скорости с boost-вариантом. Медленнее, чем на Java с созданием объектов в куче.

Да, забыл отметить, что такое падение производительности на столь примитивном объекте. А если что-то будет более реальное, раз эдак, в 50 сложнее? :)

А вот так вот быстрее выходит. Правда какова у нас погрешность?

Fib getFib(n) { return Fib(n); }

И ещё, ты -02 юзаешь ведь?

Возможно, я что-то не догоняю... Зачем городить огород с созданием новых экземпляров объекта и уж тем более с использованием кучи, когда прошлые вычисления можно запомнить, и они общие для всех экземпляров класса?
И чем вариант со стеком на с++ будет отличаться от варианта на Ruby в таком виде:

==================================


class Fib
private
@@hashValue=Hash.new(0)
@@hashValue[0] = @@hashValue[1] = @@hashValue[2] = 1
public
def self.value(n)
if ( @@hashValue[n]==0 )
@@hashValue[n] = Fib.value(n - 1) + Fib.value(n - 2)
end
return @@hashValue[n]
end
end

print Fib.value(240)

==================================


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

Для меня преимущества Руби в данном случае в поддержке больших целых чисел из коробки (использую 1.9.1), на С++ вызов с аргументом 240 можно поддерживать только с применением сторонней библиотеки

для небольших аргументов тот же подход допустим, я думаю, в любых языках, поскольку информация о содержимом Fib(x) - глобальна, то использовать можно любое глобальное хранилище, вплоть до глобальной переменной или ячейки глобального хэша (если параллелизации и безопасности важны, то тут уже не все так гладко, но опять же - тогда использовать синглтон)

Т.е. я хочу сказать, что задача для бенча решается неверным способом, ненатуральным, возможно потому и java -server работает быстро
:)

/waveM

смысл этих тестов - поглядеть, насколько быстро язык оперирует объектами, используя основыне операции типа создать/удалить.. а не посчитать число фибоначи.

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

явовский отсюда

http://balancer.ru/2008/11/24/post-1736478.html

time java -server Fib

компилял твой ++ код, только использовал return Fib(n), вместо return x, компилял так:

g++ -O2 -march=native -o 1 1.cpp

запускал

time ./1

мои результаты

java: 1:51 (111 сек), 100 циклов = 1,11 сек на цикл

c++: 1:27 (87 сек), 100 циклов = 0,87 сек на цикл

То есть си++ быстрее...

Дык! о том и речь, зачем останавливаться на использовании кучи? давайте тогда и в базу писать каждый раз, да еще через веб, чего уж там...

Оперировать объектами можно ведь тоже по-разному? можно создавать.удалять, но без надобности, только что это показывает?
То, что в одних языках это единственно возможный способ? Ну так в других может быть не все так плохо?

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


/waveM

ЗЫ: я вообще влез в эту свалку исключительно потому что тест показал несостоятельность Руби, а я к нему неровно дышу последнее время, потому и привел пример дизайна, позволяющего ему догнать "передовые" языки

мне руби тоже нравится, но я всё таки не согласен.

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

Предложите тест который оперировал бы объектами и был бы достаточно трудоёмким для того чтобы делать замеры и достаточно простым, чтобы не писать его несколько часов для переноса на другой язык.

Это шутка что-ли? У меня джава с 6-ой версии, если не с середины 5-ой, Swing-овые приложение рисует через GTK. По крайней мере, для моего самописного приложения.

адаптировал диспечер памяти отсюда https://www.ibm.com/developerworks/ru/edu/au-memorymanager/section7.html

2-2.5 раза медленне чем java|c++ stack

код

#include <stdio.h>
#include <sys/types.h>
#include <iostream>

#define POOLSIZE 100

class Fib
{
  private:
     unsigned int _value;

  public:
    Fib(unsigned int n) { _value = n; }


    unsigned int value()
    {
        if(_value <= 2)
            return 1;

        Fib *f1 = new Fib(_value - 1);
        Fib *f2 = new Fib(_value - 2);
	unsigned int v = f1->value() + f2->value();
	delete f1;
	delete f2;

        return v;
    }
    
    void* operator new (size_t size);
    void operator delete (void* pointerToDelete);
};

class MemoryManager {
  struct FreeStore {
     FreeStore *next;
  }; 
  FreeStore* freeStoreHead;
  public:
    MemoryManager () {
      freeStoreHead = 0;
      expandPoolSize ();
    }
    virtual ~MemoryManager () { 
      cleanUp ();
    }

    inline void* allocate(size_t size) {
      if (0 == freeStoreHead)
        expandPoolSize ();

      FreeStore* head = freeStoreHead;
      freeStoreHead = head->next;
      return head;
    }

    inline void free(void* deleted) {
      FreeStore* head = static_cast <FreeStore*> (deleted);
      head->next = freeStoreHead;
      freeStoreHead = head;
    }


    void expandPoolSize () {
      size_t size = (sizeof(Fib) > sizeof(FreeStore*)) ? sizeof(Fib) : sizeof(FreeStore*);
      FreeStore* head = reinterpret_cast <FreeStore*> (new char[size]);
      freeStoreHead = head;

      for (unsigned int i = 0; i < POOLSIZE; i++) {
        head->next = reinterpret_cast <FreeStore*> (new char [size]);
        head = head->next;
      }

      head->next = 0;
    }

    void cleanUp() {
      FreeStore* nextPtr = freeStoreHead;
      for (; nextPtr; nextPtr = freeStoreHead) {
        freeStoreHead = freeStoreHead->next;
        delete [] nextPtr; // запомните, это был числовой массив
      }
    }
};

MemoryManager gMM;

void* Fib::operator new (size_t size) {
  return gMM.allocate(size);
}

void Fib::operator delete (void* pointerToDelete) {
  gMM.free(pointerToDelete);
}


int main()
{
    for(unsigned int i=0; i<5; i++)
    {
        Fib * x = new Fib(40);
        printf("n=%d\n", x->value());
        delete x;
    }
    return 0;
}

Блин ё моё. А я ожидал ускорения.

операторы new, delete - практически не занимают времени (3 присваивания). Вывод - дело не в системных вызовах....

скорее всего дело в том, что в таком варианте объекты располагаются в оперативной памяти, а в стековом варианте - в кеше процессора. Поэтому и ускорение.

Что делает ява - объяснить затрудняюсь. Но если она тоже размещает данные как-то в кеше процессора, то тест получается сильно искусственный, потому что в реальной жизни объекты, по большей части, храняться в ОЗУ. => нужен другой тест.

ну и ещё один вывод - классики правы: писать программы надо как можно проще. Предварительная оптимизация - зло. На сём удаляюсь поспать пару часов.

Кто-то решил убить яву? Уже вторая новость за последнее время.

> А чем Qt хуже STL?

Да ничем, просто несколько эмм... необычно. Ну и кто-то может крикнуть про то, что зачем тащить лишние зависимости.

Но если вспомнить про то, что оно copy-on-write и полностью совместимо вплоть до алгоритмов из STL - перевес на стороне троллотулкита.

> код на яп fun -> fcode -> IL -> x86 -> внутренни код процессора

И всё в рантайме %(

А я уж подумал, что в одном проекте можно будет задействовать обе системы :)

>в легкой и непринужденной, веселой (fun) манере.

эекстелр тыой яебанейу коту11..?

> Но вижу прекрасные шустрые нативные GTK-окошки. Запускаю top - а там java висит. Весьма порадовало :)

Вот!!! Теперь я знаю, что такое "Ъ". Эх... Шрефт маленький... Тем кто скрестил GTK с Жабой надо памятник при жизни поставить, и Нобелевскую... Каждому!

>Жалко, что стартует долго, по 3-5 секунд. Но сабж - самое интересное в этой области, что мне попадалось за последние пару лет. Буду играться :)

это ещё не жалко. ты забыл про опенофис. он стартует 20 секунд.

>опенофис. он стартует 20 секунд

Уже давно нет.

>А вот так вот быстрее выходит.

Ок, проверю ещё.

>Правда какова у нас погрешность?

Ну, в большой серии два знака точно верных. Правда, для тестов по 10 минут я по 1-2 теста всего делаю. Но кортоткие - по 10 циклов за тест и тестов несколько.

>И ещё, ты -02 юзаешь ведь?

-O3

Без оптимизации результаты у GCC кошмарные :)

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

Поэтому я выше и уточнял, что эти тесты имеют смысл только на моей машине. На разных машинах результаты у всех тестов разные, вплоть до изменения пропорций.

>только использовал return Fib(n), вместо return x

А, может, и в этом дело. Для оценки, всё же, нужно одни и те же тесты сравнивать :) Чуть позже (только проснулся) проверю вариант с возвратом значения без использования переменной.

Ну и - что у тебя за архитектура? М.б. GCC под неё лучше оптимизирует. У меня P4 Prescott.

...

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

>Это шутка что-ли? У меня джава с 6-ой версии, если не с середины 5-ой, Swing-овые приложение рисует через GTK.

У меня ещё ни одного приложения нет, которе бы _настолько же_ было индентично системному GTK. Даже Eclipse имеет некоторые отличия в виджетах :) А основная масса - иногда даже до своего рендеринга шрифтов доходит (и речь не об swt - там вообще ужас).

>Но если она тоже размещает данные как-то в кеше процессора, то тест получается сильно искусственный, потому что в реальной жизни объекты, по большей части, храняться в ОЗУ. => нужен другой тест.

Ну, можно тупо вписать пару десятко переменных и пару десятков геттеров-сеттеров. ИМХО, будет достаточно близко к типовому объекту :)

>А я уж подумал, что в одном проекте можно будет задействовать обе системы :)

Я пока не понял вообще, можно ли её под тем же mono запустить. Создалось впечатление, что fan поставляется в варианте, когда под Linux он работает в Java, а под Windows - в .NET :)

На самом деле меня куда больше, чем GCC и Java волнует Python.

По сравнению с предыдущими тестами, что 2.5, что 2.6 показывают просто чудовищный провал по скорости и, почему-то, неработоспособность Psyco. Я в недоумении. И на систему не свалишь. Не смотря на общее некоторое снижение скорости по сравнению со старой (там было одно ядро на 1860МГц, а тут - гипертрейдинг из 3,2ГГц), Java и Ruby показали лучшие, чем раньше. То ли в Gentoo Python настолько хуже собирается, чем в Ubuntu, то ли за прошедший год скорость настолько деградировала и Psyco сломали :)

Привет. Ты неправильно тестируешь яву. Память выделяется в young-gen у тебя, простым инкрементом. До сборки мусора просто не доходит, думаю. Попробуй заставить свой тест поработать подольше, размеры кучи (особенно young-gen) поставь поменьше, напр. -XX:NewSize=самое-маленькое-число-которое-оно-дастm, добавь опции -XX:+PrintGC или -XX:+PrintGCDetails, и дождись, пока GC запустится, р-т будет другой.

Так Эклипс и не на Swing-e написан же? А на сколько оно идентично - не проверял, но на мой взгляд разницы нет.

> O_o Первый раз слышу про него. Можно подробнее?

О, я-то думал хоть счётчик ссылок есть как в GObject. Всё ещё хуже, да...

Парни из редмонда спиздили haxe. Один к одному с идеей компиляции в другие языки.