История изменений
Исправление Toxo2, (текущая версия) :
в плюсах компилятор такие вещи делает по умолчанию.
__m128i separators = _mm_set1_epi8(';');
__m128i chars = _mm_loadu_si128((__m128i*)data);
__m128i compared = _mm_cmpeq_epi8(chars, separators);
uint32_t separator_mask = _mm_movemask_epi8(compared);
вообще-то не похоже на «компилятор по умолчанию» в решении обсуждаемой задачи на С++ от вьетнамца по имени Le Huy Duc.
нормальные люди не хранят большие обьемы данных в джисоне
где ж их взять-то нормальных? я ж не шучу - реально гигабайт джсона люди из БД тянут и возмущаются, что и БДшник плохой, и ПГ надо убить.
парсинг не является узким место ни разу, и ускорять его довольно глупо
Не готов сказать однозначно - но судя по тому, что этот simdjson используется (вроде бы) в ClickHouse - возможно именно поэтому КХ быстрее в два раза, чем DuckDB получился на ровно том же запросе.
Исходная версия Toxo2, :
в плюсах компилятор такие вещи делает по умолчанию.
__m128i separators = _mm_set1_epi8(';');
__m128i chars = _mm_loadu_si128((__m128i*)data);
__m128i compared = _mm_cmpeq_epi8(chars, separators);
uint32_t separator_mask = _mm_movemask_epi8(compared);
вообще-то не похоже на «компилятор по умолчанию» в решении обсуждаемой задачи на С++ от вьетнамца по имени Le Huy Duc.
нормальные люди не хранят большие обьемы данных в джисоне
где ж их взять-то нормальных? я ж не шучу - реально гигабайт джсона люди из БД тянут и возмущаются, что и БДшник плохой, и ПГ надо убить.
парсинг не является узким место ни разу, и ускорять его довольно глупо
Не готов сказать однозначно - но судя по тому, что этот simdjson используется (вроде бы) в ClickHouse - возможно именно поэтому КХ ,быстрее в два раза, чем DuckDB получился на ровно том же запросе.