@sokytsinolop: To może mieć ewentualny sens w jakichś językach interpretowanych, które wykonują kod linijka po linijce. Ale dla czytelności kodu zastanowiłbym się kilka razy przed zrobieniem czegoś takiego. A dla języków kompilowanych - tak jak koledzy wyżej wspomnieli, każdy współczesny kompilator zrobi to sam tak, aby było dobrze.
@fizyk20: nie loop-unrolling, tylko wektoryzacja. I jak ktoś się chce w to bawić, to powinien oznajmić kompilatorowi, że jest na to miejsce (__attribute__((aligned(16)))) @selenita66: w językach interpretowanych jakiekolwiek zyski z takiego zaciemnianego kodu znikną w odmętach narzutu środowiska.
@Razi91: Na ile to rozumiem, to wektoryzacja dopiero będzie, jak kompilator załatwi to poczwórne przypisanie jedną instrukcją. Samo przerobienie na taką pętlę to unrolling (przynajmniej częściowy). Ale mogę się mylić, ekspertem od terminologii nie jestem ;)
@fizyk20: w sumie oboje mamy rację. Generalnie kompilator powinien ogarnąć obie rzeczy jednocześnie i obie tu mogą zadziałać w tym przypadku. Z doświadczeń wiem że loop unrolling nie daje w obecnych x86 praktycznie żadnego zysku przy dłuższych pętlach.
Coooo? tak się robi?
źródło: comment_zR29VgMebTXrwxZEIFjlpYXND0Xhgoqg.jpg
PobierzNo i tam jest błąd, bo raczej nie powinno być 4 razy
X[n].Coś podobnego Duff's device
https://en.wikipedia.org/wiki/Duff%27s_device
Generalnie na pc-tach nie ma sensu tego używać(możliwe że kompilator zgłupieje, nie zoptymalizuje jak trzeba i będzie niższa wydajność ).
I jak ktoś się chce w to bawić, to powinien oznajmić kompilatorowi, że jest na to miejsce (
__attribute__((aligned(16))))@selenita66: w językach interpretowanych jakiekolwiek zyski z takiego zaciemnianego kodu znikną w odmętach narzutu środowiska.
Z doświadczeń wiem że loop unrolling nie daje w obecnych x86 praktycznie żadnego zysku przy dłuższych pętlach.