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


Groups > ger.ct > #586923 > unrolled thread

Mein Werk

Started byBonita Montero <Bonita.Montero@gmail.com>
First post2023-03-04 16:49 +0100
Last post2023-03-08 08:31 +0100
Articles 10 — 5 participants

Back to article view | Back to ger.ct


Contents

  Mein Werk Bonita Montero <Bonita.Montero@gmail.com> - 2023-03-04 16:49 +0100
    Re: Mein Werk Bonita Montero <Bonita.Montero@gmail.com> - 2023-03-04 16:49 +0100
    Re: Mein Werk Herwig <herwig.huener@t-online.de> - 2023-03-07 04:40 -0800
      Re: Mein Werk Hermann Riemann <nospam.ng@hermann-riemann.de> - 2023-03-07 15:37 +0100
        Re: Mein Werk Hermann Riemann <nospam.ng@hermann-riemann.de> - 2023-03-07 19:54 +0100
          Re: Mein Werk Lars Gebauer <lgebauer@live.de> - 2023-03-07 20:29 +0100
          Re: Mein Werk Hermann Riemann <nospam.ng@hermann-riemann.de> - 2023-03-08 08:33 +0100
            Re: Mein Werk Hermann Riemann <nospam.ng@hermann-riemann.de> - 2023-03-08 12:36 +0100
            Re: Mein Werk Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2023-03-08 12:02 +0000
      Re: Mein Werk Bonita Montero <Bonita.Montero@gmail.com> - 2023-03-08 08:31 +0100

#586923 — Mein Werk

FromBonita Montero <Bonita.Montero@gmail.com>
Date2023-03-04 16:49 +0100
SubjectMein Werk
Message-ID<ttvp6u$10kuu$1@dont-email.me>
Ich hab mir mal die Funktion fmod( double, double ) der glibc ange-
schaut. Auf jeden Fall berechnet die den Divsions-Rest zweier FP-Zahlen.
Das Ergebnis ist immer exakt berechenbar, d.h. im Gegensatz zur FP-Divi-
sion gibt es nie einen Präzisions-Verlust weil das Ergebnis immer klei-
ner als der Divisor ist.
Grundsätzlich ist das Verfahren das wie bei einer schriftlichen Divi-
sion, was Soft- oder Hardware-mäßig halt dann nach dem Subtract and
Shift-Verfahren durchgeführt wird. Dabei kann es bei der Implementa-
tion der glibc eine Menge unvorhersagbare Sprünge geben die die Pipe
flushen - die hab ich weg-optimiert. Auf jeden Fall kann es beim dem
Subtract and Shift weiter vorkommen, dass vorne dann Ziffern (binär)
wegfallen, dass für den nächsten Schritt dann der zwischenzeitliche
Divisions-Rest wieder an die normalisierte Stelle gerückt wird, dass
die führende Eins dann wieder an Bit 52 steht (von Null an gezählt).
Das ganze hab ich dann nicht iterativ gemacht, sondern ich nehme die
C++20-Funktion countl_zero die auf modernen CPUs (!= RISC-V) dann auf
eine dafür gedachte CPU-Instruktion mappt; das erspart dann wie gesagt
auch eine normalisierende Schleife.
Auf meinem Rechner ist meine Implementation mit meinem Benchmark mit
randomisierten Zahlen für die binäre Betrachtung von Divisor und Divi-
dend von Null bis 0x7FEFFFFFFFFFFFFF ziemlich genau 2,5 mal schneller
als die glibc.
Ich glaub ich schreib mal eine C-Version und reiche das mal bei den
glibc-Evangelisten auf der entsprechenden Mailingliste ein.

#include <bit>
#include <cstdint>
#include <cfenv>
#include <utility>

using namespace std;

double myFmod( double counter, double denominator )
{
	constexpr int MAX_EXP = 0x7FF;
	constexpr uint64_t
		SIGN_BIT = (uint64_t)1 << 63,
		EXP_MASK = (uint64_t)MAX_EXP << 52,
		IMPLCIT_BIT = (uint64_t)1 << 52,
		MANT_MASK = IMPLCIT_BIT - 1,
		QNAN_BIT = IMPLCIT_BIT >> 1;
	static auto bin = []( double d ) -> uint64_t { return 
bit_cast<uint64_t>( d ); };
	static auto dbl = []( uint64_t u ) -> double { return bit_cast<double>( 
u ); };
	uint64_t const
		bCounter = bin( counter ),
		bDenom = bin( denominator );
	auto NaN = []( bool raise ) -> double
	{
		if( raise )
			feraiseexcept( FE_INVALID );
		return dbl( SIGN_BIT | EXP_MASK | QNAN_BIT );
	};
	static auto zero = []( uint64_t b ) -> bool { return !(b & ~SIGN_BIT); };
	static auto maxExp = []( uint64_t b ) -> bool { return (b & EXP_MASK) 
== EXP_MASK; };
	static auto infMant = []( uint64_t b ) -> bool { return !(b & 
MANT_MASK); };
	static auto nonNanN = []( uint64_t b ) -> bool { return !maxExp( b ) || 
maxExp( b ) && infMant( b ); };
	if( zero( bCounter ) ) [[unlikely]]
		// +/-0.0 % ...
		if( !zero( bDenom ) ) [[likely]]
			// +/-0.0 % non-zero = +/-0.0
			return counter;
		else
			// +/-0.0 % +/-0.0 = raised-NaN
			return NaN( true );
	if( maxExp( bCounter ) ) [[unlikely]]
		// [Inf|QNaN|SNaN] % ...
		if( infMant( bCounter ) ) [[likely]]
			// Inf % ...
			if( nonNanN( bDenom ) ) [[likely]]
				// Inf % non-NaN = raised-NaN
				return NaN( true );
			else
				// Inf % NaN = NaN
				return NaN( false );
		else
			// NaN % ... = NaN = NaN
			return NaN( false );
	if( zero( bDenom ) ) [[unlikely]]
		// ... % +/-0.0
		if( !nonNanN( bCounter ) ) [[likely]]
			// non-NaN % +/-0.0 = raised-NaN
			return NaN( true );
		else
			// NaN % +/-0.0 = NaN
			return NaN( false );
	if( maxExp( bDenom ) ) [[unlikely]]
		// ... % [Inf|NaN|SNan]
		if( infMant( bDenom ) ) [[likely]]
			// ... % Inf
			if( !maxExp( bCounter ) ) [[likely]]
				// real % Inf = real
				return counter;
			else
				// [Inf|NaN|SNan] % Inf = NaN
				return NaN( false );
		else
			// ... % NaN = NaN
			return NaN( false );
	int
		counterExp = bCounter >> 52 & MAX_EXP,
		denomExp = bDenom >> 52 & MAX_EXP;
	uint64_t
		counterMant = (uint64_t)(bool)counterExp << 52 | bCounter & MANT_MASK,
		denomMant = (uint64_t)(bool)denomExp << 52 | bDenom & MANT_MASK;
	auto normalize = []( uint64_t &mant, int &exp )
	{
		unsigned bits = countl_zero( mant ) - 11;
		mant <<= bits;
		exp -= bits;
	};
	if( !counterExp ) [[unlikely]]
		// normalize counter
		normalize( counterMant, counterExp ),
		++counterExp;
	if( !denomExp ) [[unlikely]]
		// normalize denominator
		normalize( denomMant, denomExp ),
		++denomExp;
	int remExp = counterExp;
	uint64_t remMant = counterMant;
	for( ; ; )
	{
		int below = remMant < denomMant;
		if( remExp - below < denomExp ) [[unlikely]]
			break;
		remExp -= below;
		remMant <<= below;
		if( !(remMant -= denomMant) ) [[unlikely]]
		{
			remExp = 0;
			break;
		}
		normalize( remMant, remExp );
	};
	if( remExp <= 0 ) [[unlikely]]
		// denormal result
		remMant >>= -remExp + 1,
		remExp = 0;
	return dbl( bCounter & SIGN_BIT | (uint64_t)remExp << 52 | remMant & 
MANT_MASK );
}

[toc] | [next] | [standalone]


#586924

FromBonita Montero <Bonita.Montero@gmail.com>
Date2023-03-04 16:49 +0100
Message-ID<ttvp86$10kuu$2@dont-email.me>
In reply to#586923
Am 04.03.2023 um 16:49 schrieb Bonita Montero:

> Ich hab mir mal die Funktion fmod( double, double ) der glibc ange-
> schaut. Auf jeden Fall berechnet die den Divsions-Rest zweier FP-Zahlen.
> Das Ergebnis ist immer exakt berechenbar, d.h. im Gegensatz zur FP-Divi-
> sion gibt es nie einen Präzisions-Verlust weil das Ergebnis immer klei-
> ner als der Divisor ist.

Äh, als der Dividend.

[toc] | [prev] | [next] | [standalone]


#587188

FromHerwig <herwig.huener@t-online.de>
Date2023-03-07 04:40 -0800
Message-ID<1d24b6c5-bd12-4ef2-ad35-fa4a83d6e183n@googlegroups.com>
In reply to#586923
2023-03-07 13:42:00 +0100

> ...

> #include <bit> 

> ...

> }

Nett. - Wenn man so etwas sieht, wird einem klar, dass man
nie mehr ein Stück Code von dieser Grösse und Komplexität
schreiben wird - es gibt keinen, der einen dafür bezahlt, und
keinen Grund, eine solche Menge Zeit zu investieren, in der
man sonst bergsteigen, Flusi fliegen oder XBoxen nach
Passanten werfen könnte.

In den 77 Monaten seit BerufsEnde habe ich keine
programmierähnliche Tätigkeit gemacht - vielleicht ein bischen
Shell, um irgendwas zu korrigieren. Vermisst habe ich das
Programmieren nicht.

Und ich habe Programmieren vor Jahrzehnten für eine
Tätigkeit gehalten, die dem LustGewinn dient!

Herwig

[toc] | [prev] | [next] | [standalone]


#587196

FromHermann Riemann <nospam.ng@hermann-riemann.de>
Date2023-03-07 15:37 +0100
Message-ID<k6p0hmFmbtaU1@mid.individual.net>
In reply to#587188
Am 07.03.23 um 13:40 schrieb Herwig:
> 2023-03-07 13:42:00 +0100
> 
>> ...
> 
>> #include <bit>
> 
>> ...
> 
>> }
> 
> Nett. - Wenn man so etwas sieht, wird einem klar, dass man
> nie mehr ein Stück Code von dieser Grösse und Komplexität
> schreiben wird 

Du magst nicht der einzige ein der so denkt.

- es gibt keinen, der einen dafür bezahlt,

Eigene Programme können Zeit sparen
und eiiges machen, was sonst nicht erhältlich ist.


> und keinen Grund, eine solche Menge Zeit zu investieren,
> in der man sonst

> bergsteigen,

wenn der Körper mitspielt und/oder man die Reise in Kauf nimmt.

> Flusi fliegen

Kann langweilig werden.

> oder XBoxen nach Passanten werfen könnte.

Die könnten zurückwerfen..

> In den 77 Monaten seit BerufsEnde habe ich keine
> programmierähnliche Tätigkeit gemacht

Perry Rhodan gelesen?  Dann
Vom kreativ schaffenden Terraner zum geniessenden
Arkoniden gewechselt?

> - vielleicht ein bisschen Shell, um irgendwas zu korrigieren.

Shell ist für nicht winzige Programme IMHO wie
ls -l $(find / -name "*.jpg") 2> /dev/null
einfach schlecht zu lesen.

> Vermisst habe ich das Programmieren nicht.

Vermissen tue ich es nicht, aber für etliche Vorhaben
brauche ich es einfach.

Beispiel:
Schalte auf Grund von Bewegungsmelder in Abhängigkeit
  von Helligkeit Licht ein,
Lichtfarbe von Tageszeit abhängig ( nachts rot wegen schlafen)
  Um nicht zu blenden ändere die Helligkeit in angemessener
Geschwindigkeit.

Das  was mit smart von Fritzbox 6690 + WLAN Schalter in Betrieb ist:
Eine Lampe eingeschaltet von 5:30-7:00.

Und Alexa bzw. Siri kommandieren mag ich auch nicht,
Obige Bedingungen wird sie kaum können.

> Und ich habe Programmieren vor Jahrzehnten für eine
> Tätigkeit gehalten, die dem LustGewinn dient!

Programmieren ist basteln und Rätsel raten,
dazu oft mit Nutzeffekt.

Hermann
    der heute etwas an seinem Datei putz Programm
    ( neu in Python3 statt alt in C)
    gebastelt hat
    welches Dateien mit Ende ~ löscht  ( von emacs)
    links zu nicht vorhandenen Dateien löscht
    bei Bedarf leere Ordner und Dateien löscht
    Nicht gesetzte Schreibbits setzt
    ( was gut nach Kopien von CDs .. USB sticks sein kann)
    usw.

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]


#587204

FromHermann Riemann <nospam.ng@hermann-riemann.de>
Date2023-03-07 19:54 +0100
Message-ID<k6pfj5Fo52lU1@mid.individual.net>
In reply to#587196
Am 07.03.23 um 16:29 schrieb Stefan Ram:
> Hermann Riemann <nospam.ng@hermann-riemann.de> writes:
>> Hermann
>>     der heute etwas an seinem Datei putz Programm
>>     ( neu in Python3 statt alt in C)
>>     gebastelt hat
> 
>    Programmieren war für mich immer das wichtigste Hobby.

Für mich ist programmieren selbst hergestelltes Werkzeug.

>    Ich habe meine Webseiten bisher mit einem VBA-Programm
>    erstellt, das Microsoft®-Word-Dokumente nach HTML wandelt.

Mit Microsoft®-Word komme ich sehr schlecht zurecht

Ich editiere meine Webseiten ( und Dokumentationen) in "Mini" html.
So habe ich schon ab html 3.2 </td> weggelassen.
Das hat bisher noch kein von mir verwendeter browser gestört,
  ab html5 ist es erlaubt.
Und einige Seiten arbeite ich mit eigenem Programm für internet auf.
Wie z.B. einfügen von <head>

Früher war das Programm mal in C, irgendwann habe ich es neu in
Python3 kodiert. In Python3 gibt es die Klasse html
https://docs.python.org/3/library/html.parser.html

Als Aufbereitungsanweisung verwende ich z.B. pseudotags,
deren Namen mit _ enden . Etwa um das inhaltliche Änderungsdatum
weiter zu verwenden.

>    Jetzt bin ich gerade dabei, das neu zu programmieren,
>    wobei ich aber als Eingabe aber normale Textdateien und als
>    Programmiersprache Python nehme. Das System arbeitet derzeit
>    schon in einer halbfertigen Rohfassung.

Manchmal verwende ich auch *.csv Dateien
( Zeilenzerlegung mit zeile.rstrip().split(';') )

>    Heute habe ich gerade den Teil hinzugefügt, der es erlaubt,
>    mehrzeilige Programmlistings innerhalb eines Textes anzuzeigen.

Bei mir ist eine Sache,
Ich habe bei 4 provider bisher 8 www.*/index.html  urls
Vorher waren es 3 provider mit 4 www
Die provider haben unterschiedliche Bedingungen.

Das Programm muss ich noch erweitern
und auch noch die Eingabedateien für (s)ftp
per Programm generieren.

Hermann
    derzeit u.a. mit PC "Umzüge" beschäftigt.
    z.B. eine PC mit SuSE 42.3
    neu formatieren, SuSE tumbleweed installieren
    und für einen Zweck, der derzeit noch weitgehend
    mit einem anderen PC unter SuSE 15.0 erledigt wird,
    neu mit erheblichen Änderungen einrichten.

-- 
http://www.hermann-riemann.de
http://www.herman-riemann.de
http://www.hermannriemann.de
http://www.hermanriemann.de

[toc] | [prev] | [next] | [standalone]


#587206

FromLars Gebauer <lgebauer@live.de>
Date2023-03-07 20:29 +0100
Message-ID<tu83b2$fq46$1@dont-email.me>
In reply to#587204
Am 07.03.2023 um 20:06 schrieb Stefan Ram:
> Mein bisheriges Word-System hat es mir überhaupt noch nicht erlaubt,
> Tabellen zu verwenden. Aber das soll sich nun bald ändern!

Immerhin! Wird das noch vor 2033 der Fall sein?

> Mein Python-Programm schreibt alle ausgegebenen HTML-Dateien in
> ein Verzeichnis. Dann habe ich eine kleine Stapeldatei, welche
> diese Dateien mit Hilfe eines Datenübertragsprogramms zum Provider
> kopiert und danach in ein anderes Verzeichnis verschiebt.

Bestechende Idee! Vielleicht solltest Du mal Abhay Bhushan Pandey 
kontaktieren. Iirc verfolgte der einen ganz ähnlichen Gedanken, als er 
1971 den RFC 114 veröffentlichte.
-- 
| Die Drachenschlucht ist ein Ort voller Magie
| Wo einst ein Lindwurm hauste und schrie
--ChatGPT versuchte sich an einem Gedicht über die Drachenschlucht bei 
Eisenach

[toc] | [prev] | [next] | [standalone]


#587217

FromHermann Riemann <nospam.ng@hermann-riemann.de>
Date2023-03-08 08:33 +0100
Message-ID<k6qs2lFkg2U1@mid.individual.net>
In reply to#587204
Am 07.03.23 um 20:06 schrieb Stefan Ram:
> Hermann Riemann <nospam.ng@hermann-riemann.de> writes:
>> Ich editiere meine Webseiten ( und Dokumentationen) in "Mini" html.
>> So habe ich schon ab html 3.2 </td> weggelassen.
> 
>    Mein bisheriges Word-System hat es mir überhaupt noch nicht erlaubt,
>    Tabellen zu verwenden. Aber das soll sich nun bald ändern!

Wenn ich eine eine reinen Text Datei Tabellen als Vorlage verwenden 
würde, würde ich die Zeilen mit $tab beginnen und $/tab beenden.
und die Elemente durch | trennen, da dieses Zeichen gut lesbar ist.

>> Die provider haben unterschiedliche Bedingungen.
> 
>    Da ich nur reines HTML (als Ausgabe) verwende, sollte das
>    überall gehen. Das Verfahren zum Hochladen könnte natürlich
>    vom Provider abhängen.

Ich habe die Dateien meist in einer Anordnung, wie sie
auch für den Leser vorhanden ist. Lediglich Bilder
und css müssen umgeordnet werden. Dazu kommt noch
andere Anordnungen für deutsch und englische Webseiten.
Die urls werden für einem Ausgabemodell (auch zum testen)
angepasst, da ich innerhalb eigener Seiten relative urls
( Beispiel  <a href="tab/satire.html">Satire</a> verwende.
Dazu kommen mehrfache Ausgaben mit etwas unterschiedlicher Anordnung.

>    Mein Python-Programm schreibt alle ausgegebenen HTML-Dateien in
>    ein Verzeichnis. Dann habe ich eine kleine Stapeldatei, welche
>    diese Dateien mit Hilfe eines Datenübertragsprogramms zum Provider
>    kopiert und danach in ein anderes Verzeichnis verschiebt.

ftp und sftp kennen cd und lcd so das nachträgliche Verschiebung
mir nicht praktisch erscheint.

Datenübertragsprogramm klingt nach windows.
ftp und sftp nach Linux

Hermann
    der bei Strato einzelne Dateien eventuell
    mit deren GUI übertragen würde,
    aber ansonsten bei allen provider ftp bzw sftp vorzieht.

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]


#587221

FromHermann Riemann <nospam.ng@hermann-riemann.de>
Date2023-03-08 12:36 +0100
Message-ID<k6raajF2o0eU1@mid.individual.net>
In reply to#587217
Am 08.03.23 um 12:08 schrieb Stefan Ram:
> Hermann Riemann <nospam.ng@hermann-riemann.de> writes:
>> und css müssen umgeordnet werden. Dazu kommt noch
>> andere Anordnungen für deutsch und englische Webseiten.
> 
>    Webseiten, die denselben Inhalt haben sollen, aber einmal
>    auf deutsch und einmal auf englisch, werden von meinem neuen
>    System besonders unterstützt:
> 
>    Man kann die Absätze in den beiden Sprache so schreiben, daß
>    die Übersetzung direkt beim Original steht, und das System
>    trennt dies dann auf zwei Seiten.
> 
>    Man kann beispielsweise folgende Eingabedatei schreiben:
> 
> de:  In diesem Kurs geht es um Python.
> en:  This course is about Python.
> 
> de:  Zuerst behandeln wir die Installation von Python.
> en:  First we cover the installation of Python.
> 
>    . Dabei kann man die englische Übersetzung eines Satzes oder
>    Absatzes direkt unter der deutschen Version schreiben.
>    Dies erleichtert spätere Überarbeitungen, bei denen die
>    deutsche und englische Version eines Textes beide analog
>    verändert werden sollen.
> 
>    Mein neues System macht dann daraus zwei Webseiten:
> 
>    Python-de.html
> 
> In diesem Kurs geht es um Python.
> Zuerst behandeln wir die Installation von Python.
> 
>    Python-en.html
> 
> This course is about Python.
> First we cover the installation of Python.
> 
>    . (Dies ist auch bereits implementiert.)

Das lohnt sich derzeit bei mir nicht.

Wegen der wenigen kleinen Quelltextzeilen mit englisch
( Siehe  <http://www.herman-riemann.de>
   mit Unterseiten z.B impressum und JavaScript )
   und <http://www.hermann-riemann.eu> )
mag ich keinen großen Programmieraufwand treiben.

Die englischen Seiten würde erst mal nur ich wegen Impressum
und Teilnahme an newsgroups in englisch brauchen.

Obiges würde ich vielleicht darstellen mit
<de_>In diesem Kurs geht es um Python.</de_>
<en_>First we cover the installation of Python.</en_>
<eo_>"in esperanto"</eo_>
so das der html Parser mich bei der Zerlegung unterstützt.

Die Zerlegung würde zu Ergebnissen führen unter

<http://www.hermann-riemann.eu/de>
<http://www.hermann-riemann.eu/en>
<http://www.hermann-riemann.eu/eo>

( Dies existiert derzeit nicht.)

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]


#587223

FromStefan+Usenet@Froehlich.Priv.at (Stefan Froehlich)
Date2023-03-08 12:02 +0000
Message-ID<1t640878c2i1a3d17n3e8%sfroehli@Froehlich.Priv.at>
In reply to#587217
On Wed, 08 Mar 2023 12:08:28 Stefan Ram wrote:
> Webseiten, die denselben Inhalt haben sollen, aber einmal auf
> deutsch und einmal auf englisch, werden von meinem neuen System
> besonders unterstützt:

>   Man kann die Absätze in den beiden Sprache so schreiben, daß die
>   Übersetzung direkt beim Original steht, und das System trennt
>   dies dann auf zwei Seiten.

>   Man kann beispielsweise folgende Eingabedatei schreiben:
> 
> de:  In diesem Kurs geht es um Python.
> en:  This course is about Python.
> 
> de:  Zuerst behandeln wir die Installation von Python.
> en:  First we cover the installation of Python.

Sollte das eine größere Anzahl an Seiten betreffen, würde ich
ernsthaft über die Verwendung von gettext nachdenken. Damit hast
Du die Eingabedateien in einer Sprache (übersichtlicher) und die
Übersetzungen innerhalb einer einzigen Datei (auch das ist
übersichtlicher). Nachteilig sind dafür die zwei getrennten
Arbeitsschritte; je größer das Projekt, umso eher lohnt sich das.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Ungewöhnliches für gewöhnliche Leute: Stefan, der Stein der Weisen!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]


#587216

FromBonita Montero <Bonita.Montero@gmail.com>
Date2023-03-08 08:31 +0100
Message-ID<tu9dhk$qn7p$1@dont-email.me>
In reply to#587188
Am 07.03.2023 um 13:40 schrieb Herwig:

 > Nett. - Wenn man so etwas sieht, wird einem klar, dass man
 > nie mehr ein Stück Code von dieser Grösse und Komplexität
 > schreiben wird - es gibt keinen, der einen dafür bezahlt,
 > und keinen Grund, eine solche Menge Zeit zu investieren, ...

Ich hab das jetzt der glibc angeboten und die wollten was, was 1:1
kompatibel ist. Ich mach das die Tage mal als drop-in replacement
fertig. Der Original-Code der heute noch Bestand hat ist von Sun
und genau 30 Jahre alt.
Mein Code ist nur schnell wenn Du eine CPU hast die sowas wie die
beidem Instruktionen SETcc (Byte-Register auf Null oder Eins in
Abhängigkeit der Flags setzen) und BSR (Anzahl der führenden, also
höherwertigen, Nullen in einem Register zählen) hast. x86 und ARM
haben beides bzw. x86 schon seit dem 486.

Ich mein fmod() ist eine wirklich selten genutzte Funktion und daher
tut diese Optimierung nicht wirklich so richtig not. Aber eine andere
Funktion wird nämlich etwas häufiger, im Einzelfall auch wirklich mit
hoher Frequenz, genutzt, und das ist pow().
Dafür hab ich mir auch eine Optimierung ausgedacht. Und zwar arbeitet
pow() ja intern mit einer Multiplikations-Reihe von Elementen die je-
weils x ^ (2 ^ N) sind. N ist jeweils die Position des gesetzte Bits
im Exponenten. D.h. man geht vom Bit Null hoch und quadriert die Basis
immer weiter und multipliziert das mit dem letzten Wert. Bei den Nachk-
omma-Stellen wird dann immer sukzessive die Wurzel von der Basis gezogen
und der wert entsprechend wenn das Bit gesetzt ist auch weiter multi-
pliziert.
So macht es auch die glibc, aber das Problem dabei ist, dass immer wie-
der gepüft wird ob ein Bit gesetzt ist und dann jeweils der vorherige
Wert multipliziert wird. Da es bei den gesetzten Bits im Exponenten
eigentlich nie regelmäßige Muster gibt hat schlägt die Sprungvorhersage
in ca. 50% der Fälle fehl und flusht die Pipe. Daher habe ich das so
gemacht:
	result = result * (bit * sq + (bit ^ 1)).
result ist das Ergebnis bzw. der vorläufige Zwischenwert dazu und ein
double, bit ist einfach ein int das der aktuelle Wert des Bits für das
eine Multiplikation durchgeführt werden soll oder nicht darstellt. Die
Variable result wird *immer* multipliziert, entweder wenn das Bit nicht
gesetzt ist mit sich selbst oder mit sq wenn das Bit gesetzt ist. Würde
ich hier Operationen mit Ganzzalen machen könnte ich sowas wie ein con-
ditional move machen, aber zumindest auf x86 gibt's diese Operation
nicht für FP-Operanden.
Grundsätzlich setzt obige Operation noch voraus, dass es eine schnelle
Wandlung von Ganzzahlen in Integer-Registern in FP-Zahlen in FP-Regis-
tern gibt; das ist zumindest auf x86 und ARM der Fall.

[toc] | [prev] | [standalone]


Back to top | Article view | ger.ct


csiph-web