Прошу прощения, если уже где-то обсуждается, но искал и не нашёл.

Кратко: в начале января 2024 народ затеял The One Billion Row Challenge (1BRC): посмотреть, на сколько быстро Java сможет прочитать миллиард записей из файла (~13Гб) и провести агрегацию над ними.

	Дословно
	The One Billion Row Challenge (1BRC) is a fun exploration of how far modern Java can be pushed for aggregating one billion rows from a text file. Grab all your (virtual) threads, reach out to SIMD, optimize your GC, or pull any other trick, and create the fastest implementation for solving this task!

Потом этим "мильярдом" заинтересовались и другие разработчики. Люди показывает что и объясняют как у них получилось оптимизировать. Может быть интересно.

В результате пока что .NET почти вдвое быстрее Java и заметно быстрее плюсов (у нас же СВ, почему бы и не накинуть?):

	Широкая картинка чтобы не ходить по ссылке

Побеждаем конечно же все мы: это и интересно и позновательно

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

4>- не работаю на любительском уровне (в частности за место на scoreboard и по слухам уникальную футболку)
4>- почти не пишу на C++ около 20-ти лет

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

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

4>так там std::string используется, т.е. это уже не про производительность

а что с std::string не так? Чем она хуже например шарповской строки? Надо было делать immutable строки в данном случае?

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

_FR>В результате пока что .NET почти вдвое быстрее Java и заметно быстрее плюсов (у нас же СВ, почему бы и не накинуть?):

Странно, как дот-нет быстрее плюсов. Он же тоже на плюсах. Ну, или на сишечке.

Если что-то быстрее плюсов, то мне начинает казаться, что это что-то на плюсах делали индусы, которым была поставлена задача сделать максимально медленно

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

4>так там std::string используется, т.е. это уже не про производительность, также неизвестно на сколько в данном случае было уместно использовать mmap.

Челлендж, кажется, до конца января, у вас есть возможность заменить std::string на то, что более производительно и показать, как нужно

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

_FR> ... чем же плох std::string

Производительностью, наверно не просто так изобретают различные альтернативы типа std::string_view

_FR> и mmap в контексте данной задачи?

Не известно сколько будет обращений к IO в случае mmap, поэтому возможно уместнее явно читать большими блоками (например по 100 Мб), тем самым сократив кол-во обращений к IO до пары сотен.
Несмотря, что оперативки там много (128 Гб) и в кэш много чего может влезть, но в любом случае, чем меньше будет обращений к IO тем лучше.

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

Хм 13Гб это они так затейливо скорость SSD тестят?

_FR>Челлендж, кажется, до конца января, у вас есть возможность заменить std::string на то, что более производительно и показать, как нужно

Помнится, в предыдущем варианте "челленджа" надо было опрокидывать на себя ведро холодной воды со льдом.

А еще раньше, вроде как в прорубь нырять.

Одного уровня сравнения. Что то, что другое не имеет отношения к производительности.

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

M>Мне вот интересно, как ты себе представляешь, почему IL языки быстрее плюсов?

Плюсодрочерство в стиле so5team — не про производительность.

On Mar 11, 2024, 9:27 AM, _FRED_ <7138@users.rsdn.org> wrote:

FRE>В картинке из моего поста есть результат "noahfalk 1.296"

Мое замечание относилось к тезису о том, что «.NET почти вдвое быстрее Java». Я заметил, что это не так. Кроме того, результат в 1.296 является не детерминированным и целевой сервер на стероидах, автор сам это признает:

A little more benchmarking on some of the top Java entries suggests my CCX33 instance posted times 5-10% better than the same entries on Gunnar's machine. @lehuyduc also pointed out that Gunnar moved to using the Hetzner AX161 instead and that the input data generators aren't deterministic so it remains challenging to compare results across different benchmarking environments without a good amount of fudge factor.

Но это так, к слову, возвращаемся к написанному, главное нет утверждения что «.NET почти вдвое быстрее Java»

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

_FR>В результате пока что .NET почти вдвое быстрее Java

это понятно

_FR>и заметно быстрее плюсов (у нас же СВ, почему бы и не накинуть?):

так там std::string используется, т.е. это уже не про производительность, также неизвестно на сколько в данном случае было уместно использовать mmap.

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

SD>Одного уровня сравнения. Что то, что другое не имеет отношения к производительности.

А что имеет? И к производительности чего?

Так-то, даже и любые соревнования по единоборствам не имеют отношения к тому, "кто сильнее", но соревнования позволяют в неких рамках (правилах) выявить лучшего, многое узнать о развитии физиологии и тому подобное, так что мне кажется это полезно.

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

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

_FR>Главное на мой взгляд позволяют узнать и попробовать способы обхода различных узких мест.

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

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


4>так там std::string используется, т.е. это уже не про производительность, также неизвестно на сколько в данном случае было уместно использовать mmap.

Фига се он заморочился с SIMD и хеш таблицей. SIMD имеет смысл, когда упёрлись в производительность CPU, здесь же есть чтение из файла — точно I/O bound

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

_FR>Прошу прощения, если уже где-то обсуждается, но искал и не нашёл.

да, уже заценил. вопрос только в том насколько велика разница и сможет ли аналогичный код написать джун?

PS C:\tmp\ProbaConsole> .\WinTime64.exe -- dotnet C:\tmp\ProbaConsole\net8\bin\release\net8.0\net8.dll
sum 1000000000 = 4,99999999067109E+17
PageFaultCount: 983300
PeakWorkingSetSize: 3.742 GiB
QuotaPeakPagedPoolUsage: 203.2 KiB
QuotaPeakNonPagedPoolUsage: 16.07 KiB
PeakPagefileUsage: 3.748 GiB
Creation time 2024/01/24 11:19:22.785
    Exit time 2024/01/24 11:19:33.602
    Wall time:  0 days, 00:00:10.816 (10.82 seconds)
    User time:  0 days, 00:00:02.562 (2.56 seconds)
  Kernel time:  0 days, 00:00:08.437 (8.44 seconds)
PS C:\tmp\ProbaConsole> .\WinTime64.exe -- dotnet C:\tmp\ProbaConsole\net8\bin\release\net8.0\net8.dll
sum 1000000000 = 4,99999999067109E+17
PageFaultCount: 983278
PeakWorkingSetSize: 3.742 GiB
QuotaPeakPagedPoolUsage: 203.2 KiB
QuotaPeakNonPagedPoolUsage: 16.07 KiB
PeakPagefileUsage: 3.743 GiB
Creation time 2024/01/24 11:19:39.593
    Exit time 2024/01/24 11:19:49.310
    Wall time:  0 days, 00:00:09.717 (9.72 seconds)
    User time:  0 days, 00:00:01.937 (1.94 seconds)
  Kernel time:  0 days, 00:00:08.156 (8.16 seconds)
PS C:\tmp\ProbaConsole> .\WinTime64.exe -- .\proba_rust\target\release\proba_rust.exe
sum 1000000000 = 4.99999999067109e17!
PageFaultCount: 2030013
PeakWorkingSetSize: 4.004 GiB
QuotaPeakPagedPoolUsage: 26.11 KiB
QuotaPeakNonPagedPoolUsage: 4.906 KiB
PeakPagefileUsage: 6.013 GiB
Creation time 2024/01/24 11:19:59.401
    Exit time 2024/01/24 11:20:05.872
    Wall time:  0 days, 00:00:06.471 (6.47 seconds)
    User time:  0 days, 00:00:01.828 (1.83 seconds)
  Kernel time:  0 days, 00:00:04.234 (4.23 seconds)
PS C:\tmp\ProbaConsole> .\WinTime64.exe -- .\proba_rust\target\release\proba_rust.exe
sum 1000000000 = 4.99999999067109e17!
PageFaultCount: 2030001
PeakWorkingSetSize: 4.004 GiB
QuotaPeakPagedPoolUsage: 26.11 KiB
QuotaPeakNonPagedPoolUsage: 4.906 KiB
PeakPagefileUsage: 6.013 GiB
Creation time 2024/01/24 11:20:07.156
    Exit time 2024/01/24 11:20:13.266
    Wall time:  0 days, 00:00:06.110 (6.11 seconds)
    User time:  0 days, 00:00:01.984 (1.98 seconds)
  Kernel time:  0 days, 00:00:04.109 (4.11 seconds)

var capacity = 1000_000_000;
var list = new List<int>(1000_000_000);
double s = 0;
for (var e = 0; e < capacity; e++)
{
    list.Add(e);
}
for (var e = 0; e < list.Count; e++)
{
    s += list[e];
}

Console.WriteLine("sum {0} = {1}", list.Count, s);

fn main() {
    let mut v = Vec::new();
    let mut s: f64 = 0.0;
    for e in 0..1000_000_000 {
        v.push(e);
    }

    for e in 0..v.len() {
        s += v[e] as f64;
    }
    println!("sum {:?} = {:?}!", v.len(), s);
}

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

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

4>>так там std::string используется, т.е. это уже не про производительность, также неизвестно на сколько в данном случае было уместно использовать mmap.

_FR>Челлендж, кажется, до конца января, у вас есть возможность заменить std::string на то, что более производительно и показать, как нужно

Нет, я себе позволить такое не могу, ибо:
— не работаю на любительском уровне (в частности за место на scoreboard и по слухам уникальную футболку)
— почти не пишу на C++ около 20-ти лет

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

_>Хм 13Гб это они так затейливо скорость SSD тестят?

Где-то читал, что они делают несколько прогонов, а на машинке чуть ли не 128Г памяти, так что файл уже и из кэша может читаться.

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

4>>>так там std::string используется, т.е. это уже не про производительность, также неизвестно на сколько в данном случае было уместно использовать mmap.
_FR>>Челлендж, кажется, до конца января, у вас есть возможность заменить std::string на то, что более производительно и показать, как нужно
4>Нет, я себе позволить такое не могу, ибо:

А можете ли вы позволить и просто рассказать, чем же плох std::string и mmap в контексте данной задачи? Я знаком с плюсами скорее теоритически, поэтому будет интересно.

On Jan 23, 2024, 4:11 PM, _FRED_ <7138@users.rsdn.org> wrote:

FRE>пока что .NET почти вдвое быстрее Java и заметно быстрее плюсов (у нас же СВ, почему бы и не накинуть?):

Уже нет, решение TW 00:01.535

	Скрытый текст
	[пока] # Result (m:s.ms) Implementation JDK Submitter Notes Certificates 1 00:01.535 link 21.0.2-graal Thomas Wuerthinger, Quan Anh Mai, Alfonso² Peterssen GraalVM native binary, uses Unsafe Certificate 2 00:01.587 link 21.0.2-graal Artsiom Korzun GraalVM native binary, uses Unsafe Certificate 3 00:01.608 link 21.0.2-graal Jaromir Hamala GraalVM native binary, uses Unsafe Certificate

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

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

Плюсовики в дерьмочеленджах не участвуют

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

_FR>> ... чем же плох std::string

4>Производительностью, наверно не просто так изобретают различные альтернативы типа std::string_view

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

А std::string и сам по себе очень хорош

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

M>>Мне вот интересно, как ты себе представляешь, почему IL языки быстрее плюсов?

Аё>Плюсодрочерство в стиле so5team — не про производительность.

Тёмчик, ну ёж-моёж, зачем ты помянул мое имя всуе? Я же здесь никому не мешал?

Но если уж ты сказал "А", то разверни уж тему, плз. Про "дрочество" в частности.

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

M> Странно, как дот-нет быстрее плюсов. Он же тоже на плюсах. Ну, или на сишечке.

Л — логика

M> Если что-то быстрее плюсов, то мне начинает казаться, что это что-то на плюсах делали индусы, которым была поставлена задача сделать максимально медленно

Расскажи уже индусам, как надрать жопу дотнету

Автор: rudzuk
Дата: 02.07.22

, а то оин, пока, только до изменения условий задачи додумалиcь

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

_FR>>Главное на мой взгляд позволяют узнать и попробовать способы обхода различных узких мест.

M>Мне вот интересно, как ты себе представляешь, почему IL языки быстрее плюсов?

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

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

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

4>>- не работаю на любительском уровне (в частности за место на scoreboard и по слухам уникальную футболку)
4>>- почти не пишу на C++ около 20-ти лет

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

Возможно, человек занимается business value, а не кодированием ради стремления кому-то что-то доказать

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

FRE>>пока что .NET почти вдвое быстрее Java и заметно быстрее плюсов (у нас же СВ, почему бы и не накинуть?):
R>Уже нет, решение TW 00:01.535

В картинке из моего поста есть результат "noahfalk 1.296"

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

_FR>>Главное на мой взгляд позволяют узнать и попробовать способы обхода различных узких мест.

M>Мне вот интересно, как ты себе представляешь, почему IL языки быстрее плюсов?

Отвечая и на предыдущее сразу: Я не вижу, что тут что-то сильно быстрее чего-то.
Вот выше поправили уже, что и Джава догнала, что соответствует моим ожиданиям. Изначально я был сильно даже фрамппирован тем, что .НЕТ вдруг так сразу хорошо "вырвался".
При текущем (и понятном для меня) положении дел, когда разница в десятых долях секунды (на миллиарде записей), я не возьмусь утверрждать "кто быстрее".

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

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

FRE>>пока что .NET почти вдвое быстрее Java и заметно быстрее плюсов (у нас же СВ, почему бы и не накинуть?):
R>Уже нет, решение TW 00:01.535
Кто-нибудь понимает почему они используют кастомный код в Scanner с unsafe? Он вроде практически повторяет стандартный ByteBuffer.