"Mogens Hansen" <mogens_h@dk-online.dk> skrev i en meddelelse
news:bmliep$1can$1@news.cybercity.dk...
>
> "Per Pedersen" <perpedersen33@hotmail.com> wrote
>
> [8<8<8<]
> > Jeg er ikke helt sikker på, at du har forstået mit egentlige formål med
at
> > spørge, så det følger her:
>
> Det har du givetvis ret i.
>
> >
> > Jeg har programmeret både C, og Assembler, på AmigaOS siden 1990
>
> Det er væsentlig information for at kunne svare konstruktivt på dit
> spørgsmål.
>
> >, og jeg har
> > da i sinde at bruge de velkendte teknikker fra det selv samme system,
> > Runtime Linking, og dynamisk allokering, af både plads, og
> > hastighedsoptimeringsgrunde,
>
> Hvilke performance fordele forventer du at få på Win32 ved at bruge
dynamisk
> linkning ?
> Den _eneste_ performance forskel jeg har kunne konstatere (og jeg har
kigget
> _grundigt_ efter) er en lille besparelse på diskplads forbruget (svarende
> til harddisk for nogle få ører). Resten er enten løgn (deling af
> kodehukommelse mellem processer) eller misforståelser (mindre
> hukommelsesforbrug).
>
> Bemærk at somme tider har man et valg om man vil bruge dynamisk (DLL)
eller
> statisk linkning. Det gælder f.eks. C runtime bibliotekets funktioner som
> malloc/free.
> I andre tilfælde er der _ikke_ noget valg. Det gælder f.eks. Win32 API'et
> med funktioner som CreateWindow.
>
> > og at gøre det ved hjælp af operativsystemet,
>
> Hvorfor, hvis man kan gøre det uafhængigt af operativsystemet.
> Altså man kan f.eks. bruge C funktionerne malloc/free i stedet for Win32
> API'et funktioner GlobalAlloc/GlobalFree.
>
> > og i det her tilfælde Win32,- det giver et væsentligt mindre overhead -.
>
> Mindre overhead end hvad ?
> Har du foretaget målinger, der påviser det ?
>
> F.eks. er det væsentligt hurtigere at bruge malloc/free and
> GlobalAlloc/GlobalFree i Microsoft Visual C++.
> I forbindelse med Microsoft Visual C++ V5 eller V6 blev der lagt mange
> kræfter i at lave en fornuftig heap-manager. Den er lavet ved en
> suballokator, som allokerer en klump fra operativsystemet, og derefter
deler
> det ud til applikationen i småstykker.
> De tidligere versioner kaldte direkte ned i GlobalAlloc/GlobalFree.
> Der var tale om en væsentlig performance forbedring i mange almindelige
> scenarier.
> Det skyldes at operativsystemet kun kan allokere i blokke der er et
> multiplum af 4k store - en hardware pagesize. Hver gang der allokeres og
> frigives skal der sættes op hardwaren at nu må man skrive på dette adresse
> interval (GDT og LDT - Global Descriptor Table og Local Descriptor Table).
> Det er ikke et typisk brugsmønster for en applikation, at alle
allokeringer
> har en størrelse som er et multiplum af 4k.
>
> Generelt er det _meget_ kompliceret at forudsige performance.
> Kun målinger kan afgøre hvad der er rigtigt og forkert. Sådanne målinger
er
> ofte ikke trivielle at udføre.
>
> >
> > Jeg har arbejdet en hel del med fremstillingen af
billedbehandlingsfiltre
> og
> > konvertere, og er derfor vandt til at ligge og rode i hukommelsen på bit
> > nivau, en opgave som oftest er lettere at udføre i assembler, end det er
i
> > C.
>
> Smag og behag er naturligvis forskellig.
> Det er generelt _meget_ svært at skrive assembler kode, der kører
hurtigere
> end C kode oversat med en _god_ optimerende compiler som Microsoft Visual
> C++ .NET og Intel C++ V7.1.
> Det skyldes primært at faktorer som instruktions pipeline og cache
> komplicerer tingene meget. Det er faktorer som compileren har mulighed for
> at have viden om.
> De par gange hvor jeg har prøvet at skrive assembler der kører hurtigere
end
> tilsvarende C++ (eller C) kode med brug af alle feje kneb (kigge på
> compilerenes output, anvendelse af Intel VTune, aggressive forsøg på
> register allokering) har jeg tabt.
>
> > Jeg kan udemærket få standartfunktionerne til at fungere, så det er ikke
> > der skoen trykker, de er bare ikke særligt optimerede til de opgaver jeg
> > gerne vil have udført.
>
> Den nødvendige information om f.eks. Win32 funktioner til heap allokering
> kan simpelt findes i hjælpesystemet som er integreret i Microsoft Visual
> Studio .NET.
> Slå op under "GlobalAlloc".
> Klik på flue-benet for øverst til venstre på hjælpesiden, for at få
> information om hvilken header fil der skal includeres (windows.h) og
hvilket
> import library der skal linkes med (Kernel32.lib). Det er egentlig
> ligegyldigt for brugen, hvilket DLL funktionen _faktisk_ ligger i.
> Klik på "heap functions" for at få en beskrivelse af gruppen af
funktioner.
>
> Gør tilsvarende med "CreateFile" for at finde Win32 funktioner til
> filadgang.
>
> Har du fået svaret på dit oprindelige spørgsmål ?
>
> Venlig hilsen
>
> Mogens Hansen
>
>
>
Jeg har efterhånden fået styr på det nu, og som sådan, da har jeg også fået
svar på mine spørgsmål.
Det som gør det her svært, er at de 2 platforme er så forskellige, på den
ene, AmigaOS, da er der kun den ene måde at gøre tingene på, og på Win32, da
kan man begge dele.
Med venlig hilsen
Per Pedersen