Побитовые проверки в Java и почему они так неоднозначны

[Ksnz]

А мне как-то для какой-то задачи не хватило в котлине | оператора. Но там можно сделать.

foo() or bar()

Performs a logical or operation between this Boolean and the other one. Unlike the || operator, this function does not perform short-circuit evaluation. Both this and other will always be evaluated.

[remindscope]

Ни разу не видел использования побитовых операций в коде. Разве что &= для цепи булевых переменных

[rukhi7]

Ни разу не видел использования побитовых операций в коде.

суслика не видишь и не видел, а он есть :)

[nv13]

Чем быстрее программа работает, тем больше она делает ошибок))

Хочется битовых операций - осознанно используй int или char, а не boolean.

[breninsul]

Честно говоря, я не верю что | вместо || хоть на сколько-то влияет на производительность в DBeaver да и в любом другом подобном прикладном или бизнес-софте. В общем всё правильно анализатор говорит делать II.

[redfox0]

Автор много написал текста, но так и не продемонстрировал, почему в short-circuit evaluation больше ветвлений.

Некий псевдоассемблер:

// if (a() && b() && c()) { foo(); }
rax = invoke a
.if rax == 0
    jmp next
.endif
rax = invoke b
.if rax == 0
    jmp next
.endif
rax = invoke b
.if rax == 0
    jmp next
.endif
invoke foo
next:

И:

// if (a() & b() & c()) { foo(); }
res = 0
rax = invoke a
and res, rax
rax = invoke b
and res, rax
rax = invoke c
and res, rax
.if res != 0  // только одно ветвление
    invoke foo
.endif

[Valerav76]

По моему скромному мнению в 2024 году программисты должны фокусироваться на написании понятного кода. Подобные бенчмерки будут меняться от железа и версии jvm. Оставьте оптимизацию производителям jvm. У них это лучше получиться.

[speshuric]

С одной стороны - да, по умолчанию и почти всегда лучше скучный и понятный код с минимумом WTF/KLOC. С другой стороны - наши процессоры уже лет 10 не растут в скорости однопотока, GPU и SIMD проковыривают путь крайне медленно (SIMD на x86 - 30 лет, GPGPU - 20), с многопоточным масштабированием тоже всё не просто, скорость памяти типа "растёт", но с огромным количеством оговорок (растёт максимальная пропускная способность, но не задержка, а пропускная способность растёт только для длинной последовательной серии операций или для нескольких каналов) .

Хотя о чём это я? В статье разбирается конкретно DBeaver - это пользовательское приложение на Java, если в нём и важны такие оптимизации, то явно не там, где они есть на самом деле. Несмотря на моё искреннее уважение к этому инструменту, большие объёмы данных его заставляют задуматься (в его оправдание - DataGrip тупит еще больше на той же Java). Приведённые в статье примеры явно не из построчной логики обработки. И ладно бы он был не быстрый, но стабильный, так ведь нет - есть куча мелких странных раздражающих багов. Получается, что тот, кто выбирает скорость в ущерб качеству, не получит ни качества ни скорости.