Article View: pl.comp.lang.asm
Article #2223Re: Odwracanie kolejności bajtów w tablicy
From: Wojciech Muła
Date: Fri, 23 Apr 2010 21:56
Date: Fri, 23 Apr 2010 21:56
80 lines
3426 bytes
3426 bytes
Andrzej Grażyński <grazynsk@petex.com.pl> wrote: > Jak pamiętasz, zadałem na początku pytanie: czy przy odwracaniu > kolejności bajtów BSWAP może się do czegoś przydać? > > Jaki wniosek? Wniosek jest taki, że się bardzo przydaje. Bez wielkiego wysiłku mamy przyspieszenie 2 razy, przy rozwinięciu pętli ponad 3 razy (w stosunku do wersji bajt po bajcie). > Co prawda w ogólnym przypadku długość pola nie jest wielokrotnością 4, > ale zaprezentowany przeze mnie algorytm po wykonaniu serii instrukcji > BSWAP wykonuje jeszcze CO NAJWYŻEJ DWIE ZAMIANY, czyli dodatkowy koszt > jest stały i niewielki. W ogólnym przypadku pola ładowane/zapisywane > do/z rejestrów EAX i EDX nie są wyrównane do DWORD, co też może wydłużać > czasy podane powyżej Będę jeszcze jutro albo pojutrze testował więcej i wtedy przygotuję jakiś nadający się do wglądu program. Na razie wstępnie zaobserwowałem, że niewyrównane dane dają spowolnienie 2-3 krotne (dla BSWAP mniejsze, dla rozkazów SSE większe). > (a propos: czy rozmiar tablicy będący wielokrotnością 32 gwarantuje, > że cała tablica będzie wyrównana na adresie podzielnym przez 32? > Chyba jednak nie...). Procedury zakodowałem jako wstawki asemblerowe w GCC, mam w programie duże statyczne tablice, które na pewno były wyrównane do granicy 16 bajtów (a może nawet do granicy strony), bo inaczej by wersje SSE nie zadziałały. :) > Skoro już wziąłeś się za pomiary, to spróbuje porównać moją procedurę z > naiwnym przestawianiem bajtów. > > PUSH EBX > PUSH ESI > PUSH EDI > > CLD > > LEA EDI,[ESI+ECX-4] > > MOV EBX,ECX > > ADD ECX,4 > SHR ECX,3 > JZ @@Partial > > @@Loop: > LODSD > MOV EDX,[EDI] > BSWAP EAX > BSWAP EDX > STOSD > MOV [ESI-4],EDX > SUB EDI,8 > LOOP @@Loop Zmartwię Cię - na Core 2 to jest dramatycznie wolne, niekiedy wolniejsze od wersji bajt po bajcie, a jeśli szybsze to nieznacznie tylko. Wszystko psuje pewnie lods/stos. Mój kod jest natomiast taki: 1: mov eax, [esi] mov ebx, [edi] bswap eax bswap ebx mov eax, [edi] mov ebx, [esi] add esi, 4 sub edi, 4 cmp esi, edx ; edx = esi + 4*(ecx/2) jne 1 I te czasy dla tablic 32-bajtowych wynoszą mniej więcej: * bajt po bajcie - 400 ms / 100% * Twoje BSWAP - 490 ms / 120% * moje BSWAP - 180 ms / 45% w.
Technical Details
Message-ID:
<20100423235642.f5548b69.wojciech_mula@poczta.null.onet.pl.invalid>Path:
mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!not-for-mailReferences:
<20100422191115.9902fe58.wojciech_mula@poczta.null.onet.pl.invalid> <hqrujb$r3j$1@news.onet.pl>Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!not-for-mail From: Wojciech Muła <wojciech_mula@poczta.null.onet.pl.invalid> Newsgroups: pl.comp.lang.asm Subject: Re: Odwracanie kolejności bajtów w tablicy Date: Fri, 23 Apr 2010 23:56:42 +0200 Organization: http://onet.pl Lines: 90 Message-ID: <20100423235642.f5548b69.wojciech_mula@poczta.null.onet.pl.invalid> References: <20100422191115.9902fe58.wojciech_mula@poczta.null.onet.pl.invalid> <hqrujb$r3j$1@news.onet.pl> NNTP-Posting-Host: public-gprs99067.centertel.pl Mime-Version: 1.0 X-Trace: news.onet.pl 1272059814 18773 79.162.4.253 (23 Apr 2010 21:56:54 GMT) X-Complaints-To: niusy@onet.pl NNTP-Posting-Date: Fri, 23 Apr 2010 21:56:54 +0000 (UTC) X-Newsreader: Sylpheed 2.5.0 (GTK+ 2.10.14; i686-pc-mingw32) Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit