[Blackhorn]

#programowanie #java
Na p0lskich uczelniach bez zmian...

[Zelber]

@leoha: Tylko należy tutaj zadać pytanie jaki wpływ na wydajność programu ma samo iterowanie po kolekcji, a jaki pozostałe operacje wykonywane na jej elementach. W rzeczywistych przykładach okaże się, że optymalizacja pętli spowodowała wzrost wydajności o oszałamiające 0.01% ( ͡° ͜ʖ ͡°)

Tak jak w przypadku uC taka zabawa może mieć sens, tak w przypadku helloworlda w javie już niekoniecznie.

[metaforyczny_kierowca]

@Blackhorn: (c) by maf i wszystko jasne ;).

[l.....x]

@Blackhorn: Zapraszamy na #pwr, na tym mądrości szanownego doktora się nie kończą xD

[InformacjaNieprawdziwaCCCLVIII]

@leoha: Jeśli masz komputer z lat '80 albo jakiś super-low-power mikrokontroler, to wtedy faktycznie, loop unrolling ma sens. Natomiast współczesne procesory są wyposażony w ten cud techniki:
https://en.wikipedia.org/wiki/Branch_predictor
Który powoduje że przy pętlach powyżej 10 wykonań skoki są praktycznie darmowe

[GotoFinal]

@leoha: po 1: koszt samej iteracji vs operacje tam zazwyczaj sprawia że różnica jest niewidoczna
po 2: java sobie sama zrobi unrolla a nawet czasem zwektoryzuje

@InformacjaNieprawdziwaCCCLVIII: fun fact: taki wyjątek potrafi pomóc, ale po 1: pętla musi być w #!$%@? duża, po 2: operacje w niej w #!$%@? proste, po 3: catch pusty, i jeszcze pewnie coś pomijam. Ale no, nie warto w 99.9999% przypadków.

[IdzPanZTakimTym]

@Blackhorn: Jezusie Cytrusie, co za bzdety XD

[GotoFinal]

1. Nie daje nic (kompilator Javy sam jest w stanie zrobić tę optymalizację)

@InformacjaNieprawdziwaCCCLVIII: no nie do końca, tylko zakładając że to jakaś tablica/ArrayList, czasem warto pamiętać, bo raz widziałem że ktoś napisał coś takiego a .size w środku miało jakieś synchronizacje/locki i jebut po wydajności.

[ni0bi]

@leoha:
Nie widze roznicy w C:

[Zelber]

@ldefix:

Zapraszamy na #pwr, na tym mądrości szanownego doktora się nie kończą xD

Z chęcią je przygarnę, pisz ( ͡° ͜ʖ ͡°)

[sweet_dream99]

int i == 0

(ʘ‿ʘ)

[GotoFinal]

@farmaceut: o samo zmniejszenie ilości wywołania pętli - tak, to daje zysk wydajnościowy, no ale pytanie jak często wykonujesz kod tego typu by ten zysk poczuć xD

[c.....c]

@Blackhorn: oi hui

[miszczo997]

@ni0bi: a tutaj jest różnica, też w C (13 strona)
https://ww1.microchip.com/downloads/en/AppNotes/doc8453.pdf
edit:
W sumie to masz rację, niżej jest:
If -O3 option is enabled in this example, the compiler will unroll the loop automatically
and generate the same code as unrolling loop manually.

[vytah]

@leoha: Instrukcja LOOP jest wolniejsza niż napisanie tego samego przy użyciu kilku instrukcji, a współczesne kompilatory jej nie emitują. Ostatni procesor, na jakim opłacało się użyć LOOP, to Intel 286.
Jeśli zaś chodzi o liczenie w górę lub w dół jako takie, to kompilator sam to zmieni, jeśli uzna, że jest to poprawne i opłacalne.

[ni0bi]

@miszczo997: na 13 stronie masz porownanie petli vs bez petli, a ja pisze o o petli for gdzie masz inkrementacje i dekrementacje.

[Antyradek]

@Blackhorn: Wykładał to profesor, który uczył się programowania w C w latach 80, kiedy kompilator faktycznie głównie przepisywał kod na asemblera.

[miszczo997]

@ni0bi: myślałem, że odnosisz się do tego unrollingu. Nie było tematu.

[Latawiec]

@Blackhorn: Ktoś popłynął mocno xD Benchmark w debugu na pewno dawał "oczekiwany" wynik.

Niemniej... jest jeden przykład podobnej optymalizacji, która do niedawna nie była wspierana przez kompilator - kolejność iteracji w wielowymiarowych tablicach.

Czyli:

int foo[10][10];

for (int i=0; i<10; ++i) {
 for (int j=0; j<10; ++j) {
 int val = foo[i][j]; // dobrze!
 // int val = foo[j][i]; źle :(
 }
}

A to przez cache-friendly data access. Skakanie po

[Lewo]

@ldefix: który to?