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

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]ppkk
2008-05-02 11:54 (ссылка)
Собственно, а почему бы вам такую программу не написать? Код жабы, кажется, уже открыт. Теоретически возможно к нему приложить любую программу с открытым кодом под GPL2. Если программа окажется полезной. народ за нее проголосует и станет вместе с жабой распространять. Передать пожелание я могу, но сильно сомневаюсь, что на него откликнутся. Оно, вероятно, полезное, но не интересное :-)

Я очень рад, что скорее всего не откликнутся. Я добра Яве не желаю, развивать её не хочу, не то, что собственным трудом, так даже полезными советами. Не считал бы очевидным, не писал бы и предложений:)

А вот сортировку TStringList во Фри Паскале улучшить, наверное, соберусь: её разработчики ФП, скорее всего, тоже считают полезной, но неинтересной:)

По-моему, лучше бы умолчательные параметры устанавливали в более разумные.
Они не могут быть разумными. Это не типичная программа на Яве, но какому-нибудь преобразователю картинок может легко потребоваться от 128*160=20480 б до нескольких гигабайт. (С учётом почти популярности подсчёта статистики использования цветов в картинке на языке PHP, это не так уж глупо.)

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


[info]qwerty
2008-05-02 12:09 (ссылка)
Ну, почему не может? Установить максимум в 2 ГБ и держать liveness в некотором диапазоне (60-80%, например). Если становится больше высшей границы, кучу расширять, например, умножая ее размер на некоторый больший единицы коэффициент, но не более, чем до предела. Если меньше низшей границы, соответственно, наоборот. Начинать с нижнего предела размера, каковой установить, скажем, в 4 МБ. Единственный недостаток - сжирающее всю кучу приложение помрет не быстро, а долго и мучительно свопя.

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

Пардон, что лезу в разговор
[info]mc6312.livejournal.com
2008-05-02 17:27 (ссылка)
> сортировку TStringList во Фри Паскале улучшить
Там не в самой сортировке дело, там сравнение строк тормозное до изумления.
Ради эксперимента вместо TStringList.Sort попробовал TStringList.CustomSort(SortProc), где вместо SortProc была стянутая из дельфей ассемблерная процедура, результат:
Sort: 13.58 sec.
CustomSort: 3.92 sec.
в 3.5 раза быстрее...

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

Re: Пардон, что лезу в разговор
[info]ppkk
2008-05-02 19:10 (ссылка)
Интересно.

В принципе, я не без этой мысли: иначе про TList написал бы.

Но Дельфы тоже тормозят: выше я писал, что "стандартным методом" у ФП время ~25 секунд, у Дельф — ~23, так что и в Дельфах SortProc не очень освоен.

А процедура встроенная (inline)? Как я понимаю, "быстро" могут работать только встроенные процедуры и процедуры из модуля system.

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

Re: Пардон, что лезу в разговор
[info]mc6312.livejournal.com
2008-05-02 20:58 (ссылка)
У фрипаскаля внутри TList.Sort целые дебри:
Procedure TStringList.Sort;
begin
CustomSort(@StringListAnsiCompare);
end;

function StringListAnsiCompare(List: TStringList; Index1, Index: Integer): Integer;
begin
Result := List.DoCompareText(List.FList^[Index1].FString,
List.FList^[Index].FString);
end;

Function TStringList.DoCompareText(const s1,s2 : string) : PtrInt;
begin
// могли бы процедурную переменную для функции сравнения завести, нафига каждый раз
// if-then?
if FCaseSensitive // почему-то по умолчанию оно false, и вызывается проверка не учитывающая регистр
then result:=AnsiCompareStr(s1,s2)
else result:=AnsiCompareText(s1,s2);
end;

function Win32AnsiCompareText(const S1, S2: string): PtrInt;
begin
// при этом она (под win32) просто вызывает функцию API, которая довольно нетороплива
// емнимс, они это передрали у дельфей
result:=CompareString(LOCALE_USER_DEFAULT,NORM_IGNORECASE,pchar(s1),length(s1),
pchar(s2),length(s2))-2;
end;

если TStringList.CaseSensitive=true, то все равно используется аналогичная обертка системной CompareString, только без флага NORM_IGNORECASE, естественно, оба варианта одинаково тормозят.

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

Re: Пардон, что лезу в разговор
[info]ppkk
2008-05-02 21:55 (ссылка)
// емнимс, они это передрали у дельфей
Просто вызов соответствующей системной функции, по-моему, нельзя считать передиранием. БОльшая часть sysutils под Окнами, кажется, — вызов соответствующих функций ОС.

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

И поэтому я упомянул "быструю сортировку", чтобы не обещать зарабатывать геморрой.

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

Re: Пардон, что лезу в разговор
[info]mc6312.livejournal.com
2008-05-02 22:07 (ссылка)
> отслеживать возможное изменение кодировки

А зачем отслеживать? Маловероятно, что она изменится за время работы процесса (если это не серверное чего-нибудь, да и там тоже). При старте программы создаются таблицы для перевода в верхний регистр (в случае Win32 - с помощью CharUpperBuff, например) и т.п. для текущей кодировки, и далее они используются для регистро-независимого сравнения и т.п.

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

Re: Пардон, что лезу в разговор
[info]ppkk
2008-05-02 22:42 (ссылка)
Да, именно так, только, по-моему, отслеживать надо (не хочется накосячить), и это в принципе несложно (просто хранить с найденными значениями и название кодировки, и каждый раз проверять, не сменилась ли она).

А поддержка неоднобайтовых кодировок — не понимаю, что с ней во Фри Паскале.

И что с поддержкой UTF-8, для которой метод не годится (но которая даже в Окнах имеет номер и название как кодировка).

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

Re: Пардон, что лезу в разговор
[info]mc6312.livejournal.com
2008-05-03 00:25 (ссылка)
Widestrings (UTF-16) во фрипаскале есть. Функции для преобразования utf-8/utf-16/utf-32 друг в друга тоже есть. Функции сравнения строк для widestrings тоже есть. Что у них внутри еще не смотрел.

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

Re: Пардон, что лезу в разговор
[info]ppkk
2008-05-02 20:24 (ссылка)
Про сортировку я ещё имел в виду, что "быстрая сортировка" лично мне не нравится: нужны ловкости для снижения вероятности квадратичного времени и т.п. Какой-нибудь вариант сортировки кучей, что-нибудь такое, может быть лучше.

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


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