spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »"Toa"«

warum wandelt der compiler die speicheradresse nicht gleich in eine Physikalische?

jetzt überleg dir mal wie der compiler das tun sollte...

Toa:
Die Adresse die du im Prozess ansprechen willst wird relativ angegeben. Im Basisregister wird gespeichert wo der Adressbereich anfängt. Also beispielsweise bei 0x00008000. So im Grenzregister wird die länge des speicherbereichs gespeichert (in Bytes). Jeder Prozess hat seine eigene 0 Adresse. Bedeutet: Wenn du gerne an 0x0 schreiben willst, wird noch das Basisregister addiert und du schreibst in wirklichkeit an 0x00008000. Ich glaube soweit hast du das verstanden. So um nun zu wissen, ob der Speicherbereich den du angegeben hast überschritten wurde brauchst du doch nur 2 dinge. Den Offset vom punkt im Basisregister (also deine virtuelle speicheradresse) und die maximale länge des sepicherbereichs. Ist der offset größer als die länge hast du pech, hier darfst du net hin. Ist er kleiner ist alles in ordnung. Ich hoffe ich habs verständlich erklärt.

Und ich hab mal wieder net geschaut ob das problem schon gelöst wurde ()

Socke

// Edit: Toa ich schau gerne über die ppt drüber, schreib mir mal ne pn wegen icq und so...

das is aber eigl einfach .

jeder thread belegt im heap sopeicher wie er möchte und gibt ihn zu unterschiedlichen zeitpunkten wieder frei. d. h. wo anderer den noch belegen und andere ihren speicher schon freigeben, entstehen lücken im speicher. so genannte fragmente. daher der Begriff fragmentierung.

Zitat von »"Toa"«

kann mir einer das mit der Fragmentierung erklären?

jap.

also fragmentierung hat nichts mit ram zu tun, die fragmentierung ist auf der harddisk.

zum vorgang:
wenn du eine datei speicherst, sucht der computer den ersten freien platz auf der harddisk, wo die datei am stück platz hat. findet er diesen platz nicht, so teilt er die datei auf, damit sie reinpasst. nun kann es auch sein, dass du eine datei bearbeitest und dadurch ihre grösse änderst, und hinten an der datei gleich eine andere folgt. dann schreibt er den 2. teil woanders hin. das bedeutet, nach vielem schreiben/modifizieren/löschen ist deine harddisk ganz "fragmentiert". wenn du nun defragmentierst (macht linux automatisch ), dann werden die dateien wieder so verschoben, dass sie zusammenhängen, was zur folge hat, dass der lesekopf der festplatte nicht hin und her wechseln muss und dadurch eine höhere geschwindigkeit hat.

btw sollte ich meine 500gb mal defragmentieren, da kann ich n tag streichen an dem ich nix tun kann :/
ps: es ist 2:25 uhr morgens, ich garantiere für nichts mehr bei diesem text

Zitat von »"DasBlub"«

also fragmentierung hat nichts mit ram zu tun, die fragmentierung ist auf der harddisk.

Selbstverständlich hat Fragmentierung auch etwas mit RAM zu tun. Windows 2000/XP unterteilt z.B. das RAM in 4KB große Blöcke die beliebig verkettet werden können (der Hauptspeicher fragmentiert in Stücken zu 4KB). Für den Anwender ist das nicht wirklich sichtbar (zum einen gaukelt die Hardware dem Anwender ja unfragmentierten Speicher vor, zum anderen wirds, wenn überhaupt, dann nur unwesentlich langsamer [zumindest nach meiner Erfahrung]). Eklig wirds nur wenn ein Treiber für irgendwelche Aktionen tatsächlich einen größeren unfragmentierten Speicherbereich braucht. Je länger Windows aktiv ist desto geringer die Chance, einen großen zusammenhängenden Speicherbereich zu kriegen...

Grüße,
Mordrak

Zitat von »"Mordrak"«

Zitat von »"DasBlub"«

also fragmentierung hat nichts mit ram zu tun, die fragmentierung ist auf der harddisk.

Selbstverständlich hat Fragmentierung auch etwas mit RAM zu tun. Windows 2000/XP unterteilt z.B. das RAM in 4KB große Blöcke die beliebig verkettet werden können (der Hauptspeicher fragmentiert in Stücken zu 4KB). Für den Anwender ist das nicht wirklich sichtbar (zum einen gaukelt die Hardware dem Anwender ja unfragmentierten Speicher vor, zum anderen wirds, wenn überhaupt, dann nur unwesentlich langsamer [zumindest nach meiner Erfahrung]). Eklig wirds nur wenn ein Treiber für irgendwelche Aktionen tatsächlich einen größeren unfragmentierten Speicherbereich braucht. Je länger Windows aktiv ist desto geringer die Chance, einen großen zusammenhängenden Speicherbereich zu kriegen...

Grüße,
Mordrak

hast ja recht, aber siehe oben, es war halb 3, so um 3 ist es mir dann in den sinn gekommen, aber dann war ich zu faul um es zu editieren (pc war am runterfahren)

tut mir leid toa, aber so genau kenn ich das auch wieder nicht. findest du nichts mit google? da wird doch sicher schon irgend so ein linux programmierer das mal dokumentiert haben