Пишу программы по обработке данных,
данных — сотни гигов, перемалывать нужно очень быстро, потоковая скорость должна быть 10MB/sec, а лучше еще больше.
Не могу достичь нормальной скорости из-за crt-шных функций типа sprintf/sscanf и т.п.
Работать нужно с double:
sprintf(stroke, "%.2lf %.2lf %.2lf ...", ...);

sscanf можно заменить atof-ом: он быстрее на 20%, но это не сильно помогает.
Переписал частично sscanf/sprintf числодробилками — получил прирост скорости в два раза, но все равно в итоге
около 5.5 MB/sec получается — мало
Подскажите пожалуйста какие функции лучше использовать, если не трудно, то с примерами кода.

Здравствуйте, balearic chill, Вы писали:

BC>Пишу программы по обработке данных,
[skiped]
BC>около 5.5 MB/sec получается — мало
BC>Подскажите пожалуйста какие функции лучше использовать, если не трудно, то с примерами кода.

а что по этому поводу профилер говорит?

Здравствуйте, balearic chill, Вы писали:

попробуй strtod

BC>Пишу программы по обработке данных,
BC>данных — сотни гигов, перемалывать нужно очень быстро, потоковая скорость должна быть 10MB/sec, а лучше еще больше.
BC>Не могу достичь нормальной скорости из-за crt-шных функций типа sprintf/sscanf и т.п.
BC>Работать нужно с double:
BC>sprintf(stroke, "%.2lf %.2lf %.2lf ...", ...);

Интересно, в каком месте программы понадобилась скорость от этих функций? Ведь в вычислениях они не нужны, а при выводе результатов большая скорость не требуется... При вводе же я сомневаюсь, что sscanf работает медленнее, чем винт выдает ей данные.

Здравствуйте, balearic chill, Вы писали:

BC>Пишу программы по обработке данных,
BC>данных — сотни гигов, перемалывать нужно очень быстро, потоковая скорость должна быть 10MB/sec, а лучше еще больше.
BC>Не могу достичь нормальной скорости из-за crt-шных функций типа sprintf/sscanf и т.п.
BC>Работать нужно с double:
BC>sprintf(stroke, "%.2lf %.2lf %.2lf ...", ...);

BC>sscanf можно заменить atof-ом: он быстрее на 20%, но это не сильно помогает.
BC>Переписал частично sscanf/sprintf числодробилками — получил прирост скорости в два раза, но все равно в итоге
BC>около 5.5 MB/sec получается — мало
BC>Подскажите пожалуйста какие функции лучше использовать, если не трудно, то с примерами кода.

Попробуйте написать конечный автомат. Это самый быстрый способ перевода. Если уж совсем критично — реализовать автомат на ассемблере — ничего быстрее в принципе не может быть. Единственное улучшение может получится, если использовать какую-нить специфику чисел. Есть специфика?

http://www.rsdn.ru/article/?alg/checkStr.xml

Автор(ы): Николай Меркин
Дата: 19.01.2002

balieric chill

а представление данных в текстовом виде -- обязательное условие?
если нет, то можно использовать read() & write().

Здравствуйте, Vamp, Вы писали:

V>http://www.rsdn.ru/article/?alg/checkStr.xml

Автор(ы): Николай Меркин
Дата: 19.01.2002

Кстати, да. Табличный метод даст 200-300% выиграша в скорости по сравнению со стандартными функциями.

Здравствуйте, Alexey Chen, Вы писали:

AC>а что по этому поводу профилер говорит?
Да меня вообще-то мало интересует что говорит профайлер — чистый поток с винта на винт у меня 60 Mb/sec,
если в промежутке появляется десяток sscanf-ов поток становится 2Mb/sec.

Здравствуйте, Kluev, Вы писали:

K>попробуй strtod

Попробовал, немного медленнее atof-a.

Здравствуйте, SWW, Вы писали:

SWW>Интересно, в каком месте программы понадобилась скорость от этих функций? Ведь в вычислениях они не нужны, а при выводе результатов большая скорость не требуется... При вводе же я сомневаюсь, что sscanf работает медленнее, чем винт выдает ей данные.

Что значит в каком месте ? Есть 200 гигов данных — географические координаты, даны допустим в проекции Меркатора,
а я это все в Ламберта перегоняю, формул в этом преобразовании — будь здоров, но все же оно на порядок быстрее sscanfa
работает. Все данные — double естественно.
Сейчас засек — по времени работы один sscanf четырех double-ов ~ 100 cos-инусам ... ужас.
Про винт вообще молчу — он 60Mb/sec выдает, даже если производительность sscanf улучшить в 30 раз все равно хватит.

Здравствуйте, LaptevVV, Вы писали:

LVV>Попробуйте написать конечный автомат. Это самый быстрый способ перевода. Если уж совсем критично — реализовать автомат на ассемблере — ничего быстрее в принципе не может быть. Единственное улучшение может получится, если использовать какую-нить специфику чисел. Есть специфика?

Спасибо за первый дельный совет, в конкретной задаче специфика имеется — точность больше двух точек после запятой пока не нужна, но это пока ...
Но на написание этого автомата времени нет — работой завален просто.
Может быть классы есть готовые или библиотеки какие-нибудь автоматов ?
Господи, 2003 год на дворе, неужели никто не написал быстрых строковых функций ??!! ... не верю

Здравствуйте, hobby, Вы писали:

H>а представление данных в текстовом виде -- обязательное условие?
H>если нет, то можно использовать read() & write().

Увы, да.

Здравствуйте, Vamp, Вы писали:

V>http://www.rsdn.ru/article/?alg/checkStr.xml

Автор(ы): Николай Меркин
Дата: 19.01.2002

Большое спасибо за ссылку.

Здравствуйте, balearic chill, Вы писали:

BC>Пишу программы по обработке данных,
BC>данных — сотни гигов, перемалывать нужно очень быстро, потоковая скорость должна быть 10MB/sec, а лучше еще больше.
BC>Не могу достичь нормальной скорости из-за crt-шных функций типа sprintf/sscanf и т.п.
BC>Работать нужно с double:
BC>sprintf(stroke, "%.2lf %.2lf %.2lf ...", ...);

BC>sscanf можно заменить atof-ом: он быстрее на 20%, но это не сильно помогает.
BC>Переписал частично sscanf/sprintf числодробилками — получил прирост скорости в два раза, но все равно в итоге
BC>около 5.5 MB/sec получается — мало
BC>Подскажите пожалуйста какие функции лучше использовать, если не трудно, то с примерами кода.

Можно еще на треды поделить.
Скажем, один обрабатывает четные строчки, а другой — нечетные. Это конечно, если все строки одинаковой длины.

А может хранить все в географических координатах, хочешь в радианах, хочешь в однородных? Тогда преобразование не покажется таким уж сложным, вернее его в принципе не будет. Будет только проецирование. Или это не от тебя зависит?

Здравствуйте, balearic chill, Вы писали:

BC>Может быть классы есть готовые или библиотеки какие-нибудь автоматов ?

Прямо здесь, на этом сайте: Статьи — Алгоритмы — Конечные автоматы

вроде в boost тоже кто-то что-то такое реализовал, но я не уверен

You will always get what you always got
  If you always do  what you always did

Здравствуйте, balearic chill, Вы писали:

BC>Спасибо за первый дельный совет, в конкретной задаче специфика имеется — точность больше двух точек после запятой пока не нужна, но это пока ...

Так по специфике можно не слабо заточить
(и без автоматов — там выигрыш по данным автора меньше чем в 10 раз)

Например такой дубовый (не самый оптимальный ) код (без проверок — специфика ведь ):

double fn(char* sz)
{
    for( double dH = 0; *sz; sz++ )
    {
        if( *sz == '.' )
        {
            sz++;
            break;
        }
        dH *= 10;
        dH += (*sz) - '0';
    }
    for( double dL = 0, d = 1.0; *sz; sz++ )
    {
        d /= 10;
        dL += ((*sz) - '0') * d;
    }
    return dH+dL;
}

//...
double d;
for( int c=1000000; c--; )
    d = fn("1.23456");

работает почти в 100 раз быстрее (на VC6 release, 4-й пень), чем:

double d;
for( int c=1000000; c--; )
    sscanf( "1.23456", "%lf", &d );

Здравствуйте, Анатолий Широков, Вы писали:

АШ>А может хранить все в географических координатах, хочешь в радианах, хочешь в однородных? Тогда преобразование не покажется таким уж сложным, вернее его в принципе не будет. Будет только проецирование. Или это не от тебя зависит?

Преобразование написано достаточно быстро и проблем не доставляет, как я уже говорил тут: один sscanf это как сто косинусов, так что проблемы не в косинусах, а в sscanf-aх. Буду я делать проецирование или преобразование — это неважно, scanf-ом/printf-ом все равно придется воспользоваться.
На выходе должна получаться вполне определенная система координат, ТЗ есть ТЗ.

Здравствуйте, YVR, Вы писали:

YVR>Так по специфике можно не слабо заточить
YVR>(и без автоматов — там выигрыш по данным автора меньше чем в 10 раз)
YVR>Например такой дубовый (не самый оптимальный ) код (без проверок — специфика ведь ):
YVR>...
YVR>работает почти в 100 раз быстрее (на VC6 release, 4-й пень), чем:
YVR>...

Ну последние два дня я только и занимаюсь что по специфике затачиваю, а в автоматах я разачаровался — в тексте про проверку флоатов/емэйлов который мне порекомендовали, автор сравнивает производительность sscanfa который все же
число вычисляет, с производительностью своей процедурки верификации, которая только да/нет выдает ...
после чего с гордостью обнаруживает большое превосходство по скорости ... герой, блин.
Есть более серьезные примеры на автоматы, но я по их внешнему виду вижу что все это тормозить будет.

За код Вам спасибо, у меня примерно то же самое только еще более специфичное: точку не ищу, потому что знаю где она,
ну и еще там по мелочи ... на процентов 7 мой вариант всего лишь быстрей.
Переписал и sscanf и sprintf даже без str* функций (они оказывается тоже тормозят заразы), только memcpy не стал
переписывать (понадеюсь что хотя бы в ней MS не лажанулась).

Вот две базовые функции (через них FastSscanf и FastSprintf работают, но там специфика — неинтересно):

// предполагаем что пробелы есть
long FastAtol(char *s) {
 long sign = 1, res = 0, i = 0;
 while(s[i] == ' ') i++;
 if(s[i] == '-') { i++; sign = -1; }
 while(s[i] != ' ' && s[i] != NULL) {
  res *= 10;
  res += s[i++] - '0';
 }
 return sign*res;
}

// возвращаем кол-во символов в s, полезно чтобы потом не тратить время на strlen
long FastLtoa(char *s, long n) {
 char temp[20];
 long i = 19, pos = 0;
 if(n < 0) { s[0] = '-'; pos = 1; }
 if(n < 10)  { s[pos] = (char)n + '0'; s[pos+1] = NULL; return pos+1; }
 if(n < 100) { s[pos] = (char)(n/10) + '0'; s[pos+1] = (char)(n%10) + '0'; s[pos+2] = NULL; return pos+2; }
 do {
  temp[i--] = (char)(n%10) + '0';
  n /= 10;
 } while(n);
 while(i <= 18) s[pos++] = temp[++i];
 s[pos] = NULL;
 return pos;
}

Кстати на P4, VC.NET производительность всего в 50 раз больше, а не в 100, может из-за оптимизации, не знаю.