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

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

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

Show all headers | View raw

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>Anton Ertl wrote:
>>>
>>>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>>>Probiere ich mal aus; da muss man trotzdem noch einen endian-abhängigen
>>>>>Shift machen, big endian nach links, little endian nach rechts.
>>>> 
>>>> Ja.  Und in dem Fall mit erase2 entsprechend auch aendern.  Wobei man
>>>> da ueberlegen sollte, ob man die "pagesize" nicht auf 64 setzt, damit
>>>> auch schon der unnoetige Zugriff auf die naechste Cache line vermieden
>>>> wird (kostet 5 Zyklen auf Ivy Bridge und zusaetzlich wird der Cache
>>>> noch verschmutzt).
>>>
>>>Für die typische Anwendung, PARSE-NAME FIND, sehe ich da gar kein Problem:
>>>Dieser Speicher wird sowieso gebraucht.
>> 
>> Bleiben immer noch die 5 Zyklen.
>
>Die würden sonst beim nächsten Zugriff in PARSE-NAME fällig.

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.

>> Klar.  Nach der Shifterei steht in h in das gleiche, egal wo der
>> String anfaengt und aufhoert (fuer big-endian muesste man das noch
>> entsprechend anpassen); um das zu pruefen, habe ich dort auch die
>> printdbg()s hingemacht.
>
>Dauert das mit der Shifterei dann nicht länger als diese 5 Zyklen? Du musst 
>bei jedem Zugriff die Abfrage machen, selbst wenn das mit dem Shiften 
>schneller geht als der direkte page-überlappende Zugriff, kostet die Abfrage 
>doch jedes Mal.

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.

Andererseits, wenn ein Buffer ein paar Bytes vor einer Cache-line
boundary anfaengt, und der immer wieder fuer zu hashende Strings
verwendet wird, wird der Fall immer eintreten und der branch richtig
vorhergesagt werden, und dann wuerde Cache-line-Granularitaet
vermutlich schon schneller sein.  Der Fall duerfte aber selten sein.

Also wohl doch Page-Granularitaet.

>> Was Speicherlecks und solche Tools angeht, hat Mozilla (zumindest
>> frueher) heftig Speicher geleckt.  War an sich kein grosses Problem,
>> nur wenn man ihn dann beendet hat, hat er einige Minuten lang auf der
>> Festplatte herumgekratzt, um den ganzen geleckten Speicher wieder
>> reinzuladen, und ihn freizugeben; ein einfaches exit() haette den
>> Speicher viel schneller und billiger freigegeben, aber dann haette das
>> Tool gemeckert.
>
>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.

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

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