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

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

Результаты ещё интереснее, типа:

$ java Map
records loaded in 1829ms
records red in 86ms

(подгрузка слила на порядок, а скорость чтения - быстрее в 7 раз чем на CPP и в 2 раза - чем на C. однако жаст-ин-тайм...)
на самом деле всё же усредняется и едетерминистичность/непредсказуыемость о которой Вы говорите в рантайме - усреднится. Поэтому и хороша она на сервере где куча юзеров друг друга усредняет (если конечно не круворукие писали и не понаворачивали фреймвоков, EJB и прочего Г.)

/* closer to C/CPP version */

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

public class Map{

public static void main(String[] args){
try{
long t0 = System.currentTimeMillis();
HashMap<String, String> hash = new HashMap<String, String>();
BufferedReader is = new BufferedReader(new FileReader("./dict"));
String line = is.readLine();
while(line!=null){
hash.put(line, line);
line = is.readLine();
}


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();
}

}

}

Ты идиот или притворяешься? Тупое решение на Си слилоло тупому решению на Си++. Так давай теперь сравнивать умное решение на Си с тупым решением на Си++? Может сравнить умное решение на Си с умным решением на Си++ ?

> алгоритм Бернштейна почему-то наиболее подходящ для равномерного распределения по хеш-бакетам.

Вот тут пишут, что это не так http://vak.ru/doku.php/proj/hash/efficiency .

> А стдлиб Map - я не знаю какой алгоритм использует и может и не Бернштейна вовсе

1. std::map использует не хеш, а красно-черное дерево.

2. std::unordered_map использует хеш, но алгоритм хеширования можно поменять.

3. Прежде чем что-то начинать оптимизировать надо убедиться, что именно оно является узким местом. Поэтому в 90% случаев уже написанные алгоритмы подойдут и только в 10% случаях придется изобретать собственный велосипед.

4. если программа работает меньше 10 секунд (и тем более меньше одной секунды) и при этом осуществляются какие-то замеры производительности, то у меня складывается ощущение, что меня на2.71бывают.

> если не в разы - тогда почему вышеприведённый код с std:map доступается в ~4 раза медленнее чем написанный ручками под задачу хэш?

Потому что ты сравниваешь теплое с мягким и хеша там нет. С unordered_map сравнивай. И хеш туда такой же поставь.

>>алгоритм Бернштейна почему-то наиболее подходящ для равномерного распределения по хеш-бакетам.
>Вот тут пишут, что это не так http://vak.ru/doku.php/proj/hash/efficiency .

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

>Reset (фотография)
Re: JavaScript в Firefox/Wine работает быстрее чем в Firefox/Linux
> алгоритм Бернштейна почему-то наиболее подходящ для равномерного распределения по хеш-бакетам.

Вот тут пишут, что это не так http://vak.ru/doku.php/proj/hash/efficiency .

> А стдлиб Map - я не знаю какой алгоритм использует и может и не Бернштейна вовсе

> 1. std::map использует не хеш, а красно-черное дерево.

aaa, так поэтому он и тормозил... (много структур, авто-балансировка).

> 2.
ясно

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

не спорю, закон. Речь шла что принципиально можно оптимизировать так как имеется контроль и всё на блюдечке в отличие от

> 4. если программа работает меньше 10 секунд (и тем более меньше одной секунды)

а почему? Ведь меряются микросекунды и ошибки идут во втором знаке (я конечно же прогнал раз по 5 - чтобы посмотреть на разброс. А дисперсии, среднеквадратичные отклонения, анализ погрешностей - делать лень. Первая значимая цифра уже даёт понятие - какое соотношение (поэтому и пишется: ~3, больше 3, или 30% - первое приближение).
Не придирайтесь, не статью в журнал пишем.

Попробовал Firefox собрать под icc - фиг. На сборке nss - сегфолт, на сборке xulrunner - ошибка компиляции (не находит идетификатор).

А это ничего, что операционной системе Windows XP уже ВОСЕМЬ лет? А Linux брали не восьмилетней давности (там тоже можно собрать этот фаерфокс будь он неладен, если поднапрячься), а Федору 10, которая как известно есть самый-самый распоследний (в хорошем смысле естественно) дистрибутив?

Передёргивание, если кратко. Наглое.

>А это ничего, что операционной системе Windows XP уже ВОСЕМЬ лет? А Linux брали не восьмилетней давности

А какое отношение производительность потрохов Firefox имеет к возрасту операционной системы?

>Видимо, это проблема конкретной сборки Firefox; никогда не наблюдал ни для Firefox, ни для Mozilla Suite.

Раздражают дебилы и мимикрирующие под дебилов больные на голову линукс-квази-патриоты.

Да, хоткеи были сломаны еще в мозилле при переходе на gtk2 и проявляется только в сборке с gtk2. И заработали они только в ff-3. Расширение-костыль для ff2 и патч для него же, не вошедший в официальную сборку не в счет.

Заруби себе на носу и не тупи больше...

> А это ничего, что операционной системе Windows XP уже ВОСЕМЬ лет? А Linux брали не восьмилетней давности (там тоже можно собрать этот фаерфокс будь он неладен, если поднапрячься), а Федору 10, которая как известно есть самый-самый распоследний (в хорошем смысле естественно) дистрибутив?

> Передёргивание, если кратко. Наглое.

Нуну :) Если прям 8 лет, то линкус не сильно то моложе :). (2.6 ветка)

17 December 2003 - Linux 2.6.0 was released (5,929,913 lines of code).

Windows XP SP0 25 октября 2001 года и она "закончилась" 30 сентября 2004 ;).

А сравнивать то надо:

24 December 2008 - Linux 2.6.28 was released (10,195,402 lines of code).[13]

Windows XP 5.1.2600.5512 Service Pack 3 — 21 апреля 2008

> Да, хоткеи были сломаны еще в мозилле при переходе на gtk2

Не прошло и суток, как кто-то наконец произнес правильные слова.

> И заработали они только в ff-3.

Неверное утверждение.

hotkeys работали и в ff < 3.

> А какое отношение производительность потрохов Firefox имеет к возрасту операционной системы?

Библиотеки времени исполнения могут давать вклад.

>Нуну :) Если прям 8 лет, то линкус не сильно то моложе :). (2.6 ветка)

Почитай Линуса - он ясно сказал что на сегодняшний день число 2.6 не означает ничего. Уж ему-то стоит поверить. За это время ядро кардинально изменилось.

>Старые и новые - это какие конкретно? А то у меня банальный gzip после icc 10.1.018 работал на 13% быстрее, чем в gcc 4.1.2

gcc 4.1 - слишком старый. как минимум 4.3 нужно использовать и с ним сравнивать.

Идиот тут только один, к твоей беде. Тупое решение на С++ слило тупому решению на С, как и должно было бы (притом, что решение на С++ пытается делать вид, что оно слегка умное). Чудес не бывает.

> Почитай Линуса - он ясно сказал что на сегодняшний день число 2.6 не означает ничего. Уж ему-то стоит поверить.

> За это время ядро кардинально изменилось.

А гигабайты сервиспаков, череда ie6/6.5/7/уже 8 винды - нет? Вплоть до полной несовместимости (сейчас уже сложно найти софт, серьезный, который бы хотел что-то меньше SP2)

Так что в общем то все равно, чего там говорит Линус, ибо MS тоже не стоит на месте и постоянно дорабатывает свою ось. Как минимум до SP2 изменения были довольно серьезные.

4 секунды на С++ против 42 секунд на Си. Может стоит снять шоры с глаз?

фф на венде собран с pgo. Насколько я знаю, ff для линупса собирается без pgo, хотя гцц его (pgo) умеет.

> А это единственное, где у линукса в лице убунты есть шанс себя показать в честном сравнении. И то, если забыть про N-Lite, который грязный хак и всё такое.

> Простые замеры скорости загрузки системы и программ с секундомером приведут линуксоидов в отчаяние, как и скорость реакции GUI. Вообще проблемы со скоростью это генетический дефект линукса, выросший из механического переноса решений для мейнфреймов 70ых годов на современные ПЭВМ - модульность до маразма везде где надо и где не надо плюс переносимость на экзотические архитектуры в ущерб скорости на единственной реально используемой (на ПЭВМ).

+1

Херасе... Не, я верю, что sleep в С может дать 42 секунды на добавлении 1.000.000 элементов в TAILQ, но как тебе удалось достичь 4 секунд на "быстрых" плюсах?!

Специально для идиотов повторяю по пунктам:

1. сними шоры с глаз

2. перечитай мой сообщение в котором говорилось про 42 секунды

3. внеси изменения в собственный код, откомпилируй и запусти

А есть сравнение 64-битных сборок?

1. С твоих? За отдельную плату. 2. Это там, где зачем-то вместо 1м инсертов делаем 100м? А зачем? Я про 1м говорю, фантазии про 100м меня мало интерисуют. 3. sleep() в сишную часть добавить?

Да, в общем-то, при современных мощностях достаточно пофиг, на чём писать (если откровенноне лажать) -- для пользовательского софта в подавляющем большинстве случаев скорости хватит, кроме достаточно редких вещей типа обработки видео/игр/и тыпы, для серверного -- дешевле купить N+1ый сервер, чем оплачивать пару месяцев работы специалиста.

Проблемы начинаются на относительно слабом железе типа тех же КПК/Internet Tablet/что там ещё из этой же серии... До смешного доходит -- картинки, которые прекрасно смотрелись на 386SX с парой метров озу, на n800 еле ворочаются. Всего-то пара десятков мегапикселей в жпеге. Зато как модно стало говорить, что С++/жаба не тормознее С. 8))

> 1.... много бреда поскипано

Как осилишь собрать так приходи сюда, дальше продолжим разговор о "тормозности" Си++.

> С++/жаба не тормознее С.

У тебя каша в голове. Жабу еще сюда приплел. 20 лет назад такие как ты же говорили о том, что фортран быстрее Си. И где сейчас этот фортран? Кроме как в библиотеках, написанных 20-30 лет назад больше нигде и не используется. Си/Си++ компиляторы многие вещи уже сто лет как научились оптимизировать лучше чем это делает человек руками.

Иди, что ли, "чиста паприколу" читать научись. Потом можешь приступать к следующему упражнению -- учиться думать.

>20 лет назад такие как ты же говорили о том, что фортран быстрее Си

А ведь с прямым назначением фортран по-прежнему справляется лучше, чем Си

>Я головой думаю регулярно - аж болит. Имеет, начиная от glibc заканчивая драйверами GL. Правда если голову перевести в положение 'вкл', а так, да, не имеет.

Ну вот и объясни, каким образом даже версия под wine работает быстрее родной линуксовой (hint: wine транслирует лишь win32-специфичные вызовы, вся арифметика/логика выполняется нативно)

Ну как, "прояснения" еще не видно?

>gcc 4.1 - слишком старый. как минимум 4.3 нужно использовать и с ним сравнивать.

Сейчас на 4.3 как раз сижу. Кроме обретённых проблем со сбором некоторых пакетов никакого прироста производительности на глаз не заметил :) Хотя с цифрами не тестировал. Надо будет заняться...