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

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

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:
>>>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.

>> Mein Code liest weder nach hinten noch nach vorne in die naechste page
>> (bzw. bei entsprechender "pagesize" die naechste cache line).  Wenn's
>> nach hinten in die naechste page gehen wuerde (der erase2-Fall), wird
>> das alignete Wort gelesen und mit shifts in beide Richtungen die
>> interessanten Bytes herausgeholt.
>
>Der Hash muss aber reproduzierbar immer der gleiche sein, egal wo der String 
>im Speicher anfängt und aufhört.

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.

>Wir könnten für safe-mem eine andere Allocation-Strategie verwenden, die 
>günstiger ist als malloc(), wir wissen ja, dass wir alles mit safe-mem 
>alloziete nie wieder freigeben werden.

Wissen wir im allgemeinen nicht: Die Doku von SAVE-MEM sagt "copy a
memory block into a newly allocated region in the heap", ein Benutzer
koennte das verwenden und spaeter mit FREE freigeben.

Man koennte allerdings den Aufruf von SAVE-MEM in S" durch etwas
ersetzen, das Speicher ohne malloc() alloziert.  Wobei die Frage ist,
ob es bestimmt niemanden gibt, der nicht das Resultat von S" FREEt.

Ein anderer workaround fuer die valgrind-Version von Gforth waere,
dass ALLOCATE die Groesse des Speicherbereichs passend aufrundet.

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.

- 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