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

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]max630.net
2008-04-29 15:20 (ссылка)
немного крючкотворства:

1. что такое sprintf? это C++ или где?
2. string вроде тупо копируются. надо бы _указатели_ в массив сложить.

boost, ага

по поводу крутости ocaml - у скольки там процентов скачавших "чистилку комментов" на окамле она запустилась? Вот и ответ. А в ассемблер пялиться - не барское дело, я после ДВК вообще ни одного ассемблера не знаю

(Ответить) (Ветвь дискуссии)


[info]kouzdra
2008-04-29 16:24 (ссылка)
1) Ну не stringstream же наворачивать - это уже вообще какой-то отстой будет.
2) Фирменный пример энтузиаста у меня даже не откомпилировался - потом что он у него на самом деле под Visual ненароком оказался заточен - так что :)

По факту - если о переносимости - Java тут вне конкуренции. При всех ее заморочках.

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

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


[info]max630.net
2008-04-30 06:47 (ссылка)
> если о переносимости - Java тут вне конкуренции

ага, ага :)

пока думал над ответом - прилетело:
http://community.livejournal.com/ru_java/641197.html

И памяти на только запустить VM возьмёт столько, сколько никаким STL не снилось.

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


[info]dluciv.livejournal.com
2008-04-30 11:22 (ссылка)
Именно stringstream

Так как там парсер статический, никаких форматных строк, и еще и поинлайниться что-то может. Страуструп еще говорил, что cout должен, по идее, работать быстрее, чем printf и жрать меньше памяти.

Поначалу, вроде бы, многие производители STL халявили, и вызывали scanf и printf, но сейчас, кажется, дела обстоят лучше.

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


[info]kouzdra
2008-04-29 16:28 (ссылка)
PS: А в ассемблер поглядывать иногда полезно бывает - чтобы примерно представлять, что во что выливается. Я вот как-то на dynamic-cast'ы посмотрел - и начал срочно их на виртуальные методы downcasting'a заменять - потому что тормоза неимоверные.

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


[info]lolepezy
2008-04-29 15:37 (ссылка)
Жуть.

Если приводите результаты тестов на С++, надо указывать
флажки оптимизатора, потому что результат при разных опциях
отличается обычно в разы.

Ну а вообще, да, если нечто можно написать на джаве --- его лучше
написать на джаве. С++ ужасен (ну кроме template'ов разве что), а
с новым стандартом станет еще чудовищнее.

(Ответить) (Ветвь дискуссии)


[info]kouzdra
2008-04-29 16:27 (ссылка)
gcc 4.2 -O2

С++ ужасен (ну кроме template'ов разве что

template тоже ужасны - хотя бывают полезны

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


[info]q
2008-04-30 08:11 (ссылка)
-O2 для шаблонного кода - мало, надо -O3 (+). Тогда включится inlining.

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

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


[info]ppkk
2008-04-30 17:25 (ссылка)
У меня тоже не скомпилировался, более того: отругался на то, что "sprintf" — "deprecated". А значит нарушено главное условие: написание кода "как принято". Ниже я какие-то тексты (полностью) написал в комментариях с приблизительным временем исполнения, интересно было бы сравнить.

Правда, у меня не Гэцеце, а компилятор от Интел (валявшийся почему-то под руками) + бесплатная версия Микрософт В. С. 2005 (его быстрее всего было скачать; итого: для командной строки), запускал с единственным ключиком "-Ox".

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


[info]phantom
2008-04-29 16:38 (ссылка)
кроме того, нужно дополнительные
меры принимать, чтобы эксперименты
были более чистыми (массово и т.д.)

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


[info]kouzdra
2008-04-29 16:44 (ссылка)
Вообще-то достаточно просто посмотреть на текст basic_string, чтобы понять, что эффективно это быть не может :)

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


[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 тоже существенно проще автоматически используются компилятором. Причина в алиасинге - в ЦПП чрезвычайно много ссылок на что попало, и компилятору никак не понять, не может ли быть ссылок на некоторый языковой объект и не могут ли две данные ссылки указывать на один объект. Потому ему приходится из заботы о корректности предполагать худшее. В Фортране ссылки используются существенно реже.

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


[info]ppkk
2008-04-30 17:29 (ссылка)
Я с [info]kouzdra@lj не соглашусь: во-первых, код на Цепепе недостаточно "стандартный", по-моему, (http://lj.rossia.org/users/kouzdra/446546.html?thread=2527314&style=mine#t2527314), а во-вторых: Ява не сработала без возни со стороны пользователя (а не программиста), но протормозила до вылета столько же, сколько Цепепешная программка (http://lj.rossia.org/users/kouzdra/446546.html?thread=2524754&style=mine#t2524754).

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


[info]ketmar
2008-04-29 17:55 (ссылка)
ты учти, что аффтар — он в геймдеве работает. там адекватных людей можно по пальцам рук перечесть.

зыж а жаба всё-таки говно. %-)

(Ответить) (Ветвь дискуссии)


[info]kouzdra
2008-04-29 19:16 (ссылка)
Жаба - говно, но довольно практичное. Лет 10 назад С++ был практичным говном, сейчас он говно, но непрактичное :)

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


[info]ketmar
2008-04-29 19:20 (ссылка)
заметь, про практичность я не сказал ни слова. %-)

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


[info]peter_lemenkov
2008-04-29 21:37 (ссылка)
> ты учти, что аффтар — он в геймдеве работает. там адекватных людей можно по пальцам рук перечесть.

+1
Все проще и проще в это верится.

> зыж а жаба всё-таки говно. %-)

Не, нармал-нармал. Все ж лучше, чем С++

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


[info]ketmar
2008-04-29 22:25 (ссылка)
>Не, нармал-нармал. Все ж лучше, чем С++
такая же херня, только обёртка красивая. язык, где есть GC и нет возможности писать полноценную функцилональщину не нужен.

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


[info]kouzdra
2008-04-29 22:33 (ссылка)
Замыкания-то в Жабе как раз есть - даже вполне полноценные. Только страшные, как атомная война.

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


[info]ketmar
2008-04-29 23:06 (ссылка)
замыкания — не всё, что надо для функциональщины. рискну сказать, что они и вовсе не обязательны.

плюс — если этим пользоваться неудобно, то этого нет.

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


[info]dimzon541.livejournal.com
2008-04-29 18:36 (ссылка)
боян

ещё пару лет назад видел сравнение Java vs GCC STL, Java победила

(Ответить)


[info]peter_lemenkov
2008-04-29 21:40 (ссылка)
Мне там понравилось про отсутствие битовых операций в яункциональных языках.

(Ответить) (Ветвь дискуссии)


[info]ketmar
2008-04-29 22:26 (ссылка)
да-да. как бедные люди в 60-е на лисп-машинах писали оконные морды без такой важной штуки — не ясно.

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


[info]ppkk
2008-04-29 22:35 (ссылка)
У меня под рукой сейчас нет ни компилятора Явы, ни Цепепе (то есть: есть, но только компилятор, без библиотек, включая даже stdio.h), но мне кажется программа на цепепе просто нечестной (инициализация, естественно, очень странно выглядит; в сортировке надо убедиться, что less_equal() встраивается, а не вызывается).

Так что дам ссылку (одну из многих подобных) и процитирую выводы: http://bruscy.multicon.pl/pages/przemek/java_not_really_faster_than_cpp.html
"The most important conclusion is obvious. (For this set of benchmarks,) C++ is clearly the winner.

Second conclusion - don't use Client VM in Java.

Unfortunately, there's also a third conclusion. It seems that it's much, much easier to create a well performing program in Java. So, please consider it for a moment before you start recoding your Java program in C++ just to make it faster…"


Паскаль же, которым я пользуюсь, считает мучительно долго, а инициализирует не очень кратко. "Стандартный" способ (судя по стилю) должен быть примерно (FreePascal, без подсчёта времени):

{$MODE OBJFPC} // чтобы integer был не как в допотопные времена (а 4 или 8 байт)
program sorttest;
uses classes; // TStringList

var
soo: TStringList;
i: integer;
s: string; // криво

begin
soo := TStringList.Create;
for i := 0 to 1999999 do
begin
Str(i,s);
soo.Add(s); // в Дельфах есть IntToStr(num): сразу на четыре строчки короче (в FPC почему-то не сделали)
// зато в FPC есть BinStr(), HexStr() и OctStr()
end;
soo.Sort;
soo.Destroy; // для красоты
end.


У меня работает: примерно секунду инициализирует, примерно двадцать четыре секунды — сортирует (причём quicksort-ом). На Дельфах (похожий текст) то же самое примерно (на две секунды быстрее).

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

(Ответить) (Ветвь дискуссии)


[info]kouzdra
2008-04-29 22:39 (ссылка)
У плюсов тормозят imho операции с пересылками строк - они там хоть и указатели, но со счетчиками ссылок - а счетчики ссылок штука недешевая (при том, что в контексте сортировки ухаживание за ними бесполезно абсолютно). Собственно пример про это и был - что у хвленого плюсового около-STL-ного "интеллекта" есть очень заметные побочные эффекты

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


[info]ppkk
2008-04-29 22:43 (ссылка)
Там нет проблем с вызовом less_equal? Он встраивается, а не вызывается?

Для упорядоченных массивов пример всё равно плохой. Это особый случай: если известна информация, что, например, массив почти упорядочен, надо использовать нестандартную сортировку (а, например, smoothsort).

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


[info]ppkk
2008-04-30 04:57 (ссылка)
Не поленился: поставил себе домой компилятор C++.

Фри Паскаль дома работает те же 25 секунд, что и на работе.

C++: (itoa --- видимо, любой нормальный человек для совместимости эту функцию сделает так или иначе, у меня с http://www.jodrellbank.manchester.ac.uk/~slowe/cpp/itoa.html )

Работает примерно 5.5 секунд.

#include 
#include 
#include 
#include 

using namespace std;

inline std::string itoa(int value, int base)
  {
  enum { kMaxDigits = 35 };
  std::string buf;
  buf.reserve( kMaxDigits ); // Pre-allocate enough space.
  // check that the base if valid
  if (base < 2 || base > 16) return buf;
  int quotient = value;
  // Translating number to string with base:
  do {
     buf += "0123456789abcdef"[ std::abs( quotient % base ) ];
     quotient /= base;
     } while ( quotient );
  // Append the negative sign for base 10
  if ( value < 0 && base == 10) buf += '-';
  std::reverse( buf.begin(), buf.end() );
  return buf;
  }

int main ()
   {
   std::vector v;
   char buf[20];

   for (int i = 0; i != 2000000; ++ i)
     {v.push_back(itoa(i,10));}
   sort (v.begin(), v.end());
   //for (int i = 0; i != v.size(); ++ i)
   //  {cout << v[i] << "\n";}
   }


Ява дома есть.

import java.util.Arrays;
public class ss {
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);
}
}


Справилась примерно за то же время, что и программа на Цепепе, только неуспешно: памяти не хватило.

По-моему, хороший повод Яву проигнорировать.

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


[info]ppkk
2008-04-30 04:59 (ссылка)
На предпросмотре читались "include"-ы: algorithm, string, vector, iostream.

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


[info]kouzdra
2008-04-30 17:29 (ссылка)
У JVM лимит памяти по умолчанию - 32mb - надо увеличивать - -Xmx128m например

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


[info]ppkk
2008-04-30 17:46 (ссылка)
Я Явой обычно не пользуюсь (не то что как программист, а как пользователь), так что, конечно, действительно честно забыл (но помнил, что существуют). А это ещё и "спрятанные" параметры: чтобы о них узнать, нужно запускать "java -X".

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

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

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

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


[info]kouzdra
2008-04-30 17:51 (ссылка)
Будет быстрее - тут она в предсмертной агонии в основном мусор собирала - это вообще фича языков с GC - если начинает реально не хватать памяти - идет катастрофическое падение производительности.

Но тут ситуация такая - отчуждение жабских приложений - действительно порядочный геморрой. Только это как раз для "серьезных приложений" наименее актуально - потому что там просто пишут инсталлятор/запускалку - и это не напрягает относительно общего объема работы. А вот для простых программок - это трабл.

В этом смысле, кстати, Linux сейчас имеет серьезные плюсы перед виндой - потому что в нем сейчас проблемы вроде установки JRE сводятся к
sudo apt-get install jre (да и это можно прописать в зависимостях, если оформлять софтину как пакет).

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


[info]ppkk
2008-04-30 18:25 (ссылка)
1. Посмотрим дома.

2. Да, как и .net очень не подходит для продаваемых за деньги утилиток, влезающих на дискетку.

3. В Окнах с интернетом ставится не сложнее. Я считаю несерьёзным требование скачивать что-то из интернета (хотя бы см. пункт два).

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


[info]kouzdra
2008-04-30 18:32 (ссылка)
Сложнее, к сожалению. По части удобства установки более или менее типового софта окошки давно уже в приличном пролете.

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


[info]ppkk
2008-04-30 18:47 (ссылка)
I.
Вопрос вкуса:
1. На случай новых версий есть автоматическое обновление.
2. Но я его отключаю, ибо для меня зайти на сайт производителя и прочитать, что изменилось и к чему, скачать отдельно файл установочный, который я смогу запустить на любом подходящем компьютере — достаточно удобно.

В броузере ввести "java.com", нажать на кнопку "скачать", нажать нужную ссылку, нажать кнопку "запустить" (когда скачалось), пару раз согласиться с лицензионным соглашением — примерно 16 действий, сравнимо с 25-ю в "sudo apt-get install jre" (то есть: я понимаю, что набить строку и нажать "Ввод" — не требует ожидания загрузок, но на сайте java.com я же могу посмотреть, какие изменения и т.п. [выбрать JDK или JRE, наконец]).

Вот Микрософт Офис, например, — да, с ним приличный пролёт. Он у меня не устанавливается ни на рабочий, ни на домашний компьютер (кроме как на виртуальную машину).

II.
Так что с быстродействием моего текста на Цепепе (на максимальной оптимизации, конечно)? Быстрее, медленнее, также? Можно время в секундах?
Я из дома на Яве ещё измерю быстродействие с увеличенной памятью, но только из дома.

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


[info]ppkk
2008-04-30 18:52 (ссылка)
Конечно, прописать скачивание и установку Явы (или установку с диска) при необходимости можно и под Окнами: так многие делают.

Кстати, жена пользуется SPSS (неоднозначной осмысленности статистический пакет): последнюю версию переписали на Яве, но кучу окнозависимого, как я понимаю, оставили, а тормозит ужасно (по словам жены, по сравнению с предыдущей версией, достаточно торможения интерфейса, хотя может и вычисления тормозят).

"Налогоплательщик" для ведения электронной переписки с налоговыми органами (на работе поставили) — тоже на Яве, тоже окнозависимого хватает.

А сборщик мусора, например, можно и в Цепепе (даже Страуструп об этом пишет относительно конкретно), и в Паскаль установить: дело нехитрое.

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


[info]qwerty
2008-05-02 12:27 (ссылка)
В ЦПП и Пасцаль можно воткнуть только консервативный сборщик мусора. Причем особенно в ЦПП, поскольку там можно откастить указатель к целому и записать в целое поле. Консервативный сборщик может работать хорошо только почти всегда. Но может случайно не попереть - подходящего двоичного вида число может быть перепутано с указателем, что помешает освободить непредсказуемое количество мусора. Дефрагментировать консервативный сборщик тоже не может.

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


[info]ppkk
2008-05-02 19:18 (ссылка)
Да, там в связи с .net (в Дельфах ведь после 7-й версии .net — первоочередной вариант) всякие возможности работы с указателями (и так в Дельфах чуть-чуть меньшие, чем во Фри Паскале, и намного меньшие, чем в Це) по возможности урезаны или хотя бы сопровождаются жалобами компилятора.

Я имел в виду: если уж вкручивать сборщик мусора, то и стиль программирования менять.

Для разработчиков, как я понимаю, считается достаточно удобным ключ (во Фри Паскале) -gh, который просто на момент закрытия программы сообщает о всём невысвобожденном с некоторыми деталями.

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

после доработки параметров Явы на стороне пользовател
[info]ppkk
2008-05-02 01:32 (ссылка)
Да, посмотрю на O'Caml при случае.

Ява наверняка что-нибудь кэширует, но 10 запусков последовательных дали:
Цепепе: 61 секунда
Ява: 46 секунд

(подозрительные числа, но повторная проверка дала почти их же)

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


[info]qwerty
2008-04-30 07:59 (ссылка)
Из забав: жаба научилась спекулятивно оптимистически инлайнить объекты. Если A ссылается на B и анализ+статистика говорят, что эта ссылка не меняется, то B отводится в памяти вслед за A тем же запросом, поля B адресуются относительно базы A. Сборщик мусора о том знает из таблиц коллокации и никогда этого инварианта не нарушает. Сама ссылка и заголовок B cохраняются. Если ж когда-нибудь (например, после динамической подгрузки какого-нить класса) будет обнаружено, что исходная ссылка меняется, скомпилированный в предположении о неизменности код выхеривается.

(Ответить) (Ветвь дискуссии)


[info]ppkk
2008-04-30 17:35 (ссылка)
А как делать так, чтобы Ява работала? Я вот скомпилировал программку, а она пять секунд промучилась и вылетела, потому что памяти не хватило (см. выше в комментариях), цепепешная примерно за то же время закончила работу.

Нужно ли писать обёртку (на Цепепе, например) в виде исполняемого файла, который (если требуется) установит соответствующую версию JRE (желательно без интернета, чтобы не было радости типа какой-то возни с драйверами ATI, которую я Вам как-то расписывал: скачать пришлось под гигабайт, кажется), настроит виртуальную мащину для работоспособности программы и запустит саму программу?

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


[info]qwerty
2008-04-30 20:49 (ссылка)
Не знаю - я на жабе пишу только тесты, когда они нужны. В мобильной жабе к программе прикладывается файл описания .jad, в котором можно писать разные параметры типа требуемого размера кучи. Файл этот читается системой управления приложениями, которая запускает либо виртуальную машину, либо задачу в существующей машине с соответствующими параметрами.

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


[info]ppkk
2008-04-30 21:44 (ссылка)
А почему на мобильниках, которые умеют записывать и проигрывать видео, игрушки на этой мобильной Яве — обычно как на Спектруме (или хуже)?

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


[info]qwerty
2008-04-30 22:04 (ссылка)
Вообще-то запись и проигрывание видео к жабе имеет очень отдаленное отношение. Обычно для этого есть отдельный DSP. Если нет, то играет их нативная программка. Правильно реализованная жаба (моя прелессть) вполне сносно работает на мобилах с 32-битовой шиной памяти. Игрушкам бывает полезен 3-мерный ускоритель. Игрушке о нем знать не нужно. Есть, например, аналог Дюка Нюкема, который на валяющемся у меня под рукой устройстве уж год как бегает с примерно 26 кадрами/сек. На мобиле он для демы.

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


[info]ppkk
2008-04-30 23:06 (ссылка)
Вряд ли в моём мобильнике отдельные процессоры и для видео (кодек по крайней мере один), и для звука (кодеки всякие разные), и для фотографий, и для GSM-дел.

А что за модель с Дюком Нюкемом?

У меня телефон Самсунг SGH-E480.

Что мне скачать, чтобы поверить, что Ява — не просто отбрасыватель назад с, условно, 486-ого процессора персоналки на ZX Spectrum?

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


[info]qwerty
2008-04-30 23:46 (ссылка)
У меня мобилы нет. Протроха omap3430 от Техасских Инструментов, кажется. Ускоритель то ли от НВидии, то ли от тех же Инструментов. Виртуальная машина своя, т.е. сановская CLDC HI. Дема графики без управления есть в составе JBenchmark 2.0.

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


[info]ppkk
2008-04-30 23:49 (ссылка)
Попробуем JBenchmark 2.0, если пойдёт. У меня для такого экранчика быстродействие Дюка ассоциируется скорее с персоналками на 386SX.

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


[info]qwerty
2008-05-01 00:32 (ссылка)
Можно запустить чисто вычислительный тест, например, EEMBC и сравнить. У многих мобил 16-битовая шина памяти, в которую вульгарно упирается выборка 32-битовых процессорных инструкций. Жаба на таких мобилах страшно сосет.

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


[info]ppkk
2008-05-02 00:53 (ссылка)
http://www.club-java.com/TastePhone/J2ME/MIDP_Java_telephone.jsp?m=865&brand=Samsung&model=SGH-E480

Я так понял, что Ява-таки его делает Спектрумом-2 Мегабласт, но всё-таки по сути Спектрумом. Или как?

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


[info]qwerty
2008-05-02 03:09 (ссылка)
As fast as a PIII (without Java compiler) at 857.9MHz.

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


[info]ppkk
2008-05-02 20:21 (ссылка)
(эмоциональный черновик, ниже вопрос по существу)
Я ссылку дал не для того, чтобы мне ткнули в эту странную строку, а чтобы получить представление о быстродействии от человека, который может сравнивать процессоры друг с другом, а не с мифическим PIII. Там полно скоростей и объёмов памятей и т.п.

Это бредовая строка. Мало того, что я вообще её не понимаю, так ещё у них процессор XScale PXA-263 на 400 МГц является "as fast as PIII (without Java compiler) at 4,664.7MHz". Или по-другому: где мой Дюк Нюкем? PIII 857.9 МГц без графических и прочих ускорителей обсчитывает Дюка Нюкема на много бОльший по площади экранчик, чем у меня. Если там проблемы с памятью и т.п., то не надо сравнивать с несравнимым (при том, что на скромный экранчик 128*160 текстуры много не займут).

JBenchMark2.0 на мой телефон — примерно … (Трахаюсь с тем, чтобы закачать Яву на телефон: интернет принципиально отключен, через кабель какие-то пляски нужны, можно ли через карту памяти MicroSD — такое ощущение, что нельзя; это всё геморрой от Самсунга, а не от Корпорации, естественно, хотя они в отличие от Моторол-Нокий и разной серой Шушеры из "Евросети" хотя бы в комплект включают кабели и т.п.)

Вопрос.
А как я могу запустить тест и вообще J2ME на персоналке под Окнами? Или не под Окнами (у меня Линукс какой-то установлен тоже)? Вообще как-нибудь?

У меня стоит Pentium-III 600 МГц, интересно узнать, что про него скажут хотя бы тесты JBenchmark.

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


[info]qwerty
2008-05-02 22:11 (ссылка)
Вы говорите, что жаба превращает вашу мобилу в Спектрум, там сообщают, что в третий пень указанной частоты.

Чистую мобильную жабу без блевотек запустить просто. Могу прислать бинарник под винд.чество или линух или можно построить из открытых сырцов с помощью визуального Ц для виндючества / гцц для линуха. Графики и прочего в чистой жабе, конечно, нет. Для всего этого нужен программный эмулятор устройства.

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


[info]ppkk
2008-05-02 22:31 (ссылка)
Вы говорите, что жаба превращает вашу мобилу в Спектрум, там сообщают, что в третий пень указанной частоты.
Я хочу увидеть свидетельство скорости как у PIII. То, что не Sun, а криворукие программисты превращают в Спектрум мой телефон — вполне себе вариант. Но в целом я не верю, что XScale 400 МГц — аналог почти 5 ГГц PIII.
Они судят по тестам, я сужу по имеющимся приложениям, этим они убедительнее намного. Но сравнение с PIII — какой-то странный выпендрёж: повторюсь, что PIII на 800 МГц без всяких ускорителей Дюка Нюкем обсчитывает на весь экран, вовсе не на 128*160. Где мне скачать Дюка?

Чистую мобильную жабу без блевотек запустить просто. Могу прислать бинарник под винд.чество или линух или можно построить из открытых сырцов с помощью визуального Ц для виндючества / гцц для линуха. Графики и прочего в чистой жабе, конечно, нет. Для всего этого нужен программный эмулятор устройства.
Мне хотелось бы на домашнем PIII запустить JBenchmark, например. Так что, конечно, без графики может и не подойти. Если он "станет" PIII бОльшей частоты, то моя мама (которой я всё не соберусь отвести компьютер) будет рада работать под несколькими вложенными Явами (есть ли виртуальная машина Явы, написанная на Яве? наверняка есть же, или как?). Если нет, то я съем свою шляпу буду очень благодарен за помощь в разрешении моих заблуждений.
Если "собрать" — запустить сборку, а не долго править makefile, докачивать и править какие-то библиотеки (я не думаю, что с Явой так, просто подобные действия меня обычно расстраивают), я и сам смогу, то есть достаточно ссылки (я до сих пор не ориентируюсь на сайтах Сана). Svn/cvs или что-нибудь столь же простое для пользователя использовать смогу, конечно. У меня, кстати, под бесплатным МСВЦе установлен сейчас компилятор от Интел, что должно положительно повлиять на возможное быстродействие.

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


[info]qwerty
2008-05-02 23:17 (ссылка)
Графическая часть дюка - в JBenchmark2.0.

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

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

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


[info]ppkk
2008-05-02 23:22 (ссылка)
Посылайте, пожалуйста.

Какой объём (архив мегабайт в 20 почта осилит, наверное)? Почта моя сохранилась, или послать письмецо?

что-то из цыгвина
Это может вылиться во что угодно:] Как раз в похожей ситуации мне как-то приходилось искать старые версии библиотек, ибо с новыми совместимости не было; но вряд ли это тот случай.

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


[info]qwerty
2008-05-02 23:45 (ссылка)
Меньше метра - она ж мобильная. Почту проще еще раз.

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


[info]qwerty
2008-05-02 23:19 (ссылка)
Жаба на жабе - это обычно жаба путем раскрутки, а не интерпретация интерпретатора.

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


[info]ppkk
2008-05-02 23:24 (ссылка)
?

Was ist "Raskrutka"?

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


[info]qwerty
2008-05-02 23:42 (ссылка)
Одна жаба генерит другую, которая работает сама без первой.

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


[info]kouzdra
2008-04-30 17:44 (ссылка)
Кстати - присоединяюсь к предыдущему оратору - деплоймент жабских приложений - гемор первостатейный. Ежели это великий утиль вроде Эклписа - оно терпимо, но вот простые программки делать, так чтобы их мог запустить не обученный специально юзер - та еще радость

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


[info]ppkk
2008-04-30 17:51 (ссылка)
Да, я тут, не получив быстро ответа, разнервничался и стал ко всем приставать с альтернативными результатами.

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


[info]qwerty
2008-04-30 20:45 (ссылка)
Я же приложений не пишу и вообще моя жаба встроенная. Если у тебя есть конкретные пожелания, могу из передать в правильные руки.

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


[info]ppkk
2008-04-30 21:49 (ссылка)
Несмотря на то, что я Яве добра не желаю: хотя бы "динамическую" кучу, чтобы программы не вылетали без доп. настроек (типа ключа -Xmx…). Если это слишком сложно для корпорации, то хотя бы стандарт для пожеланий типа упомянутых .jad (в .jar архиве как файл, для одинокого .class — ещё как-нибудь), как я понял, но для всех Яв, не только мобильной.

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


[info]qwerty
2008-04-30 22:15 (ссылка)
Куча и без того динамическая, а максимальный размер при виртуальной памяти знать нужно. Небось, проще всего раз и навсегда поправить в JAVA_OPTS или еще как. Или чтобы дефолты были побольше. Чтобы инсталлятор менял дефолты под компутер - таке в планах у них уж год.

Нет, .jad - это текстовый манифест сбоку от .jar. Его не виртуальная машина читает.

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


[info]ppkk
2008-04-30 23:08 (ссылка)
Куча и без того динамическая, а максимальный размер при виртуальной памяти знать нужно.
???

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


[info]qwerty
2008-04-30 23:48 (ссылка)
Ведь не хочется, чтобы замусоренная куча сначала была отсвоплена, а потом в ней началась сборка мусора?

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


[info]kouzdra
2008-04-30 23:54 (ссылка)
Честно говоря O'Caml и бемовский коллектор как-то без этих ужасов обходятся.

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


[info]qwerty
2008-05-01 00:38 (ссылка)
Наверно, более разумные умолчания. Можно еще попытаться медитировать на вынюковые счетчики производительности, но как-то это сомнительно.

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


[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 (ссылка)
В серверном варианте уж больше года как есть.

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


[info]ppkk
2008-05-02 00:30 (ссылка)
Честно говоря, это, по-моему, означает, что надо собирать мусор, когда приходит пора использовать жёсткий диск (естественно, с установкой, чтобы не производить её повторно слишком быстро). Я неправильно понимаю сущность сборки мусора, или её свойство в том, что она может происходить в любой момент?

Ответ только сделал ситуацию непонятнее.

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


[info]qwerty
2008-05-02 03:15 (ссылка)
ОС, однако, не извещает приложение о свопинге. И вообще в системе много процессов, каждый из которых может хотеть память.

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

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


[info]ppkk
2008-05-02 10:43 (ссылка)
(следующий комментарий учтён)

ОС, однако, не извещает приложение о свопинге.
Но отследить, какие страницы сброшены на медленную память ведь можно?
Да и заблокировать страницы против их сброса на медленную память тоже можно.
Если для Явы самое страшное — возможное торможение из-за возможного переноса в медленную память, то можно выделять память "по понятиям" (типа меньшего из 32 Мб и 10% свободной) и блокировать её от сброса, когда памяти не хватит, — собрать мусор, если собралось немного, — выделить ещё памяти, когда проснётся совесть, начать выделять память без блокировки сброса в медленную.

В общем, лучше бы медленнее сортировали строки.

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


[info]qwerty
2008-05-02 11:19 (ссылка)
По-моему, лучше бы умолчательные параметры устанавливали в более разумные.

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


[info]qwerty
2008-05-02 03:21 (ссылка)
Насчет мест сборки мусора вру - в принципе, где угодно, на самом же деле только когда все нитки в GC-safe поинтах, которые определяются реализацией.

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

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


[info]ppkk
2008-05-02 10:12 (ссылка)
А, ну я тогда правильно предполагал: в остальных местах тоже можно, только придётся не просто остановить программу, но и как-то нетривиально её перестраивать.

По-хорошему алгоритм и параметры по умолчанию должны быть такими, чтобы о них не нужно было знать.
Проблеме с вылетом из-за нехватки памяти приложений, которые не снабжены тем, о чём я изначально написал (в Окнах: установщиком, обёрткой в виде .exe файла, который следит за тем, что установлена правильная версия JRE и вызывает исполнение с правильными параметрами), очень много лет.

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


[info]qwerty
2008-05-02 11:17 (ссылка)
Собственно, а почему бы вам такую программу не написать? Код жабы, кажется, уже открыт. Теоретически возможно к нему приложить любую программу с открытым кодом под GPL2. Если программа окажется полезной. народ за нее проголосует и станет вместе с жабой распространять. Передать пожелание я могу, но сильно сомневаюсь, что на него откликнутся. Оно, вероятно, полезное, но не интересное :-) Я сам десктопных жаб не пишу. Моя мобильная стандарта CLDC 1.1. Максимальный размер кучи у нее по умолчанию 1 МБ.

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


[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 (ссылка)
Про сортировку я ещё имел в виду, что "быстрая сортировка" лично мне не нравится: нужны ловкости для снижения вероятности квадратичного времени и т.п. Какой-нибудь вариант сортировки кучей, что-нибудь такое, может быть лучше.

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


[info]ifp5
2008-05-22 19:50 (ссылка)
При всех своих достоинствах для десктопа жаба умерла навсегда. Потому как юзеров, способных хотя бы скачать и поставить JRE, сейчас примерно 0.01% от общего количества :>

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


(Анонимно)
2008-09-08 16:17 (ссылка)
Неэквивалентный код для с++ сравниваете. Во-первых, короткие строки в с++ хранятся inplace и их сортировка дорого обходится, надо сортировать указатели. А во-вторых с++ сортировка использует только отношение <, а не функцию compare, возвращающую <,=,>.


int compare( const void* a, const void* b )
{
const std::string* lhs = (const std::string*)a;
const std::string* rhs = (const std::string*)b;
return strcmp(lhs->c_str(),rhs->c_str());
}
void test ()
{
std::vector<std::string> v (n);
std::vector<std::string*> vp (n);
char buf [20];
for (int i = 0; i != v.size (); ++ i)
{
sprintf (buf, "%d", i);
v [i] = std::string (buf);
vp[i]=&v[i];
}
qsort(&vp[0],n,sizeof(std::string*),compare);
}

(Ответить)