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

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

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

Show all headers | View raw

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? Zentrale Methoden
ge-inline-d? 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.

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). Pixel
werden dann nach Möglichkeit nicht in einer Klasse dargestellt, sondern
in einem Datentyp, der es erlaubt, die SIMD-Instruktionen des Prozessors
zu nutzen. Und wenn's sehr pressiert, werden die zentralen Routinen dann
in Assembler geschrieben.

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 habe zum Beispiel das Gefühl, dass yip nur einen der sechs
> Prozessorkerne nutzt... wo finde ich (für mich verständliche!)
> Informationen zum Thema Multithreading mit C++?

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.


  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