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


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

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

From Jörg "Yadgar" Bleimann <yazdegird@gmx.de>
Newsgroups de.comp.lang.iso-c++
Subject Re: Floyd-Steinberg - geht das nicht noch schneller?
Date 2017-02-22 16:29 +0100
Organization albasani.net
Message-ID <o8kapt$3iv$1@news.albasani.net> (permalink)
References <o8fcfi$am$1@news.albasani.net> <o8i24h.4ug.1@stefan.msgid.phost.de>

Show all headers | View raw


Hi(gh)!

On 21.02.2017 18:49, Stefan Reuther wrote:
> Am 20.02.2017 um 19:27 schrieb Jörg "Yadgar" Bleimann:
>> Jetzt habe ich also (danke, Stefan Reuther!) meinen
>> Floyd-Steinberg-Filter einwandfrei implementiert und lasse ihn gerade
>> per bash-Skript eine Sequenz von über 7000 Bildern bearbeiten... aber
>> irgendwie kommt mir das alles ziemlich behäbig vor, was die
>> Rechengeschwindigkeit angeht. Für 2000 Bilder (unkomprimierte TGAs, 533
>> x 400 Pixel) 69 Minuten, und das auf einem AMD-Hexacore mit 6 x 3,852
>> GHz... ließe sich da nicht noch einiges optimieren?
>
> Da kann man Bücher drüber schreiben. Die offensichtliche Frage natürlich
> zuerst: Compiler-Optimierung schon eingeschaltet?

So weit ich weiß, nicht... ich kompliere immer g++ quelle.cc -o kompilat

> Zentrale Methoden
> ge-inline-d?

Da müsste ich erstmal meinen "Aupperle" ausgraben, um nochmal 
nachzulesen, wie das geht...

Das erscheint mir auch so recht langsam.
>
> Ansonsten ist deine Implementierung natürlich sehr naiv (und das sage
> ich ganz ausdrücklich nicht abwertend): Du nutzt vector<vector<>>. Du
> nutzt die Bereichsprüfung per vector.at. Du nutzt Klassen für alles
> Mögliche. Das ist schön zum lernen und experimentieren, aber eben nicht
> schnell.

...ich bin doch nur ein besoffener Manta-Schrauber, der versucht, die 
Technik eines Formel-1-Rennwagens zu ergünden! :-)

> Echte[tm] Bildverarbeitungsalgorithmen arbeiten auf nacktem Speicher,
> also bestenfalls ein Vektor, auf dessen Inhalt dann am Ende per
> Pointer+Länge zugegriffen wird (die Größe ändert sich ja nicht).

Nein, Pixel bestehen an sich aus jeweils drei unsigned char-Werten... 
die müssen zum Rechnen natürlich in längere Typen umgewandelt werden!

> Pixel
> werden dann nach Möglichkeit nicht in einer Klasse dargestellt, sondern
> in einem Datentyp, der es erlaubt, die SIMD-Instruktionen

SIMD? Kann das mein Hexacore?

> des Prozessors
> zu nutzen. Und wenn's sehr pressiert, werden die zentralen Routinen dann
> in Assembler geschrieben.

Ouhauerha! Bevor ich mich da rantraue, lerne ich erstmal 6502-Assembler, 
damit ich meinen C 64 endlich mal richtig ausreizen kann... später 
könnte ich dann zum 68000 übergehen, hier steht nämlich auch noch ein 
Atari 1040 STFM, der sich mittlerweile schon ziemlich vernachlässigt 
fühlt...

> Das musst du dir nun nicht alles antun, aber schon das Umbauen von
> vector<vector<>> und at auf einen vector und [] dürfte einiges bringen.
>
> Ich weiß ja nicht, was dein Ausgangspunkt ist, aber ich würde vermutlich
> anfangen, erst einmal ein paar allgemeine Artikel zum Thema
> Multithreading reinzupfeifen, und danach etwas zur gewünschten
> Threading-Bibliothek der Wahl (Qt? C++11? pthreads?).
>
> Für den konkreten Fall, ich habe einen Algorithmus in ein Programm
> gegossen und will den maximal schnell auf viele Dateien loslassen,
> schreib ich allerdings meistens einfach ein Makefile und lass make das
> ganze auf Prozessebene parallelisieren.

Ich habe es mir gestern Nacht einfacher gemacht und einfach fünf 
Instanzen von yip gestartet, jede bearbeitete jeweils rund 7000 
Bilddateien, heute vormittag gegen halb elf war alles fertig! Aber mit 
deinen Vorschlägen wäre natürlich noch mehr Speed drin... aber alles 
eins nach dem anderen!

Bis bald im Khyberspace!

Yadgar

Back to de.comp.lang.iso-c++ | Previous | NextPrevious 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