[m.....y]

co będzie szybsze?
var counter = new AtomicInteger();

if (counter.increamentAndGet() >= 10) {
counter.set(0);
run();
}

if (counter.increamentAndGet. % 10 == 0) {
run();
}

#java #programowanie

[Eoghan]

@mistyk-gehenny: kod1 i kod2 nie robią tego samego, więc porównanie nie do końca ma sens

[s.....e]

@mistyk-gehenny: xD
ja bym użył tego które zadziała poprawnie

[j.....6]

@mistyk-gehenny: kolejne konto? ( ͡° ͜ʖ ͡°)

[93michu93]

@mistyk-gehenny: jesli counter bylby przewidywalny tzn. np. 0,1,2,3,4.., n-1, n to mysle, ze wieksze rowne byloby szybsze dzieki branch prediction.

[Saly]

@mistyk-gehenny: na logikę modulo: niby jest wolniejsze, jednak dwa zapisy/dwa memfence vs jeden powinny przeważać. Benchmarkując https://quick-bench.com/q/On5Yq3jlbC35CDKk0LFOY8-7zJY wychodzi na to, że jedna wersja działa szybciej na gcc a druga na clangu, więc można powiedzieć, że wyniki są zbliżone. Tyle, że wersja modulo będzie działać tym lepiej im więcej writerów, bo synchronizacja pamięci pomiędzy rdzeniami jest mniejsza

[Saly]

@mistyk-gehenny: no i jak się da to możesz zamienić 10 na 8 albo 16. Liczenie modulo dla potęg 2 jest dużo szybsze https://gcc.godbolt.org/z/PP1e4vfY8

[kazik117]

@Saly: to jest java, a nie c++.
@mistyk-gehenny: może sprofiluj sobie i zobacz, które w Twoim przypadku jest szybsze.

Nie zakładałbym, większej różnicy.

[Saly]

@kazik117: mechanizm działania jest ten sam, co za różnica?

[kazik117]

Z tym, że w jvm różnica na takich mikrooptymalizacjach zostanie zjedzona narzutem wykonania i imo nie jest to warte świeczki.

[Saly]

@kazik117: ale dyskusja jest o tym co jest szybsze a nie, czy to ma sens. Nawet wtedy wszystko zależy od przypadku użycia. Wolne/Szybkie rzeczy pisze się zarówno w C++ jak i w Javie. Jakby to były bebechy jakiegoś frameworka to taka optymalizacja mogłaby mieć sens, tak samo przy jakimś HFT. Narzut też powinien być zerowy w porównaniu do C++, bo Hotspot dobrze optymalizuje takie pętle + operacje na atomicach używają intrinsiców,