Вышли новые версии оригинальных компиляторов языков D2 и D1

Блог известного на StackOverflow товарища Jon Harrop. Одно из последних сообщений. Какая-то «летающая лягушка»: http://flyingfrogblog.blogspot.com. А именно сообщение Boost's shared_ptr up to 10× slower than OCaml's garbage collection. Товарищ постоянно что-то там измеряет, а потом докладывается в своем блоге.

Можно перефразировать с некоторой натяжкой твои слова: «в реальном приложении GC практически не влияет на скорость». Вот, .NET и Java, сволочи, долго стартуют из-за байт-кода. Это чувствуется. Но тот же Ocaml умеет компилировать в нативный бинарник, у которого очень быстрый старт. В общем, не все так просто.

Еще раз повторяю: какое GC имеет отношение к обращению (чтение/запись) к памяти ?!

Это ты мне скажи. Твоя же мысль была, что стоит ввести в C++ GC и он тормознутым станет как все эти ваши интерпретаторы. А если GC на производительность не влиет, то из чего ты споришь?

Скорости работы реализаций заданных алгоритмов на различных ЯП.

Это не то. Мы же конкретно про доступ к памяти, а там много чего влияет.

Не согласен - приведи пример других бенчмарков или проведи свои.

[ortfero@u210 ~]$ cat test.cxx
#include <iostream>
#include <vector>

int main( int, char ** )
{
    static const int limit = 512 * 1024 * 1024;

    try
    {
        typedef std::vector< char > bytes;
        bytes array( limit );

        for( bytes::iterator it = array.begin(); it != array.end(); ++it )
            *it = -1;
    }
    catch( const std::bad_alloc & )
    {
        std::cout << "can`t allocate array" << std::endl;
    }

    return 0;
}
[ortfero@u210 ~]$ cat Test.java
public class Test
{

    public static void main(String[] args) {

        final int LIMIT = 512 * 1024 * 1024;

        try {        
            byte[] array = new byte[LIMIT];

            for (int i = 0; i < LIMIT; i++)
                array[i] = -1;
        } catch (OutOfMemoryError e) {
            System.out.println( "can`t allocate memory" );
        }
    }

}
[ortfero@u210 ~]$ cat Test.cs
using System;

public class Test
{
    public static unsafe void Main()
    {
        const int Limit = 512 * 1024 * 1024;

        byte[] array = new byte[Limit];
        fixed (byte *begin = array)
        {
            byte *end = begin + Limit;
            for (byte *it = begin; it != end; ++it )
                *it = 0xFF;
        }
    }
}
[ortfero@u210 ~]$ g++ -O3 test.cxx
[ortfero@u210 ~]$ javac Test.java
[ortfero@u210 ~]$ mcs /unsafe Test.cs
[ortfero@u210 ~]$ time ./a.out

real	0m1.942s
user	0m1.077s
sys	0m0.703s
[ortfero@u210 ~]$ time java -Xmx1024m -server Test

real	0m1.850s
user	0m0.967s
sys	0m0.767s
[ortfero@u210 ~]$ time mono Test.exe

real	0m1.981s
user	0m1.050s
sys	0m0.770s
[ortfero@u210 ~]$ 

Это ты мне скажи. Твоя же мысль была, что стоит ввести в C++ GC и он тормознутым станет как все эти ваши интерпретаторы. А если GC на производительность не влиет, то из чего ты споришь?

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

По поводу твоих бенчмарков: ты действительно решил, что меня обломает повторить их у себя на компе ???

$ time java -Xmx1024m -server Test

real	0m1.679s
user	0m0.544s
sys	0m0.426s
$ g++ Test.cpp -O3 -o Test
$ time ./Test

real	0m0.813s
user	0m0.553s
sys	0m0.240s

В два раза, не находишь?

Идем дальше, с какого перепугу ты схватился за std::vector и оптимизировал O3, а не O4??? Пишем аналогичный тест, но на нативных массивах и с О4:

$ cat Alt.cpp 
#include <stdio.h>

int main()
{
    static const int limit = 256 * 1024 * 1024;
    try
    {
        char *array = new char[limit];
        for(int it = 0; it < limit; ++it )
            array[it] = -1;
    }
    catch(...)
    {
        printf("can`t allocate array\n");
    }
    return 0;
}

$ g++ Alt.cpp -O4 -o Alt
$ time ./Alt

real	0m0.416s
user	0m0.109s
sys	0m0.295s

Вопросы?

Примечание: я опустил кол-во выделяемой памяти до 256 МБ, чтоб комп не уходил в своп.

> оптимизировал O3, а не O4???

Как минмум потому, что не во всех компиляторах есть -O4 %) Не говоря уже о том, что и O3, и O4 могут включать опасные оптимизации.

$ g++ Alt.cpp -O3 -o Alt
$ time ./Alt

real	0m0.414s
user	0m0.114s
sys	0m0.282s
$ g++ Alt.cpp -O2 -o Alt
$ time ./Alt


real	0m0.631s
user	0m0.339s
sys	0m0.289s
$ g++ Alt.cpp -O1 -o Alt
$ time ./Alt

real	0m0.684s
user	0m0.384s
sys	0m0.274s

При всем этом, О1 даже совместима с ассемблерными вставками. Да и опасность эта сильно преувеличена. За всю жизнь видел только один пример фэйла из-за оптимизации. Его легко обошли, использовав вместо -О3 выборочные ключи оптимизаций.

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

Ну так ты им говоришь, что все будет тормозить, если GC ввести, потому что «айдишники», а у меня спрашиваешь, какое GC отношение к чтению/записи в память имеет. Раздвоение личности?

Идем дальше, с какого перепугу ты схватился за std::vector

Потому что это стандартная библиотека и потому что на обычных массивах люди часто делают ошибки, подобные твоим. Их потом очень неприятно выискивать в коде. Фактически ты пруф привел, что GC в C++ крайне необходим.

C -O4 нет особой разницы:

[ortfero@u210 ~]$ g++ -O4 test.cxx
[ortfero@u210 ~]$ time ./a.out

real	0m1.923s
user	0m1.107s
sys	0m0.703s

Вопросы?

Зачем для 256М время привел?

> не во всех компиляторах есть -O4 %)

Давайте не будем упоминать недокомпиляторы, и тогда я не буду приводить примеры недо-JVM.

Ну так ты им говоришь, что все будет тормозить, если GC ввести...

Чувак, у тебя паранойя? Чего ты ко мне с этим GC прицепился?

а у меня спрашиваешь, какое GC отношение к чтению/записи в память имеет. Раздвоение личности?

Нет, наводящий вопрос. Чтоб ты подумал и понял, что GC к нашему спору никакого отношения не имеет.

Потому что это стандартная библиотека

В Java тоже хватает стандартных контейнеров, которые тормознее нативных массивов.

и потому что на обычных массивах люди часто делают ошибки

Кто им доктор? Я ж говорил, у криворуких кодеров поделки на яве работают лучше.

подобные твоим.

Где у меня там ошибка???

Зачем для 256М время привел?

Чтоб ноут в своп не уходил. Но если ты такой упрямый, то так и быть, использую более мощный комп:

$ javac Test.java 
$ time java -Xmx1024m -server Test

real	0m1.605s
user	0m0.360s
sys	0m0.160s
$ g++ Test.cpp -O3 -o Test
$ time ./Test 

real	0m0.353s
user	0m0.170s
sys	0m0.180s
$ g++ Alt.cpp -O3 -o Alt
$ time ./Alt

real	0m0.241s
user	0m0.020s
sys	0m0.210s

>Кто им доктор? Я ж говорил, у криворуких кодеров поделки на яве работают лучше.

Где у меня там ошибка???

Ты в трех строчках утечку не видишь?

Чтоб ноут в своп не уходил. Но если ты такой упрямый, то так и быть, использую более мощный комп

Перешел на более мощный комп и время выполнения C++ программы уменьшилось в разу, а время выполнения Java осталось тем же. У тебя все программы на Java на всех компах выполняются с этим временем?

Опять отдельно для 256М цифра. Какой в ней смысл? Мы же меряем у C++ и Java.

> Ты в трех строчках утечку не видишь?

С умным видом намекаешь на free()/delete перед завершением программы. Не просто толсто, жирно, я б сказал. Или это опять паранойя сказывается?

Перешел на более мощный комп и время выполнения C++ программы уменьшилось в разу, а время выполнения Java осталось тем же. У тебя все программы на Java на всех компах выполняются с этим временем?

Да уж, плохой запуск вышел, позапускал несколько раз - время колебалось около 460мсек.

Опять отдельно для 256М цифра. Какой в ней смысл? Мы же меряем у C++ и Java.

Я так понимаю, ты меня совсем за идиота держишь. На ноуте запускал все тесты (кроме моно) с размером 256МБ (да, взял, и поменял аж одну цифру в твоих примерах). На новом компе - все по 512МБ.

Какой «смысл» ты вкладывал с цифру 512МБ я так и не понял, посему 256МБ выбрал просто чтоб в оперу гарантированно поместилось.

>> не во всех компиляторах есть -O4 %)

Давайте не будем упоминать недокомпиляторы

gcc-4.3

и тогда я не буду приводить примеры недо-JVM.

Мне пох на JVM.

> gcc-4.3

А почему не gcc-0.9(beta) 1987 года выпуска??? Ах, да плюсы нужны. Тогда 1.15.3, релиз того же года.

С умным видом намекаешь на free()/delete перед завершением программы. Не просто толсто, жирно, я б сказал. Или это опять паранойя сказывается?

С умным видом намекаешь, что по привычке хотел поставить delete, но вот именно специально решил не ставить тут? Вот где жирнота-то.

На ноуте запускал все тесты (кроме моно) с размером 256МБ (да, взял, и поменял аж одну цифру в твоих примерах). На новом компе - все по 512МБ.

Сразу говори, а то мне плохо видно, что ты там делаешь.

Какой «смысл» ты вкладывал с цифру 512МБ я так и не понял, посему 256МБ выбрал просто чтоб в оперу гарантированно поместилось.

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

Я увеличил количество итераций, чтобы разброс был меньше. Результаты на моей машине:

[ortfero@u210 ~]$ cat test.cxx
#include <iostream>
#include <vector>

int main( int, char ** )
{
    static const int limit = 256 * 1024 * 1024;
    static const int reps = 100;

    try
    {
        typedef std::vector< char > bytes;
        bytes array( limit );

        for( int r = 0; r < reps; ++r )
        {
            for( int i = 0; i < limit; ++i )
                array.at( i ) = -1;
        }
    }
    catch( const std::exception & e )
    {
        std::cout << "error : " << e.what() << std::endl;
    }

    return 0;
}
[ortfero@u210 ~]$ cat Test.java
public class Test
{

    public static void main(String[] args) {

        final int LIMIT = 256 * 1024 * 1024;
        final int REPS = 100;

        try {        
            byte[] array = new byte[LIMIT];

            for( int r = 0; r < REPS; r++ ) {
                for (int i = 0; i < LIMIT; i++)
                    array[i] = -1;
            }
        } catch (OutOfMemoryError e) {
            System.out.println( "can`t allocate memory" );
        }
    }

}
[ortfero@u210 ~]$ g++ -O3 test.cxx
[ortfero@u210 ~]$ javac Test.java
[ortfero@u210 ~]$ time ./a.out

real	1m13.587s
user	1m9.942s
sys	0m0.463s
[ortfero@u210 ~]$ time java -Xmx512m -server Test

real	0m42.895s
user	0m28.042s
sys	0m12.553s
[ortfero@u210 ~]$ 

> С умным видом намекаешь, что по привычке хотел поставить delete, но вот именно специально решил не ставить тут?

Нет, по привычке захотел поставить free(), но потом вспомнил, что это плюсы, а потом вообще забил по вышеупомянутой причине.

for( int r = 0; r < reps; ++r )
{
for( int i = 0; i < limit; ++i )
array.at( i ) = -1;
}

array.at( i )

Это ж вызов функции!? Еще бы, оно у тебя так тормозит!

>Нет, по привычке захотел поставить free(), но потом вспомнил, что это плюсы, а потом вообще забил по вышеупомянутой причине.

Т.е. это трагическая случайность, повторение которой в реальном проекте невозможно. Ясно. Только ведь это все равно антипаттерн: new; /blah-blah-blah/ delete.

Это ж вызов функции!? Еще бы, оно у тебя так тормозит!

-O3

честно говоря не знаю, что вы меряете( лень все читать ), но на С++ я бы данный пример написал так:

#include <cstdlib>

int main( int, char ** )
{
	static const int limit = 256 * 1024 * 1024;
	static const int reps  = 100;

	char* buf = new char[ limit ];
	if( buf )
	{
		char* end = buf + limit;

		for( int r = 0; r < reps; ++r )
		{
			for( char* p = buf ; p < end ; ++p )
				*p = -1;
		}
	}

	delete[] buf;
}

g++ -O3 ./1.cpp
time ./a.out 

real	0m9.028s
user	0m8.881s
sys	0m0.152s

Задача в том, чтобы наиболее приближенный к Java вариант написать (не наиболее эффективный) и сравнить, так ли уж медленно там доступ к памяти осуществляется.

Да, если уж if( buf ), то тогда new( std::nothrow ), а если new, то тогда try/catch.

>но на С++ я бы данный пример написал так:

я бы бил молотком по пальцам каждый раз, когда в C++ пишут код, требующий явного вызова delete/delete[]

Пальцы всем перебьете. Кто же писать программы будет тогда?

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

>>>gcc-4.3

Если мне не изменяет склероз, то -О4 и выше были убраны во всех ванильных gcc вышедших после 2.95.3. Ключи оставили, но эффект у них как и у -О3.

> я бы бил молотком по пальцам каждый раз, когда в C++ пишут код, требующий явного вызова delete/delete[]

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

П.С. в конце main() строка «return 0;» смотрится куда лучше освобождения памяти, которое и без того произойдет.

> Какова ниша D?

Заменить Си и Сипипи. Окамлы тут даже рядом не стоят.

> Да, если уж if( buf ), то тогда new( std::nothrow ), а если new, то тогда try/catch.

согласен, сначала написал malloc, потом решил, что меня обвинят, что это не С++ и переправил на new/delete, но это момент упустил

> я бы бил молотком по пальцам каждый раз, когда в C++ пишут код, требующий явного вызова delete/delete[]

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

вот кстати еще более быстрый вариант:

#include <alloca.h>
#include <memory.h>
#include <cstdlib>

int main( int, char ** )
{
	static const int limit = 256 * 1024 * 1024;
	static const int reps  = 100;

	char* buf = (char*) alloca( limit );
	if( buf )
	{
		for( int r = 0; r < reps; ++r )
			memset( buf, -1, limit );
	}
}

g++ -O3 ./1.cpp && time ./a.out 

real	0m3.058s
user	0m2.908s
sys	0m0.148s

256 мегабайт на стеке, выделенные нестандартной функцией - это круто. И даже segfault не словил. Волшебник, право слово.

> 256 мегабайт на стеке, выделенные нестандартной функцией - это круто

спасибо

И даже segfault не словил. Волшебник, право слово.

если у вас в системе дефолтный стек слишком мал - воспользуйтесь <sys/resource.h>, ну или ulimit, если лень в код добавлять

> если у вас в системе дефолтный стек слишком мал...

Да это-то я знаю. А вот кто не в курсах и попробует сие запустить, начнет исходить на говно. И опять C виноват окажется :)

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

Кстати, на D связка D+ Python получается ещё проще: http://pyd.dsource.org/ http://pyd.dsource.org/celerid.html http://delight.sourceforge.net/index.html http://delight.sourceforge.net/compare.html

И когда начианют грить - вот новый супер-пупер D (G,E,F .. Z) всех убъет и один останется у меня появляются сильные сомнения... Да, на нем можно будет писать все - но одинаково хреново;-) Это два.

на нишу универсального одинакового хренового для всех языка уже претендует С++, нечего D в этой нише делать :))

http://pyd.dsource.org/dconf2007/presentation.html

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

Да, но зачем специально расставлять грабли, на которые потом все равно наступят?

>Пальцы всем перебьете. Кто же писать программы будет тогда?

К счастью, не всем:)

>Я бы отрывал язык тем, кто возмущается на рабочий, не вызывающий никаких проблем код

Рабочий и не вызывающий проблем - лишь до поры до времени

И да, в моем мировоззрении никак не укладывается тот факт, что в C++ программируют как на C, а не как на C++

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

Альтернатива бусту - написание собственных велосипедов, дублирующих буст. Но действительно - каждому своё:)

>И да, в моем мировоззрении никак не укладывается тот факт, что в C++ программируют как на C, а не как на C++

Вдобавок и еще очень бурно реагируют на тех кто пытается писать на C++ как на C++ (мой последний тред).

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

Для С++0x возможны реализации со сборкой мусора

>Нормальный override, а не этот мерзкий [[override]] в конце концов.

Скобки уже вроде выпилили, будет просто override

>Когда уже ARM начнут поддерживать?

А также MIPS, SH4 и PowerPC

> Рабочий и не вызывающий проблем - лишь до поры до времени

Ну и как долго ждать того времени, когда этот код станет нерабочим?

И да, в моем мировоззрении никак не укладывается тот факт, что в C++ программируют как на C, а не как на C++

Для тех, кто в танке: оператор delete[] в Си отсутствует, его ввели именно в полюсах. А в том, что некоторым программерам его использовать религия не позволяет, не виноват ни я, ни Страуструп, ни человек, написавший тот клочок кода.

>Ну и как долго ждать того времени, когда этот код станет нерабочим

До первого исключения, например.

Для тех, кто в танке: оператор delete[] в Си отсутствует, его ввели именно в полюсах

Еще в плюсах есть placement new. Но ведь вы же не вызываете его явно, правда же? Явное использование delete/delete[] - из той же серии: оно должно быть зашито в деструкторах вспомогательных классов (например, тех же std::vector и std::array) и не вызываться нигде больше.

> в моем мировоззрении никак не укладывается тот факт, что в C++ программируют как на C

Тебе надо расширить сознание^Wмировоззрение %)

И что не так с delete[]?

>Если мне не изменяет склероз, то -О4 и выше были убраны во всех ванильных gcc вышедших после 2.95.3. Ключи оставили, но эффект у них как и у -О3.

У меня на 4.5 эффект от -O4 есть.

>И что не так с delete[]?

То, что явный вызов этого оператора является индикатором того факта, что перед нами - быдлокод, в котором даже нет автоматического управления ресурсами в стиле C++.

Ответ в стиле «патамушта гладиолус».

управления ресурсами в стиле C++.

Кстати, тебе еще нужно уложить в свое мировоззрение такой факт: Си++ гораздо старше Буста и даже STL.

>До первого исключения, например.

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

юзай LLVM D compiler. Или собери кросс gcc с поддержкой gdc.

>юзай LLVM D compiler. Или собери кросс gcc с поддержкой gdc.

насколько оно стабильно?