Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.iso-c++ > #2031

Re: Floyd-Steinberg - geht das nicht noch schneller?

Show all headers | View raw

Am 23.02.2017 um 02:14 schrieb Stefan Ram:
> Stefan Reuther <stefan.news@arcor.de> writes:
>> Dann pack da noch ein -O oder -O2 dazu und staune.
> 
>   Warum nicht »-03«?

Weil "-03" keine gültige Option ist :) und "-O3" zumindest im
Normalbetrieb für mich keinen sinnvollen Gewinn mehr bringt verglichen
mit dem Aufwand.

>> Dann könntest du schon einen Gewinn daraus ziehen, dass du
>> diese Klasse von "drei unsigned char" auf "ein uint32_t"
>> umbaust. "get_red" ist dann "return (pixel >> 16)", "set_red"
>> ist "pixel = (pixel & 0x00FFFF) | (value << 16)", und so
>> weiter.
> 
>   Hier wird
> 
> a.y = c;
> 
>   zu
> 
> movb    %dl, 49(%rsp)
> 
>   kompiliert (a ist eine struct mit drei chars x,y,z bei 48,
>   c befindet sich schon in edx).
> 
>   Aus
> 
> a = a&0xff00ff | c<<8;
> 
>   wird (jetzt ist a ein unsigned long bei 64,
>   c ist wieder schon in edx)
> 
> movl    64(%rsp), %eax
> andl    $16711935, %eax
> movl    %eax, %ecx
> movsbl  %dl, %eax
> sall    $8, %eax
> orl     %ecx, %eax
> movl    %eax, 64(%rsp)
> 
>   Ist das immer effizienter als ein einzelnes »movb«?

Interessanter wird das dann, wenn du mehrere solcher Operationen machst.

Speicherzugriffe sind teurer als Rechenoperationen. Bei
komponentenweisen Zugriffen werden halt mehrere Zugriffe generiert, den
uint32_t holt der Compiler in einem Rutsch. Wieviel davon der Cache auf
einem Desktop-Schlachtschiff wegoptimiert, kann ich zugegebenermaßen
nicht sagen, aber auf Embedded-Systemen hab ich durchaus schon solche
Effekte messen können.

Ein kleverer Compiler fasst
   a = (a & 0xFF00FF) | (g << 8);
   a = (a & 0xFFFF00) | b;
zu einem
   a = (x & 0xFF0000) | (g << 8) | b;
zusammen, und wenn du das in einer Schleife tust, wird das "<<" auch
noch aus der Schleife gezogen. Der uint32_t ist auch immer aligned, so
dass memcpy zumindest in einen schnelleren Pfad gehen wird als bei einem
misaligned struct {uint8 r,g,b,a} oder gar struct {uint8 r,g,b}.


  Stefan

Back to de.comp.lang.iso-c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Floyd-Steinberg - geht das nicht noch schneller? Jörg "Yadgar" Bleimann <yazdegird@gmx.de> - 2017-02-20 19:27 +0100
  Re: Floyd-Steinberg - geht das nicht noch schneller? ram@zedat.fu-berlin.de (Stefan Ram) - 2017-02-21 16:23 +0000
  Re: Floyd-Steinberg - geht das nicht noch schneller? Stefan Reuther <stefan.news@arcor.de> - 2017-02-21 18:49 +0100
    Re: Floyd-Steinberg - geht das nicht noch schneller? Markus Schaaf <mschaaf@elaboris.de> - 2017-02-21 21:47 +0100
    Re: Floyd-Steinberg - geht das nicht noch schneller? Jörg "Yadgar" Bleimann <yazdegird@gmx.de> - 2017-02-22 16:29 +0100
      Re: Floyd-Steinberg - geht das nicht noch schneller? Stefan Reuther <stefan.news@arcor.de> - 2017-02-22 19:07 +0100
        Re: Floyd-Steinberg - geht das nicht noch schneller? ram@zedat.fu-berlin.de (Stefan Ram) - 2017-02-23 01:14 +0000
          Re: Floyd-Steinberg - geht das nicht noch schneller? Stefan Reuther <stefan.news@arcor.de> - 2017-02-23 18:58 +0100
        Re: Floyd-Steinberg - geht das nicht noch schneller? Jörg "Yadgar" Bleimann <yazdegird@gmx.de> - 2017-03-22 02:23 +0100
          Re: Floyd-Steinberg - geht das nicht noch schneller? Stefan Reuther <stefan.news@arcor.de> - 2017-03-22 19:43 +0100
  Re: Floyd-Steinberg - geht das nicht noch schneller? Bonita Montero <Bonita.Montero@gmail.com> - 2017-02-23 18:27 +0100
    Re: Floyd-Steinberg - geht das nicht noch schneller? Stefan Reuther <stefan.news@arcor.de> - 2017-02-24 18:34 +0100

csiph-web