про все остальное речь не шла. js вполне себе запинывает на алгоритмах
v8 запинывает
@aleksxor
Vladimir
пруф?
Andrew
ну модули ядра на ноде на сях написаны, я не думаю что ты тупо на сях напишешь сильно оптимальнее, будет конечно оверхед некоторый, но не в разы я считаю
Andrew
Не хватит оперативки
а сколько сейчас оперативки и сколько это все добро занимает в сумме места?
Andrew
обычный комп позволяет до 32 гигов спокойно поставить, и деньги не столь велики для подобных задач
Dmitrii
а сколько сейчас оперативки и сколько это все добро занимает в сумме места?
Сейчас 32, а все добро занмает около 300-400 гб
Andrew
а не
тогда не вариант
Andrew
но, если объём поделить, допустим, на 20, то он уже будет влезать в оперативку
Andrew
т.е. за 20 итераций можно отсортировать 20 порций
Dmitrii
На порядок - это прям в 10 раз? Странно. Но в любом случае, это более оптимальный и удобный способ, если задача не разовая, а постоянная при поступлении новых данных. Я бы игрался с памятью и прочими оптимизация в PG. Вот такое 123123:323123 можно разбить на два поля, например, и следать int вместо текста.
Ну, не в 10, но в сроки не кладывается ни при каких оптимизациях. Конечно, можно докупить мощностей, но пока приходится обходиться тем, что есть
Andrew
если их грамотно разложить по 20 файлам
Dmitrii
Ну, а потом только построчно, если так
Andrew
да
Andrew
в оперативе полюбому быстрее будет сортировка
Andrew
а ключи дублируются?
Dmitrii
Да, первая часть будет повторяться и не раз
Andrew
в таком случае как сортируешь при дублирующемся ключе?
Dmitrii
Вторая тоже, но их комбинация уникальна
Andrew
или отбрасываешь?
Andrew
значит там где первые совпали, надо по второму сортировать?
Dmitrii
Нет, только по первому
Dmitrii
По крайней мере пока
Andrew
я бы так сделал
Vint
Ну, не в 10, но в сроки не кладывается ни при каких оптимизациях. Конечно, можно докупить мощностей, но пока приходится обходиться тем, что есть
Ну, надо играться, за глаза не скажу)
А результат сортировки весь нужен или только top xxx?
Andrew
берешь максимальное значение первого ключа
Andrew
делишь его на 30
Dmitrii
@aleksxor
пруф?
https://gist.github.com/spion/3049314
как эталон.
там в комментах привели и крутую С версию, но кода и знаний чтобы ее написать, надо явно поболе чем для тупого алгоритма на луа
Andrew
проходишь все файлы и раскладываешь строки по 30 файлам согласно диапазона ключей
Andrew
дальше сортируешь отдельно каждый файл, благо он в память по идее должен взалить, если нет, тогда не 30 а 40 50 или 60
Andrew
получаешь дцать файлов с отсортированным контентом внутри
Andrew
по ходу отслеживаешь, если где-то файл начинает выходить за рамки лимита оперативки, бьешь на части дополнительно
в любом случае у тебя ключи разложатся в пределах диапазонов по файлам
Vladimir
Dmitrii
Vint
Весь
Печально. Читать исходники через stream и сравнивать с топом - было бы несложно. А так, весь result слишком жирный, в память не влезет.
Надо пытаться имплементировать максимально быстрый механизм external merge sort. Они уже описаны и есть готовые алгоритмы.
@aleksxor
увы, это плохой бенчмарк
удобная позиция )
по мне так, вообще, эталонный. четко показывает что писать шустрые пргоги на луа гораздо проще чем на сях
Dmitrii
Ну и последний вопрос, уточняющий: c++, luajit или нода?
Vladimir
Я не знаю, как там полчилось у lua быстрее чем c и с++
Dmitrii
И да, всем спасибо за помощь
Andrew
Ну и последний вопрос, уточняющий: c++, luajit или нода?
в сях задолбаешься за памятью следить
Andrew
про луа не знаю
Vladimir
Но в случае с луа и нодой как минимум во время включено время инициализации
@aleksxor
легко. luajit очень хорошо умеет в оптимизацию. гораздо лучше среднего человека
Andrew
как нода такие объёмы будет хавать тоже вопрос
Vladimir
легко. luajit очень хорошо умеет в оптимизацию. гораздо лучше среднего человека
и лучше компилятора?
Andrew
в любом случае пиши в файлы не построчно, а пачками, иначе на иопсах будешь большой оверхед иметь
Vladimir
нода - не равно v8
@aleksxor
компилятор сам по себе в оптимизацию обычно не умеет
Vladimir
-03 знаешь что такое?
@aleksxor
вот именно. а есть еще -01 и другое. к компилятору напрямую не относится
@aleksxor
можно компилять без оптимизации, вообще
Vladimir
можно, но так никто не делает
@aleksxor
оптимизация и компиляция разные процессы. luajit пишет Mike Pall. на мой вкус, самый способный. дотаточно глянуть на список оптимизаций которые luajit умеет
Ale
Vladimir
Vladimir
и в него вложены десятки миллионов долларов
@aleksxor
так себе агрумент
Vladimir
Конечно, один мужик в подвале может тоже самое сделать
@aleksxor
удобно чучело пинать?
Vladimir
Но не суть - допустим lua быстрее C++
Vladimir
Осталось ответить на вопрос - почему
Vladimir
Без этого ответа наиболее вероятно, что это некорректный бенчмарк
@aleksxor
опять чучело пинаешь. я не говорил что луа быстре сей.
код на луа через luajit быстрее того что напишет средний сишный кодер. это наиболее близко к моей точке зрения.
Vladimir
Луа быстрее в этом бенчмарке
@aleksxor
ты видел код на луа в нем и код на си который быстрее луа?
@aleksxor
такой код на луа я напишу через пару дней знакомства с языком. тот код на си который там приведен и быстрее кода на луа - я с трудом разобрать могу
@aleksxor
а с сями я работал довольно плотно в начале нулевых
Vladimir
и это объясняет что он медленнее?
@aleksxor
я чувствую тебе со своими мыслями комфортнее спорить чем с собеседником )
Vladimir
В этом бенчмарк луа быстрее C и C++
@aleksxor
именно так
Vladimir
Я лишь говорю, что это требует объяснения
Дима
и в него вложены десятки миллионов долларов
flux пишут ребята из фейсбука, в него вложены десятки миллионов долларов, конечно, один дэн в подвале не может то же самое сделать
@aleksxor
первого варианта. там в комментах есть вариант который быстрее
Vladimir
> @ZeroBias
flux пишут ребята из фейсбука, в него вложены десятки миллионов долларов
лол, конечно. миллиарды
Vladimir
Наиболее верочтное объяснение - бенчмарк некорректен
Дима
> @ZeroBias
flux пишут ребята из фейсбука, в него вложены десятки миллионов долларов
лол, конечно. миллиарды
Что лол, я просто говорю что аргументация к деньгам не катит