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

Groups > de.comp.lang.forth > #308

Re: gforth - assert in malloc.c, Zeile 2372 nicht als exception?

Show all headers | View raw

Anton Ertl wrote:
> Nein, die 5 Zyklen genemigt sich der Prozessor, um diesen Spezialfall
> (Cache-Line-uebergreifendes load) zu behandeln, selbst wenn beide
> cache lines schon im data cache liegen.

Da was per Programm tun zu wollen ist aber IMHO premature optimization: Das 
kann bei der nächsten Prozessorarchitektur gleich wieder ganz anders 
aussehen.

> Die Abfrage muss ich fuer den Page-Fall ohnehin machen (und in dem
> Fall erspart sie auch 27 Zyklen auf dem Ivy Bridge, selbst wenn beide
> Seiten zugreifbar sind), die Frage ist nur, ob ich sie auf
> Page-Granularitaet, oder auf Cache-line-Granularitaet einstelle.  Die
> zusaetzlichen Berechnungen selbst dauern vermutlich kuerzer als 5
> Zyklen (und es sind genausoviele shifts), aber wenn der Fall im
> Normalfall ueber eine misprediction erreicht wird, ist es besser, die
> Granularitaet moeglichst grob zu machen, damit der Fall moeglichst
> selten erreicht wird.

Selbst wenn die Abfrage nur einen Takt dauert, wird sie im Durchschnitt 511 
mal unnötig und ein mal treffend ausgeführt, was mehr kostet als die 27 
Extra-Takte. Und da muss man dann noch die 14 Takte Branch-Miss abziehen, 
und die paar Takte für das Herumshiften.

Problematisch wird höchstens, wenn der Input-Buffer gerade auf einer Page-
Grenze liegt, und der Fall dann ständig vorkommt. Das ist aber halt dann 
blöder Zufall, oder wir sorgen dafür, dass der Input-Buffer page-aligned ist 
(was dann aber wieder unnötige Verschwendung von Speicher ist).

>>Wobei das sogar in der valgrind-Doku explizit drin steht, dass Speicher,
>>der sowieso für den ganzen Programmablauf "lebend" ist, eben nicht
>>explizit freigegeben werden sollte, weil das Beenden des Prozesses viel
>>schneller ist.
> 
> Nur war es den Programmierern von Mozilla offenbar trotzdem lieber,
> vom Tool nicht angemeckert zu werden, als schnell zu sein.  Genauso
> wie bei dem DFALIGNED.  Und bei Mozilla bin ich mir nicht sicher, ob
> da nicht einfach echte Lecks versteckt wurden, indem einfach ein
> Wrapper um malloc() gemacht wurde, der jedes Speicherstueck trackt und
> am Ende frei gibt.

Wir können natürlich auch einfach sagen "Die valgrind-Warnung für hashkey2 
ist ok, kann man ignorieren".

Ich hab' jetzt erst mal alle Zugriffswarnungen weg, dabei war auch eine 
relevante dabei (die neuen vtables führten zu einem use-after-free-Zugriff 
auf den für Locals allozierten Speicher - wobei, da müssen wir noch was 
fixen, die gehen nicht für beliebig lange Namen, das geht gar nicht! ;-).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

Back to de.comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

gforth - assert in malloc.c, Zeile 2372 nicht als exception? djc <ciesinger@gmx.net> - 2015-06-10 00:52 -0700
  Re: gforth - assert in malloc.c, Zeile 2372 nicht als exception? djc <ciesinger@gmx.net> - 2015-06-10 01:10 -0700
  Re: gforth - assert in malloc.c, Zeile 2372 nicht als exception? djc <ciesinger@gmx.net> - 2015-06-11 01:04 -0700
    Re: gforth - assert in malloc.c, Zeile 2372 nicht als exception? Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-11 23:15 +0200
      Re: gforth - assert in malloc.c, Zeile 2372 nicht als exception? djc <ciesinger@gmx.net> - 2015-06-12 02:38 -0700
        Re: gforth - assert in malloc.c, Zeile 2372 nicht als exception? djc <ciesinger@gmx.net> - 2015-06-13 16:25 -0700
          Re: gforth - assert in malloc.c, Zeile 2372 nicht als exception? Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-15 00:52 +0200
            Re: gforth - assert in malloc.c, Zeile 2372 nicht als exception? djc <ciesinger@gmx.net> - 2015-06-14 23:22 -0700
            Re: gforth - assert in malloc.c, Zeile 2372 nicht als exception? djc <ciesinger@gmx.net> - 2015-06-14 23:33 -0700
            Re: gforth - assert in malloc.c, Zeile 2372 nicht als exception? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-16 06:12 +0000
              Re: gforth - assert in malloc.c, Zeile 2372 nicht als exception? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-17 10:47 +0000
                Re: gforth - assert in malloc.c, Zeile 2372 nicht als exception? Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-17 23:49 +0200
                Re: gforth - assert in malloc.c, Zeile 2372 nicht als exception? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-18 08:42 +0000
                Re: gforth - assert in malloc.c, Zeile 2372 nicht als exception? Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-18 23:17 +0200
                Re: gforth - assert in malloc.c, Zeile 2372 nicht als exception? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-21 15:22 +0000
                Re: gforth - assert in malloc.c, Zeile 2372 nicht als exception? Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-22 04:17 +0200
                Re: gforth - assert in malloc.c, Zeile 2372 nicht als exception? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 13:40 +0000
                Re: gforth - assert in malloc.c, Zeile 2372 nicht als exception? Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-22 21:03 +0200

csiph-web