JavaScript в Firefox/Wine работает быстрее чем в Firefox/Linux

вылезай из танка, qt 4.5 под lgpl

Ну и? Тут дело не в языках вообще-то. Давай теперь сравним qsort и std::sort. Или map с sys/tree.h, последний сравняется по производительности с map'ом только если написать собственный аллокатор.

Ну да, ну да... Начинается. Итак, STL плохое и тормозное. Что быстрое и хорошее-то? Из библиотек общего пользования, пожалуйста, а не что-то специфичное для узкого круга задач. Вот для обычного двусвязного списка с указателем на конец (std::list в STL, TAILQ в sys/queue.h) хочу хорошую и быструю библиотеку на плюсовке.

Про std::list и sys/queue.h мне что-то слабо верится. Чую тест был из разряда тех, что делают по ссылке в сабже или на форониксе.

Без аллокатора sys/queue.h должен был слить. Поэтому либо показывай код и рассказывай как и чем собирал либо кончай 3.14здить.

#include <sys/queue.h>
#include <list>
#include <iostream>

struct clist {
    int value;
    TAILQ_ENTRY(clist) link;
};

int
main()
{
    struct timeval begin, end;
    time_t sec, usec;
    
    std::list<int> cpplist;

    gettimeofday(&begin, NULL);
    for (int i = 0; i < 1000000; i++)
        cpplist.push_back(i);
    gettimeofday(&end, NULL);
    sec = end.tv_sec - start.tv_sec;
    usec = end.tv_usec - start.tv_usec;
    if (usec < 0) {
        sec--; usec += 1000000;
    }
    std::cout << "cpplist insert: " << sec << "s " << usec << "u\n";

    TAILQ_HEAD(, clist) c_list = TAILQ_HEAD_INITIALIZER(c_list);
    gettimeofday(&begin, NULL);
    for (int i = 0; i < 1000000; i++) {
        struct clist *elm = malloc(sizeof(elm));
        elm->value = i;
        TAILQ_INSERT_TAIL(&c_list, elm, link);
    }
    gettimeofday(&end, NULL);
    sec = end.tv_sec - start.tv_sec;
    usec = end.tv_usec - start.tv_usec;
    if (usec < 0) {
        sec--; usec += 1000000;
    }
    std::cout << "c_list insert: " << sec << "s " << usec << "u\n";

    return 0;
}

gcc -O2

Удаление списка остаётся для домашнего упражнения, равно как и прочие операции.

Ну что, продолжаем дальше 3.14здить про быстроту C++ на уровне plain C, или наконец признаём, что плюсовка по факту тормознее чистого С, что с ней не делай (кроме делания из неё чистого С, есесна)?

Плюсовка и так тормознее. А С тормознее чем асм. А еще круче наверно сразу машинный код писать. Зато ++ функциональней и, что пожалуй важнее, на нем писать в разы быстрее.

Вы бы хоть код для проверки сначала попробовали собрать, прежде чем постить с ошибками.

Попробовали собрать, потом понаписали аллокаторов для плюсовки, потом stl переписали? Нафиг оно мне надо. Написал по памяти, идея понятна.

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

> Жава не нужна. Ни сама, ни жаваскрипт.

ололо,
не говорите так никогда.

жабаскрипт (в отличие от жабы) - это так-сказать Ц веба.
Только на нём можно написать гуи не уступающие десктопным приложениям (на базе YUI, например), всякие там спредшиты с редакторами в каждом селе, инкрементальными апдейтами и прочее.
Например, селлов - десятки-сотни тысяч и такое количество DOM-элементов убило-бы браузер. На жабоскрипте-же можно делать умную подгрузку того что видит юзер и только.
Потом жабаскрипт - единственный функциональный язык реально работающий в индустрии (только на нём никто писать правильно не может: пишут примитивные функции по традиции).
Знаю конторы которые имеют практически аналоги екселей на вебе (что возможно сделать только жабаскриптовыми манипуляциями css).

> Попробовали собрать, потом понаписали аллокаторов для плюсовки, потом stl переписали? Нафиг оно мне надо.

Позволю ответить вам вашими словами: Нафиг оно мне надо.
Просто не люблю подобную халатность, я конечно исправил косяки в коде и никаких алокаторов не писал (боже упаси). Кстати там не в 2 раза, в 1,5 примерно у меня вышло :) По честному надо указывать версию компилятора и железо, но мы конечно телепаты и поэтому это мелочи.

> Написал по памяти, идея понятна.

Конечно. А я вот когда-то давно тестировал скорость std:sort c std:vector и С-шный qsort и там qsort проиграл, ощутимо, не 2 раза, но что-то на 20% если не изменяет память. Ваш пример не убедителен. Идея понятна?

Если что, я не говорил, что С++ быстрей С , я всего лишь сказал про ошибки в коде ;)

ещё послушайте Крокфорда (полно роликов на вебе с лекциями по правильному жабаскрипту).
Щас вообще тенденция: гугле докс, вебмейлы - всё на "асинхронном жабаскрипте".

> Попробовали собрать, потом понаписали аллокаторов для плюсовки, потом stl переписали? Нафиг оно мне надо. Написал по памяти, идея понятна.

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

cpplist insert: 0s 47844u c_list insert: 0s 49553u

> По честному надо указывать версию компилятора и железо, но мы конечно телепаты и поэтому это мелочи.

Все претензии к аффтару слов про то, что С++ не тормознее С. Имею право взять хоть Turbo C 3.1 (или какой он там был во времена далёкой юности?) и сравнить с gcc 4.3 с оптимизацией под c2d. 8))

В данном случае был, емнип, как раз последний. В любом случае, это было для умных людей повод задуматься (в том числе и над абсолютными значениями и разницей в трудозатратах), остальные могут буквоедствовать. 8))

> Конечно. А я вот когда-то давно тестировал скорость std:sort c std:vector и С-шный qsort и там qsort проиграл, ощутимо, не 2 раза, но что-то на 20% если не изменяет память. Ваш пример не убедителен. Идея понятна?

Нет, не понятна.

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

Зато на плюсах обычно быстрее писать, и порог вхождения пониже будет.

> Зато на плюсах обычно быстрее писать, и порог вхождения пониже будет.

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

Врунишко, иди проспись уж наконец. 8)))) Я-то хоть сразу сказал, что конкретно в этом примере конкретно с -O2 плюсовка сливает не в 2 раза, перепутал. А ты что-то совсем заврался, посиди без сладкого. 8))))

kemm@nova:~$ g++ -O2 -o t t.c
kemm@nova:~$ ./t
cpplist insert: 0s 74647u
c_list insert: 0s 63038u
kemm@nova:~$ ./t
cpplist insert: 0s 70215u
c_list insert: 0s 61564u
kemm@nova:~$ ./t
cpplist insert: 0s 70407u
c_list insert: 0s 65410u
kemm@nova:~$ ./t
cpplist insert: 0s 71184u
c_list insert: 0s 62606u
kemm@nova:~$ ./t
cpplist insert: 0s 70375u
c_list insert: 0s 61537u
kemm@nova:~$ ./t
cpplist insert: 0s 70509u
c_list insert: 0s 63632u
kemm@nova:~$ ./t
cpplist insert: 0s 70740u
c_list insert: 0s 62211u
kemm@nova:~$ ./t
cpplist insert: 0s 70295u
c_list insert: 0s 61766u
kemm@nova:~$ ./t
cpplist insert: 0s 71207u
c_list insert: 0s 63358u
kemm@nova:~$ ./t
cpplist insert: 0s 70044u
c_list insert: 0s 66170u
kemm@nova:~$ ./t
cpplist insert: 0s 75945u
c_list insert: 0s 65656u
kemm@nova:~$ g++ --version
g++ (Gentoo 4.3.3 p1.0, pie-10.1.5) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
Это свободно распространяемое программное обеспечение. Условия копирования
приведены в исходных текстах. Без гарантии каких-либо качеств, включая
коммерческую ценность и применимость для каких-либо целей.

> По определению.

Свое "определение" можешь засунуть себе в жопу. Пока ты позорно слил со своим тестом.

Уровень _вхождения_ -- ниже. Уровень _владения на уровне_ выше.

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

Деточко, проспись и перестань позорно врать.

Из нас двоих соврал только ты про "в два раза". Два раза я не увидел. На моей машине плюсы оказались на пару процентов быстрее.

Позорище, ты в цикле поставь 100000000 и посмотри на "скорость Си":

cpplist insert: 4s 789448u c_list insert: 42s 888017u

Я же говорил, что без аллокатора sys/queue.h и прочее неюзабельно. Если прикрутить аллокатор, то скорость будет примерно одинакова.

Глаза протри, врунишка. Про "в два раза" я ещё до твоих бредней говорил, что перепутал.

На твоей машине, твоим компилятором... На моей моим компилятором плюсовка сливает. И всегда будет сливать. И никуда ей не дется от этого факта.

> На твоей машине, твоим компилятором... На моей моим компилятором плюсовка сливает. И всегда будет сливать. И никуда ей не дется от этого факта.

У тебя какая-то особенная машина и особенный компилятор. Ты бы разобрался чтоль в причинах для начала, а потом бы постил сюда эту ахинею. Си++ видите ли виноват.

Мне не нужно 100000000, мне нужно 1000000. Кто-то тут бредил, что С и С++ одинаковы по производительности.

Ещё раз: да, теоретически добиться на плюсовке той же производительности в большинстве случаев можно, но зачастую это сопровождается потерей львиной доли привлекательности плюсовки. Увы и ах. Любой переход на более высокий уровень заставляет терять в скорости работы, но выигрывать на скорости разработки. По определению. Свои анальные фантазии можешь оставить при себе.

Ты б сначала сам бы головой подумал прежде чем бредить. Я прекрасно знаю, почему плюсовка тут сливает, прекрасно знаю, где и почему она не будет сливать тупого решению в лоб на С, но сольёт умному. Но в итоге сольёт она всегда. Правда, в большинстве случаев это не важно.

OpenOffice по ощущениям тоже как-то быстрее на XP пашет. Что-то чем дальше в лес, тем "тяжелее" софт. А вообще w3m - наше все!

У с++ линкер грузит плюсовую стандартную либу, которая гораздо больше. А ты это не учитываешь. А темплейты не тормозят вообще. На интеловском компиляторе так точно. Это было главное к ним требование при введении в стандарт. В ИСО комитете сидят сумашедшие идиоты эбедедщики, которые боятся даже малейшего замедления по сравнению с С.

> Имею право взять хоть Turbo C 3.1 (или какой он там был во времена далёкой юности?)

Turbo C 3.1 не существовало, существовал Borland C++ 3.1
http://en.wikipedia.org/wiki/Turbo_C
Лично я начинал с Turbo C++ 1.0, иногда натыкался на Turbo C 2.0
Но это так, вспомнилось студенчество.

> Нет, не понятна.

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

> Ещё раз: С++ тормознее С. По определению.

Мне тесты лень писать. Но вы можете заглянуть вот сюда: http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=gcc&...

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

Вообще по моему опыту в большинстве случаев "чистый" С быстрей С++, но конечно не в разы, в разы это если руки кривые или компилятор. Другое дело, что когда люди увлекаются слишком сильно ООП и высокими материями в С++, то про высокую скорость часто не приходится говорить, вот и имеем ... то, что имеем.

>Вообще по моему опыту в большинстве случаев "чистый" С быстрей С++, но конечно не в разы, в разы это если руки кривые или компилятор. Другое дело, что когда люди увлекаются слишком сильно ООП и высокими материями в С++, то про высокую скорость часто не приходится говорить, вот и имеем ... то, что имеем.

Дык.. о том и речь. Конечно если выкинуть из С++ кода всё ООП и все фичи из за которого оно собственно и ++, то скорость будет фактически одинаковая. Правда либы больше весят. Какой только смысл таким образом использовать С++ когда есть С?

Дайте угадаю, вы фанат гтк и гнома?)

А если серьезно, то в С++ те самые ++ это не только ООП. И даже его, ООП, можно использовать так, что оно не будет тормозить. Если что, STL, упомянутый здесь, надо очень аккуратно использовать, а это требует большего опыта и знаний, чем у большинства начинающих С++ кодеров. Лично я не считаю STL совершенством и по уму его можно было давно улучшить в разы, но стандарты они такие стандарты ...

дело в том, что вы кладёте просто числа, а чуть дело коснётся какого-нибудь узкого места, кастом алгоритма - из Ц можно выжать много (а генерик фреймвок - сольёт просто потому что он фреймвок и там производится куча ненужных проверок - для тех случаев которые может никогда в данной задаче не встретятся). Поэтому надо всегда думать - а какой процент фич мне действительно будет нужен.
Вот например, я знаю что скажем в серч-энджине хешироваться будут человеческие слова, а чел. язык - сильно избыточен и алгоритм Бернштейна почему-то наиболее подходящ для равномерного распределения по хеш-бакетам. А стдлиб Map - я не знаю какой алгоритм использует и может и не Бернштейна вовсе (или будет делать кучу проверок at runtime: idle cycles). Эта моя эвристика/знание - может дать мне преимущество во много раз.

Например, в посланных ниже тестах - Ц++ слил более чем в 3 раза на чтении из хеша (+22% - при чтении из файла и загрузке).

Это без оптимизаций, потратив всего полдня на написание хеша (а полдня - ничто на самом деле - если речь идёт о важной для проекта функциональности и вообще важном проекте).
Можно заточить ещё сильнее (чего не получится с мапом для общих целей).

за код прошу не пинать - знаю что куча натянутостей, отсутствие проверок и пр. (в продакшене можно потратить ещё полня на долизывание)

$ g++ -O2 -o map map.cpp
$ ./map
records loaded in 0.233988
records red in 0.67486

$ gcc -O2 -o mapc map.c
$ ./mapc
records loaded in 0.177162
records red in 0.183764

#include <map>
#include <string>
#include <iostream>
#include <fstream>
#include <sys/time.h>

using namespace std;

int main() {
map<string, string> hash;
string line;
struct timeval start, middle, end;
time_t s,ms;

gettimeofday(&start, NULL);

ifstream in("dict");
while (in >> line) {
hash[line]=line;
}
gettimeofday(&middle, NULL);
s = middle.tv_sec - start.tv_sec;
ms = middle.tv_usec - start.tv_usec;
if(ms<0){ s--; ms+=1000000; }

cout << "records loaded in " << s << "." << ms << "\n";

for(int i=0; i<10000; i++) {
hash["abracadabra"];
hash["vasya"];
hash["test"];
}
gettimeofday(&end, NULL);
s = end.tv_sec - middle.tv_sec;
ms = end.tv_usec - middle.tv_usec;
if(ms<0){ s--; ms+=1000000; }

cout << "records red in " << s << "." << ms << "\n";

return 0;
}

#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#include <errno.h>


#define MAX_MAPPING_FILE_LINE 1024
#define MAX_KEY 1024

#define OUT_OF_MEM() { \
fprintf(stderr, "Out of memory: %s:%d", __FILE__, __LINE__); \
exit(-1); \
}


typedef struct hash_bucket{
char* key;
void* data;
struct hash_bucket* next;
} hash_bucket;

struct hash{
long size; /* table size */
long n; /* current number of entries */
long used; /* number of used elements */
hash_bucket** table;
char name[256]; /* hashname */
};


/* berkeley DB algorithm (V.G.: I've got 0 collisions populating English words (dict)
and 70 colisions - with Bernstein algorithm, so I'm using the 1st one) */
static unsigned long calc_hash(char* str){

unsigned long hash = 0;
int c;

while ((c = *str++))
hash = c + (hash << 6) + (hash << 16) - hash;

return hash;
}


struct hash* hash_create(long size){

struct hash* table;
hash_bucket** bucket;
long i;

table = (struct hash*)malloc(sizeof(struct hash));
if(table == NULL){
OUT_OF_MEM();
}

if (size <= 0){
free(table);
return NULL;
}

table->size = size;
table->table = (hash_bucket**)malloc(sizeof(hash_bucket*) * size);
if(table->table == NULL)
OUT_OF_MEM();

bucket = table->table;

if (bucket == NULL) {
free(table);
return NULL;
}

for (i = 0; i < size; i++)
bucket[i] = NULL;

table->n = 0;
table->used = 0;

return table;
}


void* hash_put(struct hash* table, char* key, void* data){

unsigned long val = calc_hash(key) % table->size;
hash_bucket* bucket;

if ((table->table)[val] == NULL) {
bucket = (hash_bucket*)malloc(sizeof(hash_bucket));
if (bucket == NULL)
OUT_OF_MEM();

bucket->key = strdup(key);
bucket->next = NULL;
bucket->data = data;

(table->table)[val] = bucket;
table->n++;
table->used++;

return bucket->data;
}

for (bucket = (table->table)[val]; bucket != NULL; bucket = bucket->next)
if (strcmp(key, bucket->key) == 0) {
void* old_data = bucket->data;

bucket->data = data;

return old_data;
}

bucket = (hash_bucket*) malloc(sizeof(hash_bucket));
if (bucket == NULL)
OUT_OF_MEM();

bucket->key = strdup(key);
bucket->data = data;
bucket->next = (table->table)[val];

(table->table)[val] = bucket;
table->n++;

return data;
}

void* hash_get(struct hash* table, char* key){

unsigned long val = calc_hash(key) % table->size;
hash_bucket* bucket;

/* printf("getting attempt %s<\n", key); */

if ((table->table)[val] == NULL)
return NULL;

for (bucket = (table->table)[val]; bucket != NULL; bucket = bucket->next)
if (strcmp(key, bucket->key) == 0)
return bucket->data;

return NULL;
}


static int read_mapping(const char *filepath, struct hash *map){

FILE *fp = NULL;
char line[MAX_MAPPING_FILE_LINE];
char *delim;
char *valStart;
long lineNum = 0;
long len;
char key_buffer[MAX_KEY + 1];
char val_buffer[MAX_MAPPING_FILE_LINE + 1];


if ((fp = fopen(filepath, "r")) == NULL){
printf("Cannot read %s\n", filepath);
return -1;
}

errno=0;

while(fgets(line, sizeof(line), fp) != NULL){

if(errno){
fprintf(stderr, "Can't read from file %s: %s\n", filepath, strerror(errno));
exit(-1);
}

if(line[sizeof(line)-1] == '\n')
line[sizeof(line)-1] = '\0';

len = strlen(line);

if(len == 0){
fprintf(stdout, "WARN: line %ld is empty -- ignored" ,lineNum);
continue;
}

strcpy(key_buffer, line);
strcpy(val_buffer, line);

hash_put(map, strdup(key_buffer), strdup(val_buffer));

}/* fgets */

errno=0;

fclose(fp);

if(errno)
fprintf(stderr, "Can't close file descriptor %s: %s\n", filepath, strerror(errno));

return 0;
}


int main(void){
struct hash* map;
struct timeval start, middle, end;
time_t s,ms;
int i;

gettimeofday(&start, NULL);

map=hash_create(100000);
read_mapping("./dict", map);

gettimeofday(&middle, NULL);
s = middle.tv_sec - start.tv_sec;
ms = middle.tv_usec - start.tv_usec;
if(ms<0){ s--; ms+=1000000; }

printf("records loaded in %d.%d\n", s, ms);

for(i=0; i<10000; i++) {
hash_get(map, "abracadabra");
hash_get(map, "vasya");
hash_get(map, "test");
}

gettimeofday(&end, NULL);
s = end.tv_sec - start.tv_sec;
ms = end.tv_usec - start.tv_usec;
if(ms<0){ s--; ms+=1000000; }
printf("records red in %d.%d\n", s, ms);

return 0;
}

$ head dict
a
A
AA
AAA
Aachen
aardvark
Aaren
Aarhus
Aarika
Aaron

$ cat dict | wc
62074 62074 547509

$ uname -a
Linux compaq 2.6.18-6-amd64 #1 SMP Tue Aug 19 04:30:56 UTC 2008 x86_64 GNU/Linux

алгоритм Бернштейна:

static unsigned long calc_hash(char* str){

unsigned long hash = 0;
int c;
while ((c = *str++))
hash = c + (hash << 6) + (hash << 16) - hash;
return hash;
}

кстати, знание эвристик и их использование - это единственная возможность сделать быстро обучаемую/сходящуюся нейросеть или например шахматы, обыгрывающие Каспарова (просто минимакс - туп). И нужную эвристику (которую хороший программер должен чуствовать) для задачи - даст разницу не на проценты, а на разы, что уже очень важно.
Ещё пример - несколько крупных биржевых аппликаций написаны на... асме. Казалось бы - самоубийцы (не одно узкое место, а вся аппликация!)
Потому что если есть стоящий проект (а не быдлопроект который надо быстро сляпать и всунуть заказчику), который будет жить долго и в котором перформанса в любом случае слишком много не будет - написать нужные алгоритмы, оптимизированное под задачу - совсем даже не оверхед. Наоборот - больше контроля.
Ну а программеры конечно-же любят писать фреймвоки для других - хлебом не корми (это же их работа). Важно - не ленится, не хавать всё подряд, где легче, а думать о каждой задаче природе её данных отдельно.

>а во-вторых Крон говрил, что у него наоборот в генте тормознее.

Да, когда-то у меня на равном железе под Убунтой Фокс намного быстрее стартовал (секунды 3 против 5-7) и пошустрее работал. Сейчас сравнить не могу, так как железо и загрузка машин у Gentoo и Ubuntu-десктопов сильно разная. На C2Q-6600/4Гб Firefox в Gentoo летает :)

>Не было у меня этой проблемы, независимо от рус./лат.

Воистину эпохально! :D

>Байки из склепа. Лучше старого gcc, хуже нового, как обычно. Проверено неоднократно, что на gcc грешить - дураком оказаться.

Старые и новые - это какие конкретно? А то у меня банальный gzip после icc 10.1.018 работал на 13% быстрее, чем в gcc 4.1.2: http://www.linux.org.ru/jump-message.jsp?msgid=3172469&cid=3172756

>OpenOffice по ощущениям тоже как-то быстрее на XP пашет.

Зато GIMP под Linux намного быстрее, чем под Windows :)

сорри, тормознул (запаматовал совсем - давно не использовал): вышеприведённый алгоритм - это алгоритм беркли ДБ, а бернштейновский я забраковал, проведя тесты с английскими словарями на коллизии.
Т.е. назвал не правильно, каюсь. (Вспомнил, прочитав свой-же каммент - после копипасты).

Ещё один аргумент в пользу полного контроля над кодом и алгоритмами ;)

Я там, как бе, один бинарник использую, что для плюсовки, что для сей.

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

> Turbo C 3.1 не существовало, существовал Borland C++ 3.1

Да фиг с ним... Что я, все константы помнить должен?! 8))

> Из тамошних тестов не следует большого преимущества С над С++. Конечно там только числодробительные тесты, но ведь именно такой тест и у вас. Кстати там есть тесты, где С сливает С++, а вы говорите ...

Ну, дык, эта, типа... У меня и не числодробилка. На числодробилке результаты будут близки даже у джавы (если правильно тесты проводить, а не как некоторые (http://alextutubalin.livejournal.com/136608.html) сравнивают жабу с вычислениями на float, где все данные в кеш лезут с fftw на double, где они уже, очевидно, не помещаются). В любом случае, отставание С возможно только в том случае, если не сделали как минимум аналогичных хитростей тем, которые делаются в плюсовке.

> конечно не в разы, в разы это если руки кривые или компилятор

Есесна, что в разы получается только на кривых руках. Как пример -- очистка того же stl'ного контейнера, в котором не инты, а что-нибудь посуровее, типа shared_ptr, да на какой-нибудь классик, в котором самом пара контейнеров с shared_ptr и далее... Сишнику тут сразу видно, что фигня-с будет, если тупо последовательно элементы очищать. В итоге сразу же как-нибудь вывернется. Начинающий плюсовщик же спокойно влепит container.clear(), ога. 8)) Потом начнёт городить примерно то же, что и сишник, после нагоняя от начальства. 8))

> Есесна, что в разы получается только на кривых руках. Как пример -- очистка того же stl'ного контейнера, в котором не инты, а что-нибудь посуровее, типа shared_ptr, да на какой-нибудь классик, в котором самом пара контейнеров с shared_ptr и далее...

если не в разы - тогда почему вышеприведённый код с std:map доступается в ~4 раза медленнее чем написанный ручками под задачу хэш? (я уверен что можно ещё поиграть: циклы там развернуть, буфера подтюнить и пр. что в случае Ц скорее всего ещё неплохо увеличит скорость, а имплементацию std:map'а я просто не контролирую - не могу ничего сделать).

Вот этот доступ: никаких там деаллокаций нет:

for(i=0; i<10000; i++) {
hash_get(map, "abracadabra");
hash_get(map, "vasya");
hash_get(map, "test");
}
vs
for(int i=0; i<10000; i++) {
hash["abracadabra"];
hash["vasya"];
hash["test"];
}

Гы-гы-гы,

сделал прикола ради на жабе.

$ javac Map.java
$ java Map
records loaded in 1074ms
records red in 116ms

код ниже (и как-же всё-таки быстро и просто писать на жабе!)

результаты объясняются следующим:
чтение из файла понятно - в ~6 раз медленнее чем на Ц и в ~4 - чем ЦПП.
Но чтение из хеша - быстрее чем в Ц (по причине рантайм оптимизации жаст-ин-тайм компилятора, я так понимаю). Может при неповторяющихся ключах будет иной результат.

import java.io.*;
import java.util.*;


public class Map{


public static void main(String[] args){
try{
long t0 = System.currentTimeMillis();
Properties hash = new Properties();
hash.load(new BufferedInputStream(new FileInputStream("./dict")));

System.out.println("records loaded in " + (System.currentTimeMillis()-t0) + "ms");
t0 = System.currentTimeMillis();

for(int i=0; i<10000; i++) {
hash.get("abracadabra");
hash.get("vasya");
hash.get("test");
}

System.out.println("records red in " + (System.currentTimeMillis()-t0) + "ms");

}
catch(Exception e){
e.printStackTrace();
}

}

}

>>Не было у меня этой проблемы, независимо от рус./лат. >Воистину эпохально!

Уже обсуждалось, с ~2002 это проблема официальных сборок под X11. у меня ctrl-T/Е,F/А,W/Ц работали всегда на Linux и VMS без дополнительных действий.

Специфическое решение под задачу всегда выиграет у общего, тут и говорить-то не о чем. Именно поэтому для стёба я взял std::list, а не std::map.

В плюсовке проигрыш в разы даёт обычно попытка решения "в лоб" (на которой, к слову сказать, многие и останавливаются -- большего в данной задаче не нужно может быть). Причём решение "в лоб" на плюсовке может выиграть у решения "в лоб" на сях -- как бы то ни было, stl и boost тоже не совсем идиоты писали.

$ java -version
java version "1.5.0_14"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_14-b03, mixed mode)

а почему тогда вообще не жаба? Быстрее плюсов (и даже иногда Ц - как видно из моего теста на частые доступы) - на чистом процессинге и кодить гораздо быстрее, проще найти людей. Между прочим не искуственный тест - я писал руль-енджины, где основной операцией был доступ к ассоциативным массивам (ака хеш) и вся дата, логика - всё - приходило оттуда. Писал на сях, но как я вижу сейчас - на жабе могло быть даже быстрее.
люцина на жабе вообще недостижима по скорости (переписать пытались на ЦПП - утухло).
А если надо что-то фундаментальное, где жаба не прокатит по каким-то причинам из-за медленного стартапа или прожорливости - то писать на сях уж.
Плюсы какая-то вымирающая ветвь ИМХО.

Потому что жаба вообще неконтролируема по сути своей. На каких-то крайне специфических задачах jit может дать "ускорение" относительно некоторого варианта решения на С/С++, но в массе своей С даёт куда более быстрые варианты, а С++ -- разумное совмещение управляемости С там, где это необходимо, и простоты разработки там, где скорость не критична.