Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет kouzdra ([info]kouzdra)
@ 2008-04-29 14:22:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Entry tags:Компутерщина

Тут наткнулся на очередного энтузиаста С++ с незамутненным вполне сознанием. Ну интереса ради написал три тестика - точнее один - на трех языках:

создание и сортировка (причина выбора теста была в упоминании std::sort в контексте Ну не нужно и все. И списки сортировать без библиотечных функций не нужно) массива из 2 млн строк, представляющих собой числа от 0 до 2_000_000 в дес.записи:

C++:

void test () {
   vector v (2000000);
   char buf [20];
   for (int i = 0; i != v.size (); ++ i)
   {
     sprintf (buf, "%d", i);
     v [i] = string (buf);
   }
   sort (v.begin (), v.end (), less_equal ());
//   for (int i = 0; i != v.size (); ++ i)
//      cout << v [i] << "\n";
}


O'Caml:
let (+>) x f = f x
let s = Array.init 2_000_000 string_of_int      
let _ = Array.fast_sort compare s      
(*let _ = s +> Array.to_list +> String.concat ", " +> Printf.printf "[%s]\n"*)      


Java:
	public static void main(String[] args) {
		final String [] v = new String [2000000];
		for (int i = 0; i < v.length; i++) v[i] = Integer.toString(i);
		Arrays.sort(v);
//		for (String aV : v) System.out.println("s = " + aV);
	}


Результаты оказались ожидаемыми - С++ с O'Caml одинаковы по скорости, программа на O'Caml потребила 36MB памяти против 54MB на С++, Жаба порвала С++ как бобик тряпку - инициализация - массива раза в полтора быстрее, сортировка - раза в 3.

Смотреть код и память у Жабы - занятие то, еще на код O'Caml и C++ я посмотрел:
O'Caml - 84 вполне естественных строчки на асме, С++ - 2895 строчек (без отладочной информации).

Ну собственно - вполне типовой пример того, что получается если "просто писать на С++, как на нормальном языке" - хреново получается. Аффтар исходного поста в конце треда уже что-то несет про то, что вот да с доступом к векторным инструкциям он любой O'Caml уделает.

Может и уделает (хотя я не очень понимаю, как сортировку оптимизировать "векторными инструкциями") - только вот даже 10,000 строк кода затрахаешься "векторными инструкциями" оптимизировать. Ну о портабельности я уж и не говорю. Хотя боюсь, что и с эффективностью будут траблы - потому что умственные усилия, которые можно на усовершенствование алгоритмики потратить, пойдут на "векторные инструкции".


Какая из этого мораль - да очень простая - полезно иногда немного по сторонам смотреть, ну и еще одна - если Вы совершенно точно не знаете, почему вам не подходит Жаба - не лезьте в С++ - просто потратите кучу времени совершенно зря.


(Читать комментарии) - (Добавить комментарий)


[info]kouzdra
2008-05-01 11:24 (ссылка)
Да нет - просто у них нет лимита - они действительно могут сожрать всю память - но по крайней мере ocamlевый расширяет кучу только если она оказывается заполнена слишком сильно (там есть параметр - заполненность кучи - Gc.space_overhead) -

http://caml.inria.fr/pub/docs/manual-ocaml/libref/Gc.html

которым можно управлять, как и прочими параметрами Gc - причем можно их менять на ходу. Жабий GC после общения с ocaml'евским у меня честно говоря вызывает изрядное раздражение - у тех давно уже и инкрементальный сборщик нормально работал.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]qwerty
2008-05-01 13:05 (ссылка)
У меня размер кучи управляется диапазонами по размеру, доле живых объектов (примерно соответствует твоему параметру) и доле времени исполнения программы, проведенной в сборщике мусора. Размер меняется только после большой сборки мусора. Диапазоны там для гистерезиса, чтобы не гуляло туда-сюда на границе. И все равно работает не очень хорошо - иногда пухнет слишком быстро, иногда наоборот. Подозреваю, что по существу все эти параметры нужны для предсказания будущего по короткому прошлому, а для моего алгоритма и типичных приложений оно нифига предсказываться не желает. Вместо гладкости явно лезут периодические свойства остатков (типа, размер младшего поколения поделить на аппетит тела цикла).

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

Но -Xmx явно скоро умрет. Для нового сборщика G1 в нем мало смысла.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ppkk
2008-05-02 00:34 (ссылка)
G1
А когда оно будет?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]qwerty
2008-05-02 03:10 (ссылка)
В серверном варианте уж больше года как есть.

(Ответить) (Уровень выше)


(Читать комментарии) -