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

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]lolepezy
2008-04-29 16:46 (ссылка)
Не, ну понятно, что это не тщательные деталное тестирование.
Просто пример показательный.

Я вот тоже пишу на плюсах потому что большие вычисления на нем
быстрее. Но если бы можно было сравнимую производительность
получить, например, на джаве --- давно все переписал бы.

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


[info]kouzdra
2008-04-29 16:53 (ссылка)
Что для числодробилок С++ лучше - я не спорю. Дело в том, что кроме числодробильных задачек есть еще много других - когда всякие хитрые структуры данных с кучей ссылок друг на друга - и вот там С++ частенько пролетает не только по удобству, но и по эффективности.

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

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


[info]tristes_tigres
2008-04-30 00:14 (ссылка)
Что для числодробилок С++ лучше - я не спорю.

Для числодробилок C++ сосёт. Нет нормальных многомерных массивов, нет способа узнать, размещена ли память по указателю, необходимые библиотеки (читай- LAPACK) всё равно на фортране.

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


[info]lolepezy
2008-04-30 08:23 (ссылка)
Угу.

Про подсчет ссылок: я как-то заглянул в реализацию boost::shared_ptr<>.
Там классов штук 5-6 и где-то в потрохах есть код на ассемблере. Самое
веселое, что оно еще и страшно тормозит -- деструктор этого boost::shared_ptr<>
при более-менее регулярном использовании вызывается миллионами раз.

Это все при условии, что boost считается (да и является, в общем-то)
образцом кодирования.

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


[info]tristes_tigres
2008-04-30 00:12 (ссылка)
Большие вычисления надо писать на Fortrane 95 или 2000. Это удобнее и работать будет быстрее.

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


[info]qwerty
2008-04-30 07:51 (ссылка)
Фортран и Фортресс для вычислений рулез. Особенно последний.

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


[info]tristes_tigres
2008-04-30 22:09 (ссылка)
Vaporware не может быть лучше проверенного инструмента по определению.

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


[info]qwerty
2008-04-30 22:16 (ссылка)
Может - меня от него тащит. А от Фортрана нет.

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


[info]lolepezy
2008-04-30 08:41 (ссылка)
Ну в теории - да, на практике (академической) этого факта я не
обнаружил.

В свое время заморочился вопросом - разница в производительности
кода на с++ и фортране (какой-то тест с МКЭ и методом сопряженных
градиентов) при должном изоморфизме программ оказалась равна нулю.

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

Другое дело, если мы говорим про индустриальные стандарты. Там
фортран рулил и продолжает рулить по историческим причинам (весь
вычислительный багаж за 50 лет) и потому, что всякие распараллеливающие
компиляторы писались в первую очередь для фортрана.

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


[info]tristes_tigres
2008-04-30 22:11 (ссылка)
а в плане читабельности и сопровождения, особенно когда нужно поддерживать в рабочем сотоянии под 100000 строк кода, с++, кажется, лучше.

Однако же наибольший code reuse не в теории, а на практике, обеспечивает именно Fortran.

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


[info]qwerty
2008-05-02 12:15 (ссылка)
Фортран гораздо лучше распараллеливается на высокопроизводительных компутерах. И SIMD тоже существенно проще автоматически используются компилятором. Причина в алиасинге - в ЦПП чрезвычайно много ссылок на что попало, и компилятору никак не понять, не может ли быть ссылок на некоторый языковой объект и не могут ли две данные ссылки указывать на один объект. Потому ему приходится из заботы о корректности предполагать худшее. В Фортране ссылки используются существенно реже.

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


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