<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[double - caching]]></title><description><![CDATA[<p>Wir haben bei uns durch Profiling festgestellt, dass eine Methode, die wir benutzen, bis zu 50 % der Ausführungszeit frisst. Das kommt nicht von irgendwoher, die Methode ist aus nem 3rdParty, also nicht von uns, recht Komplex und ein zentraler Anlaufpunkt. Das Ergebnis der Methode ist ein double. (Ums genau zusagen, macht diese Methode geografische Projektionen)<br />
Da sie der Kern der Anwendung ist, habe ich darüber nachgedacht, ob es sich lohnt, einen cache für die Werte zu benutzen.<br />
Wenn wir bei doubles bleiben, würd ich eine map&lt;double,double&gt; anlegen, und ihr etwa 10 mb an an Speicherplatz geben. Was wohl ungefähr 1024 * 1024 * 10 / 64 ca 160.000 doubles wären (was sehr wenig ist)</p>
<p>Mein Problem ist, ich muss ja mitunter zusehen, dass die map nicht zu groß wird, zum anderen muss ich ein double IS_EQUAL benutzen, was kein reines look up ist (Ungenauigkeit und so)<br />
Sprich direkter Zugriff auf Map is so nicht gegeben, außer die doubles kommen nicht in voller präzision da rein, sondern schon um ein DELTA reduziert. Dann kann ich mein eingehendes Double auch auf die Präzision reduzieren und ein direktes look up machen.</p>
<p>Allerdings wirkt das für mich nicht gerade performance-schonender. Es gibt im Grunde zwei Szenarion: Framerate ohne Benutzer Interaktion (sehr viele doubles bleiben gleich) und Framerate während ein Benutzer Funktionen wie Zoom ausführt (sehr viele doubles ändern sich auf einmal)<br />
Kritisch ist natürlich wenn Benutzeraktion statt findet, da dort die lags am ehesten zu spüren sind. Nun gewinnen wir garnichts, wenn das caching super klappt, solange keine benutzeraktion vorhandenen ist und bei der benutzer aktion ständig cache misses und die damit verbundenen kosten des hinzufügens des wertes und des truncate der map auf einen konstanten faktor.</p>
<p>Hat jemand ein paar Tipps oder Kommentare?</p>
<p>Danke</p>
]]></description><link>https://www.c-plusplus.net/forum/topic/252448/double-caching</link><generator>RSS for Node</generator><lastBuildDate>Mon, 14 Sep 2026 11:27:41 GMT</lastBuildDate><atom:link href="https://www.c-plusplus.net/forum/topic/252448.rss" rel="self" type="application/rss+xml"/><pubDate>Tue, 20 Oct 2009 06:23:23 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to double - caching on Tue, 20 Oct 2009 06:23:23 GMT]]></title><description><![CDATA[<p>Wir haben bei uns durch Profiling festgestellt, dass eine Methode, die wir benutzen, bis zu 50 % der Ausführungszeit frisst. Das kommt nicht von irgendwoher, die Methode ist aus nem 3rdParty, also nicht von uns, recht Komplex und ein zentraler Anlaufpunkt. Das Ergebnis der Methode ist ein double. (Ums genau zusagen, macht diese Methode geografische Projektionen)<br />
Da sie der Kern der Anwendung ist, habe ich darüber nachgedacht, ob es sich lohnt, einen cache für die Werte zu benutzen.<br />
Wenn wir bei doubles bleiben, würd ich eine map&lt;double,double&gt; anlegen, und ihr etwa 10 mb an an Speicherplatz geben. Was wohl ungefähr 1024 * 1024 * 10 / 64 ca 160.000 doubles wären (was sehr wenig ist)</p>
<p>Mein Problem ist, ich muss ja mitunter zusehen, dass die map nicht zu groß wird, zum anderen muss ich ein double IS_EQUAL benutzen, was kein reines look up ist (Ungenauigkeit und so)<br />
Sprich direkter Zugriff auf Map is so nicht gegeben, außer die doubles kommen nicht in voller präzision da rein, sondern schon um ein DELTA reduziert. Dann kann ich mein eingehendes Double auch auf die Präzision reduzieren und ein direktes look up machen.</p>
<p>Allerdings wirkt das für mich nicht gerade performance-schonender. Es gibt im Grunde zwei Szenarion: Framerate ohne Benutzer Interaktion (sehr viele doubles bleiben gleich) und Framerate während ein Benutzer Funktionen wie Zoom ausführt (sehr viele doubles ändern sich auf einmal)<br />
Kritisch ist natürlich wenn Benutzeraktion statt findet, da dort die lags am ehesten zu spüren sind. Nun gewinnen wir garnichts, wenn das caching super klappt, solange keine benutzeraktion vorhandenen ist und bei der benutzer aktion ständig cache misses und die damit verbundenen kosten des hinzufügens des wertes und des truncate der map auf einen konstanten faktor.</p>
<p>Hat jemand ein paar Tipps oder Kommentare?</p>
<p>Danke</p>
]]></description><link>https://www.c-plusplus.net/forum/post/1795124</link><guid isPermaLink="true">https://www.c-plusplus.net/forum/post/1795124</guid><dc:creator><![CDATA[Seikilos]]></dc:creator><pubDate>Tue, 20 Oct 2009 06:23:23 GMT</pubDate></item><item><title><![CDATA[Reply to double - caching on Tue, 20 Oct 2009 07:37:18 GMT]]></title><description><![CDATA[<p>Also für mich hört sich das Ganze eher nach Interpolation an...</p>
<p>Eine weitere Sache ist, dass man asynchron im Hintergrund die nächste Zoomstufe vorberechnen kann, wenn der User noch gar nicht das zoom-Kommando gegeben hat.</p>
]]></description><link>https://www.c-plusplus.net/forum/post/1795144</link><guid isPermaLink="true">https://www.c-plusplus.net/forum/post/1795144</guid><dc:creator><![CDATA[Bloops]]></dc:creator><pubDate>Tue, 20 Oct 2009 07:37:18 GMT</pubDate></item><item><title><![CDATA[Reply to double - caching on Tue, 20 Oct 2009 07:54:09 GMT]]></title><description><![CDATA[<p>Was hat das mit Interpolation zutun? Ich will keine Zwischenwerte errechnen.</p>
<p>Das mit asynchronen irgendwas wird kaum möglich sein. Wir setzen sehr viel Paging ein, weil die visualisierten Datenmengen im GB bereich liegen. Jede mögliche Benutzeraktion kann hier nicht vorberechnet werden. Weil Scrollen und Zoomen (nur zwei der vielen Interaktionen) nicht in alle Kombinationen berechnet werden können (Kachelung, LOD)</p>
]]></description><link>https://www.c-plusplus.net/forum/post/1795155</link><guid isPermaLink="true">https://www.c-plusplus.net/forum/post/1795155</guid><dc:creator><![CDATA[Seikilos]]></dc:creator><pubDate>Tue, 20 Oct 2009 07:54:09 GMT</pubDate></item><item><title><![CDATA[Reply to double - caching on Tue, 20 Oct 2009 08:25:23 GMT]]></title><description><![CDATA[<p>Vielleicht sagst Du noch, wie diese Double-Werte benutzt werden.</p>
<p>Ich habe eventuell einen ähnlichen Fall: Eine recht komplizierte Abbildung von 3D nach 2D, die aber in einer kleinen Umgebung jeweils näherungsweise eine affinlineare Abbildung ist. Ich berechne daher einige Werte auf einem Gitter vor und interpoliere dann dazwischen, weil's so viel schneller geht.</p>
]]></description><link>https://www.c-plusplus.net/forum/post/1795169</link><guid isPermaLink="true">https://www.c-plusplus.net/forum/post/1795169</guid><dc:creator><![CDATA[Sebastian Pizer]]></dc:creator><pubDate>Tue, 20 Oct 2009 08:25:23 GMT</pubDate></item><item><title><![CDATA[Reply to double - caching on Tue, 20 Oct 2009 08:32:27 GMT]]></title><description><![CDATA[<p>Das wird natürlich auch so gemacht.<br />
Es werden Texturen aufgezogen und nur dort zwsichen berechneten Werten interpoliert. Das ist kein Thema.<br />
Da wir aber noch ein Grid haben und einzelne Objekte, die korrekt in der projezierten 2D Ebene (ohne Textur) plaziert werden müssen. Muss der Update dieser Objekte ständig durchgeführt werden.<br />
Die Doublewerte sind die Koordinaten der Objekte, die wirklich per Vertex projeziert werden müssen</p>
]]></description><link>https://www.c-plusplus.net/forum/post/1795174</link><guid isPermaLink="true">https://www.c-plusplus.net/forum/post/1795174</guid><dc:creator><![CDATA[Seikilos]]></dc:creator><pubDate>Tue, 20 Oct 2009 08:32:27 GMT</pubDate></item><item><title><![CDATA[Reply to double - caching on Tue, 20 Oct 2009 09:58:02 GMT]]></title><description><![CDATA[<p>Einen double zu kürzen, sollte so wenige Takte brauchen, das glaubst Du gar nicht.</p>
<pre><code class="language-cpp">#include &lt;iostream&gt;
#include &lt;ctime&gt;
using namespace std;

double kurzmach1(double d){
	//siehe http://de.wikipedia.org/wiki/IEEE_754
	unsigned long long l=*reinterpret_cast&lt;unsigned long long*&gt;(&amp;d);
	//einfach hinten ein paar Bits löschen.
	l&amp;=0xffffffff00000000ull;
	//sodele, 64 bits sind weg und trotzdem noch 5 genaue dezimalstellen.
	return *reinterpret_cast&lt;double*&gt;(&amp;l);
}

double kurzmach2(double d){
	//vorhin 32 bit weggehauen? das erinnert mich doch an was. 
	return double(float(d));
}

int main(int argc, char* argv[])
{
	{
		cout&lt;&lt;&quot;siebentel-tabelle\n&quot;;
		for(int i=0;i&lt;=7;++i)
			cout&lt;&lt;i/7.0&lt;&lt;' '&lt;&lt;kurzmach(i/7.0)&lt;&lt;'\n';
		cout&lt;&lt;'\n';
	}
	double kurzezeit;
	{
		cout&lt;&lt;&quot;summe roh\n&quot;;
		clock_t start=clock();
		double summe=0;
		for(int i=0;i&lt;1000000000;++i){
			summe+=double(i);
		}
		kurzezeit=(clock()-start)/double(CLOCKS_PER_SEC);
		cout&lt;&lt;&quot;zeit: &quot;&lt;&lt;kurzezeit&lt;&lt;'\n';
		cout&lt;&lt;&quot;summe: &quot;&lt;&lt;summe&lt;&lt;'\n';
		cout&lt;&lt;'\n';
	}
	double langezeit;
	{
		cout&lt;&lt;&quot;summe mit kurzmach-overhead\n&quot;;
		clock_t start=clock();
		double summe=0;
		for(int i=0;i&lt;1000000000;++i){
			summe+=kurzmach(double(i));
		}
		langezeit=(clock()-start)/double(CLOCKS_PER_SEC);
		cout&lt;&lt;&quot;zeit: &quot;&lt;&lt;langezeit&lt;&lt;'\n';
		cout&lt;&lt;&quot;summe: &quot;&lt;&lt;summe&lt;&lt;'\n';
		cout&lt;&lt;'\n';
	}
	cout&lt;&lt;&quot;zeit pro kurzmach: &quot;&lt;&lt;(langezeit-kurzezeit)&lt;&lt;&quot; nanosekunden\n&quot;;
  return 0;
}
</code></pre>
]]></description><link>https://www.c-plusplus.net/forum/post/1795215</link><guid isPermaLink="true">https://www.c-plusplus.net/forum/post/1795215</guid><dc:creator><![CDATA[volkard]]></dc:creator><pubDate>Tue, 20 Oct 2009 09:58:02 GMT</pubDate></item><item><title><![CDATA[Reply to double - caching on Tue, 20 Oct 2009 10:14:22 GMT]]></title><description><![CDATA[<p>Danke für den code.</p>
]]></description><link>https://www.c-plusplus.net/forum/post/1795227</link><guid isPermaLink="true">https://www.c-plusplus.net/forum/post/1795227</guid><dc:creator><![CDATA[Seikilos]]></dc:creator><pubDate>Tue, 20 Oct 2009 10:14:22 GMT</pubDate></item><item><title><![CDATA[Reply to double - caching on Tue, 20 Oct 2009 10:31:12 GMT]]></title><description><![CDATA[<p>Eine vergessliche und ungenaue hashtable sollte so schnell sein, das glaubst du gar nicht.</p>
<pre><code class="language-cpp">#include &lt;iostream&gt;
#include &lt;ctime&gt;
#include &lt;cmath&gt;
#include &lt;iomanip&gt;
#include &lt;vector&gt;
using namespace std;

double kurzmach1(double d){
	//siehe http://de.wikipedia.org/wiki/IEEE_754
	unsigned long long l=*reinterpret_cast&lt;unsigned long long*&gt;(&amp;d);
	//einfach hinten ein paar Bits löschen.
	l&amp;=0xffffffff00000000ull;
	//sodele, 64 bits sind weg und trotzdem noch 5 genaue dezimalstellen.
	return *reinterpret_cast&lt;double*&gt;(&amp;l);
}

double kurzmach2(double d){
	//vorhin 32 bit weggehauen? das erinnert mich doch an was.
	return double(float(d));
}

template&lt;typename T,T func&gt;
struct doublecache{
	static size_t const size=65536;
	struct entry{
		double x;
		double y;
	};
	vector&lt;entry&gt; data;
	doublecache():
		data(size){
	}
	double get(double x){
		double kurz=kurzmach1(x);
		size_t pos=*reinterpret_cast&lt;unsigned long long*&gt;(&amp;kurz)*568337%size;
		if(data[pos].x!=kurz){
			data[pos].x=kurz;
			data[pos].y=func(x);
		}
		return data[pos].y;
	}
};

double f(double x){
	double y=sqrt(1-x*x);
	return y;
}

int main(int argc, char* argv[])
{
	clock_t start=clock();
	double summe=0;
	doublecache&lt;typeof(&amp;f),&amp;f&gt; cache;
	for(int i=0;i&lt;100000000;++i){
		double x=i/100000000.0;
//		double y=f(x);
		double y=cache.get(x);
		summe+=y;
	}
	cout&lt;&lt;&quot;zeit: &quot;&lt;&lt;(clock()-start)/double(CLOCKS_PER_SEC)&lt;&lt;'\n';
	cout&lt;&lt;&quot;PI=&quot;&lt;&lt;setprecision(10)&lt;&lt;summe/100000000*4&lt;&lt;'\n';
  return 0;
}
</code></pre>
<p>Ohne cache:<br />
zeit: 3.484<br />
PI=3.141592674</p>
<p>Mit cache:<br />
zeit: 2.921<br />
PI=3.141593494</p>
<p>Ok, die Funktion f ist auch bewußt cachefreundlich gewählt. Aber sie ist auch ein echter Kurzrechner im Gegensatz Zu Deiner.</p>
]]></description><link>https://www.c-plusplus.net/forum/post/1795240</link><guid isPermaLink="true">https://www.c-plusplus.net/forum/post/1795240</guid><dc:creator><![CDATA[volkard]]></dc:creator><pubDate>Tue, 20 Oct 2009 10:31:12 GMT</pubDate></item></channel></rss>