1 биллион челлендж

Проблема в том, что из таких «ничего не стоит» и набегает время.

Нужно именно на Яве

Я не пишу на Яве и не собираюсь.

Такой роскоши у нас нет. По условиям на вход подается случайный файл.

Файл то случайный, но названия метеостанций в жизни априори известны.

А в чём собственно челинж?

но названия метеостанций в жизни априори известны.

Даже если так, то их *гораздо* больше чем 10К, как в условии задачи.

Сложного ничего, но это надо было осознать:-)

urxvt такого осознания не продемонстрировал, он все хотел с шапкой наголо че то параллелить. Хорошо ещё GPGPU не предложил юзать…

10К? Фигово

Ну тогда переход вовходных данных к бинарному формату и ID станций скорее всего сделает многопоточность бесмыссленной, даже при размещении данных в памяти:-)

Интересное утверждение. Если просто решить задачу то да, задача тривиальная. Если же решить быстрее всех то да, сложно. Очень сложно. Иначе тут бы уже половина ЛОРа победителей было, а не на словах.

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

А в чём профит задачи?
Пусть даже принимаем данные от 10000 метеостанций.
Загрузка их не займёт по идее много времени.

У меня есть гораздо более интересные задачи из HPC. Футболок у меня хватает, на Яве я не пишу.

Кроме того я не увидел ограничений/условий по железу - а они важны.

Да просто аффтор конкурса развлекается. Профита никакого

Могут, если знать что делаешь. JIT отчасти убирает «кучу проверок» на горячем коде. GraalVM Native Image генерирует машинный код как и компилятор Си. Влияние сборки мусора зависит от кривизны рук. При желании можно вручную управлять памятью вне хипа прямо как в Си. Подвезли в последние версии JVM официально.

«Отчасти» - это не все. Все равно весь оверхед не уберешь. Хотя если оно все переведет в нативный код (кэш код, если я правильно формулирую, исправь, как правильно)… Только эта операция тоже стоит времени при первом запуске. Мы ее игнорируем или как? Да и в целом, джава, которая переводит все в нативный код - хм, а зачем? Если есть C/C++/Rust, которые сразу дают нативный код без монстра в виде байткода и виртуальной машины.

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

Компиляция в нативный код + simd, реультат будет близкий, но скорее всего джава все равно будет немного отставать. А знаешь, как сделать так, чтобы не отставала? Да выкинуть из джавы все кроме компиляции в нативный код :-)

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

Да и в целом, джава, которая переводит все в нативный код - хм, а зачем? Если есть C/C++/Rust

У первого нет простоты джавы, у второго нет нормального ООП. Поэтому выбираю меньшее из зол, пусть и заплатив чуть меньшей производительностью. Плюс IDE у джавы более-менее (у остальных привет из 80-х). С удовольствием бы пользовал другой ЯП и рантайм, но такого нет.

А знаешь, как сделать так, чтобы не отставала? Да выкинуть из джавы все кроме компиляции в нативный код :-)

Ну Жава так-то не про скорость. Про скорость - это Ассемблер, при условии что руки не совсем из жп. А Жава - это про надёжность, безопасность и предсказуемость. Там где на Сишечке из-за криворукости одного из разрабов всё закончится крашем процесса, по причине сегфолта, в Жаве будет выброшено исключение проверки границ массива, которое вероятно будет перехвачено выше по стеку вызовов, и возможно корректно обработано, и процесс продолжит работу. Там, где даже на Расте будет течь память, сборщик мусора Жавы, хоть и сам прожорлив, но возможность большинства утечек нивелирует. Там, где на крестах будет уязвимость из-за use-after-free, на Жаве всё будет спокойно. Там где заоптимизированная система серверов целиком написанная на Ассемблере (да, для этого нужно много забойной травы ;) ) будет летать, пока не поставят процессоры той же линейки, но следующего поколения, а потом начнёт притормаживать из-за изменения количества кеш-линий в наборе, медленную систему серверов на Жаве, можно, в идеале, легко пересадить на совершенно другую архитектуру, и рассчитывать на ту же величину изменения производительности, коей новая архитектура отличается от старой…

А rust ?

Там где на Сишечке из-за криворукости Там, где даже на Расте будет течь память Там, где на крестах будет уязвимость из-за use-after-free

Вот интересное сравнение криворуких c/c++/rust разрабов с разрабами java у которых руки на месте.

Хотя конечно, то что в джаве сложнее ошибиться - это факт.

С другой стороны видывал я джава приложения, которые юзеру показывали исключения и аварийно завершались и c++ приложения, которые работают без ошибок.

$ time ./Antonl.py /home/Sources/1brc/measurements.txt

real	13m30,512s
user	13m19,505s
sys	0m10,840s

бгг

Современные оптимизирующие компиляторы как правило генерят из С/С++ код не хуже, чем рукописный асм. Так что программирование на асм ручками постепенно уходит в прошлое…

Ну так питон же… он не для скорости:-)

Как-то прям сильно не для скорости. Думал примерно похоже должно быть.

Практически слово-в-слово такой же код на Го (простое решение в лоб) - работает 3 минуты, как и их эталонное решение на Java.

---

Пытался в DuckDB тыкать, раз они про него упоминали - проигрывает ClickHouse в полтора раза.

SELECT
 	city
 	,min(temperature)
 	,avg(temperature)
 	,max(temperature)
FROM
 	read_csv(
 		'/home/Sources/1brc/measurements.txt'
 		,delim=';'
 		,buffer_size=320000000
 		,parallel=True
 		,auto_detect = false
 		,columns={'city': 'VARCHAR', 'temperature': 'FLOAT'}
 	)
GROUP BY
 	city
 ;

Там по ссылке в ОП есть решение на питоне, на М1 45 секунд. Подход традиционный для обработки больших файлов - чанками в процессах по количеству процессоров и потом объединение результатов.

Ну можно взять cython какой нить. Проигрышь на два порядка С-ям на такой задаче для питона это норм. Мы его не за скорость любим:-)

А pypy?

пичалька, ну тогда в Show and tell закинуть. давно хотел проверить свой скилл на typescript. Задача относительно сложная конечно, так еще и тред один. И было бы круто всех удивить)) Типа хоба, смотрите как могу. Распарсить 1 биллион строк на ноде при этом не вызвав дома пожар и не состарится от старости)) А че, круто 🤔 Не думаю что найдется еще один такой же наглухо отбитый как я 🤪

Как-то прям сильно не для скорости.

Дык «вы неправильно считаете!» (с) .)

Напитонено за полторы минуты за спасибо не приходя в сознание. Итого: 15 минут.

Жабиста ты сначала будешь 15 минут уговаривать, а потом он тебе две недели будет сношать мозг правильным ООП.
Результат: счёт «за 3 часа работы и две недели обучения ваших дебилов антипатернам».

да, для этого нужно много забойной травы

как говорится, дайте мне мешок казеной колумбийской муки и я сдвину землю 😎👍

А pypy?

real	3m21,219s
user	3m11,890s
sys	0m8,927s

Да, действительно, так похоже на «остальные простые решения», хоть и пилит в одно ядро. С виду тот же код на Го по нескольким ядрам размазывается судя по htop, а по времени почти так же получается.

Ну, cython возможно будет по-быстрее, но это уже дополнительная возня.

а зачем? Если есть C/C++/Rust,

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

Интересно сколько лисп выдаст:-)

1e9 записей с полутысячи станций…

NOAA разъясняет, что каждая станция оборудована тремя термометрами передающими замеры каждые 2 секунды. Эти замеры усредняются для получения 5-минутных данных, из которых получаются «официальные» ежечасные замеры.

Если предположить, что в CSV запихали 5-минутные результаты, то…
1e9 / 12 замеров в час / 24 часа в сутках / 500 станций / 365.25
получается примерно 20 лет замеров.

Как учит нас википедия, самое быстрое зарегистрированное изменение температуры в Америке ~27 градусов за 2 минуты. Выглядит так, что обработка 2-секундных показателей с каждого термометра – это необязательно чья-то прихоть.

Делим на 3 термометра, 30 замеров в минуту и пр. Получаем… две недели

WMO клевещет про 8K+ станций. То есть в таком количестве «всё-отовсюду» будет собираться примерно за сутки.

Вопрос на два цента: какая разница будут ли собранные за сутки данные обсчитываться 15 минут или 0 секунд?
(Считать вклад менее эффективных вычислений в глобальное потепление пренебрежительно малым по сравнению с парниковым эффектом выхлопа горящих задниц.)

15 минут работы компутера это грубо 0,1 кВт. при стоимости электричества в $0.166 за кВт/ч

Вопрос на два цента

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

~$7 в год, если считать каждый день. Почти три литра бензина по американским ценам. В районе 30 километров на автомобиле. Java-чемпион уже сидит перед камином дома, а Python-участник соревнований ещё идёт пешком по лесу, бросив авто на трассе.

Как-то так на текущий момент?

Эммм…у меня нет машины. Вообще. Она мне ненужна - езжу обычно на яндекс-такси уровня комфорт-комфорт+, эконом какой то стремный стал:-(

Зато горных лыж дома пар 6, включая скитуровские кастлы:-) ЧЯНТД?

Считаю, что следует считать разницу между «компутер крутит xscreensaver» и «компутер крутит xscreensaver и одновременно считает среднюю температуру по больнице^W планете».

Но не это должно было насторожить во всей этой болтовне неискушённого ценителя практических задач… :)

P.S.

бросив авто на трассе

Плюшевый питончик
Полз по лесу
Жабок собирал
Сразу терял
Всё что находил

~$7 в год, если считать каждый день.

Положим (от балды, конечно), что медленное решение программист напишет за час, а быстрое за день. Пусть зарплата составляет $50/ч. Тогда медленное решение стоит $50, а быстрое — $400. Разница между ними составляе $350 и она отобьётся за 50 лет непрерывных расчётов.

отобьётся за 50 лет

если не возобновляемые ресурсы для бензина ещё не кончатся к тому времени.

За 9,58 сто метров бегать совсем не обязательно в практическом смысле. Особенно если не можешь.

Но да, юмор - такая субъективная вещь (с)

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

Моё однопоточное произведение, на С: https://github.com/imonlyfourteen/1brc

Чуть побыстрее, чем у firkax, хотя не сильно-то и отличается)

там 404

Самое быстрое решение написал!

Я про него и говорил - нет нормального ООП. Посмотрел реализацию DOM в Servo и хочу теперь это развидеть.

какая разница будут ли собранные за сутки данные обсчитываться 15 минут или 0 секунд?

Зависит от задач, если ты не гранты пилишь, а реально развиваешь цивилизацию, то у тебя со временем будут возникать новые задачи. И если каждая будет отрабатывать за 15 минут, а не за 0 секунд, то в определенный момент у тебя не хватит на них ресурсов процессора.

Можно конечно купить новые процессоры, но я думаю ты понимаешь как я продолжу свои рассуждения?

Ещё смотрел как игры на ржавом пилят. Там где нужно ООП даже целый фреймворк запилили с его симуляцией. Одним словом - цирк.

У меня есть гораздо более интересные задачи из HPC. Футболок у меня хватает

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

Не фанат Раста, но посмотрел бы, как на нём выглядить фреймвок симуляции ООП.

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

А так-то поразмазывать рассуждения по чистому столу можно в любую сторону. Например, «если на написание каждой одноразовой самой-быстрой-считалки будешь тратить по два часа своей жизни, то…»

Ещё смотрел как игры на ржавом пилят. Там где нужно ООП

Скорее не нужен, в играх и на С++ (и C#) сейчас то же самое, отказ от ООП в пользу ECS (Entity-Component-System) да и раньше там не особо использовался ООП в ява стиле.

даже целый фреймворк запилили с его симуляцией.

Наверно просто видел реализацию ECS.