mboost-dp1
unknown
Windows er noget lort kort sagt.. men ok, efter Longhorn laver MS en helt ny kode at besere deres OS på.. har jeg da læst et sted ialdfald :D
ja, men der ligger selvfølgelig også et stort arbejde bag. men man kan da godt forestille sig at m$ står bag en stor del af besværet.
For mig lyder den her nyhed mest som en konstatering af, at driverne er uhensigtsmæssigt designet. Multitrådet kode hører slet ikke hjemme i drivere. Drivernes opgave er at sørge for, at applikationer kan kommunikere med hardwaren. Den slags bør være en simpel opgave, som ikke bruger nogle væsentlige mængder CPU tid. Derfor burde der slet ikke være nogen gevinst at hente på drivernes performance ved at udnytte multicore systemer.
Drivere skal dog stadigvæk tage højde for tråde idet flere applikationer eller flere tråde i samme applikation kan benytte driveren samtidigt. Den slags skal en driver være parat til at håndtere på fornuftig vis.
I øvrigt er pointen med 3D hardware at tage de tunge opgaver fra CPUen. Så hvorfor skulle multicore overhovedet gøre en forskel for performance? Kan deres hardware ikke selv klare opgaven tilfredsstillende?
Hvis man mener nogle af beregninsopgaverne med fordel kan foretages på CPUen, så hører de til i applikationen eller et library, som applikationen udnytter. Den slags kan naturligvis godt laves multitrådet, men det har ikke noget med en multitrådet driver at gøre.
Hvis nVidia synes Windows udgøre et væsentligt problem, synes jeg de skulle starte med at lave en proof-of-concept driver til et andet OS. Jeg vil ikke udtale mig om, hvilket OS, der er bedst egnet til opgaven, for jeg kender ikke så mange. Men jeg er ret sikker på, at der er flere, hvor en multitrådet driver ikke ville være noget problem.
Drivere skal dog stadigvæk tage højde for tråde idet flere applikationer eller flere tråde i samme applikation kan benytte driveren samtidigt. Den slags skal en driver være parat til at håndtere på fornuftig vis.
I øvrigt er pointen med 3D hardware at tage de tunge opgaver fra CPUen. Så hvorfor skulle multicore overhovedet gøre en forskel for performance? Kan deres hardware ikke selv klare opgaven tilfredsstillende?
Hvis man mener nogle af beregninsopgaverne med fordel kan foretages på CPUen, så hører de til i applikationen eller et library, som applikationen udnytter. Den slags kan naturligvis godt laves multitrådet, men det har ikke noget med en multitrådet driver at gøre.
Hvis nVidia synes Windows udgøre et væsentligt problem, synes jeg de skulle starte med at lave en proof-of-concept driver til et andet OS. Jeg vil ikke udtale mig om, hvilket OS, der er bedst egnet til opgaven, for jeg kender ikke så mange. Men jeg er ret sikker på, at der er flere, hvor en multitrådet driver ikke ville være noget problem.
#6 jeg studsede også lidt over det da jeg så denne nyhed..
Der er selvfølgelig diverse funktioner som ai kontrollering osv (hvilket jeg ej heller kan se skal være i gfx kortet/drivere) men går ud fra at disse bliver regnet på gpu'en...
Der er selvfølgelig diverse funktioner som ai kontrollering osv (hvilket jeg ej heller kan se skal være i gfx kortet/drivere) men går ud fra at disse bliver regnet på gpu'en...
#6 Man må vel gå ud fra at gevinsten ved denne teknologi opvejer den brugte cpu tid på tildeling af arbejdsbyrder. Ellers ville de vel næppe have påstået den store gevinst. Spørgsmålet er så om, hvor vidt nvidia har multikerne GPU'er på vej :)
Man kunne dog forestille sig, at de her tal er vurderet ud fra gætteri, da de, som påstået, har store problemer med at få udviklet dem.
Man kunne dog forestille sig, at de her tal er vurderet ud fra gætteri, da de, som påstået, har store problemer med at få udviklet dem.
#6 -- Mon ikke begrebet ``driver-performance'' udelukkende dækker over ``svartid og behandlingstid på systemkald''? FWIW, gætter jeg:
I tråd med dette quote:
Denne (sandsynligvis elendige) hypotese rejser imidlertid to spørgsmål, jeg kunne tænke mig at finde svar på:
Hvor mange timeslices opererer moderne operativsystemer med pr. tid -- hvor store er de, og hvordan arbejder Windows' scheduler?
Er det ikke lidt amatøragtigt, at driver-kald foretages ikke-asynkront -- selv i en verden, hvor flerkernede systemer ikke er kurante?
I tråd med dette quote:
He explained that drivers in Windows normally run synchronously with the applications making API calls, so that they must return an answer before the API call is complete.Ens applikations render-tråd sleeper igennem hele system-kaldet, som sandsynligvis (iflg. nyheden) /skal/ afvikles på cpu0 (uanset, om man skal vente til der bliver et timeslice frit, på denne?). Mon ikke nvidia gerne ville have, at man kunne tråde disse, så de (som userspace-applikationer, tager jeg af nyheden) ville kunne afvikle parallelt? Hvordan ser det ud med Linux på dette punkt?
Denne (sandsynligvis elendige) hypotese rejser imidlertid to spørgsmål, jeg kunne tænke mig at finde svar på:
Hvor mange timeslices opererer moderne operativsystemer med pr. tid -- hvor store er de, og hvordan arbejder Windows' scheduler?
Er det ikke lidt amatøragtigt, at driver-kald foretages ikke-asynkront -- selv i en verden, hvor flerkernede systemer ikke er kurante?
[url=#9]#9[/url] SKREWZ
Jeg ved, der er mikrokode designs, hvor man bruger en message passing interface i stedet for at lade applikationernes egne tråde afvikle kode i kernel mode. Så har kernen et antal tråde, der typisk er for lille, til at tage sig af opgaverne. Hvis man ovenpå dette design laver en konventionel API med synkrone kald opnår man det værste fra begge designs.
[url=#11]#11[/url] SKREWZ
Mon ikke begrebet ``driver-performance'' udelukkende dækker over...Jeg er helt klar over, at performance af en driver ikke bare drejer sig om CPU forbrug. Faktisk burde CPU forbruget være det mindst væsentlige aspekt af performance
Ens applikations render-tråd sleeper igennem hele system-kaldetEfter jeg skrev mit sidste indlæg blev jeg opmærksom på den formulering, og jeg undrede mig. Med et OS design som jeg kender det giver det slet ikke mening at sige, at tråden sover. Tråden vil derimod være i gang med at afvikle driver koden og kan af den grund ikke foretage sig andet samtidigt.
Hvor mange timeslices opererer moderne operativsystemer med pr. tid100-1000 timeslices per sekund er vist det mest normale.
Er det ikke lidt amatøragtigt, at driver-kald foretages ikke-asynkrontDe APIer jeg har kendskab til er hovedsaligt synkrone, kun disk I/O findes der ofte asynkrone muligheder for. Og hvis man implementerer en API bestående af synkrone kald, så kan man jo ikke lave en asynkron implementation. Desuden er asynkrone kald dobbelt så kompliceret for applikationsudvikleren.
Jeg ved, der er mikrokode designs, hvor man bruger en message passing interface i stedet for at lade applikationernes egne tråde afvikle kode i kernel mode. Så har kernen et antal tråde, der typisk er for lille, til at tage sig af opgaverne. Hvis man ovenpå dette design laver en konventionel API med synkrone kald opnår man det værste fra begge designs.
[url=#11]#11[/url] SKREWZ
Er dual-core == SMP?Ja, det er næsten det samme. I princippet er dual core bare to CPUer sat i samme indpakning. De kan dog have mulighed for hurtigere kommunikation end to CPUer sat i hver sin sokkel. Evt. kan de også dele cache, implementeret rigtigt kan delt cache give endnu bedre performance. Med delt cache skal man dog passe meget på for at undgå timing attacks og unfair deling af pladsen.
#15 --
Artiklen nævner, at Windows' måde at lave driverkald foregår synkront med den kaldende tråd. Derfor konkluderede jeg umiddelbart, at den kaldende tråd måtte sleepe, imens.
Imens kaldet står på burde BF1942-tråden kunne arbejde videre. Det faktum rører egentlig ved min operativsystemopfattelse af Windows, og jeg kan forstå, at du må have fat i den lange ende. Kaldene er altså mere (i programmør-terminologi) ``funktionskald'' end ``signaler''.
Som for at perspektivere på denne nyopnåede erkendelse, vil jeg kommentere, at: Det var da en voldsomt dum løsning. Driveren bør netop være en sleepende proces, da den vel ellers skal bede operativsystemet om sine ressourcer og hardware-tilladelser, ved hvert kald? Ligeledes ville dette forårsage en voldsom ydelsesfremgang i SMP-systemer, hvor driveren kan sleepe, bunden til én processor, mens den anden processor afvikler den kaldende tråd.
Men -- måske jeg skulle sætte mig ind i stoffet, i stedet for gisninger som disse.
Dual-core anvender altså to processorer på én enhed. Tråde kan afvikles simultant, men cachen er delt (sjovt, nu hvor SRAM er så kostbart). Men, jeg har fået svar på mit spørgsmål. Tak. :)
Efter jeg skrev mit sidste indlæg blev jeg opmærksom på den formulering, og jeg undrede mig. Med et OS design som jeg kender det giver det slet ikke mening at sige, at tråden sover. Tråden vil derimod være i gang med at afvikle driver koden og kan af den grund ikke foretage sig andet samtidigt.AFAIK betyder det, at driverens afvikling er synkron med tråden, som foretager systemkaldene, at: Tråden som foretager systemkaldene (en fork af BF1942.exe, eksempelvis) laver et kald til en allerede-kørende driver, som så foretager hardware-interaktionen.
Artiklen nævner, at Windows' måde at lave driverkald foregår synkront med den kaldende tråd. Derfor konkluderede jeg umiddelbart, at den kaldende tråd måtte sleepe, imens.
Imens kaldet står på burde BF1942-tråden kunne arbejde videre. Det faktum rører egentlig ved min operativsystemopfattelse af Windows, og jeg kan forstå, at du må have fat i den lange ende. Kaldene er altså mere (i programmør-terminologi) ``funktionskald'' end ``signaler''.
Som for at perspektivere på denne nyopnåede erkendelse, vil jeg kommentere, at: Det var da en voldsomt dum løsning. Driveren bør netop være en sleepende proces, da den vel ellers skal bede operativsystemet om sine ressourcer og hardware-tilladelser, ved hvert kald? Ligeledes ville dette forårsage en voldsom ydelsesfremgang i SMP-systemer, hvor driveren kan sleepe, bunden til én processor, mens den anden processor afvikler den kaldende tråd.
Men -- måske jeg skulle sætte mig ind i stoffet, i stedet for gisninger som disse.
Dual-core anvender altså to processorer på én enhed. Tråde kan afvikles simultant, men cachen er delt (sjovt, nu hvor SRAM er så kostbart). Men, jeg har fået svar på mit spørgsmål. Tak. :)
[url=#17]#17[/url] SKREWZ
Hvis man har brug for at lave rettighedscheck, allocere resourcer (som f.eks. hukommelse I/O adresser osv.) sker det typisk en gang, hvorefter driveren kan huske det til senere fordi der i kernen ligger passende datastrukturer.
At køre dele af driverkoden som en seperat tråd er en ulempe for performance, fordi man så både har skiftet mellem privilegieniveauer og skiftet mellem tråde. Skiftet mellem privilegieniveauer er nødvendigt fordi datastrukturer involveret i kommunikationen og trådschedulering skal beskyttes.
Gøres der brug af delt hukommelse kan en del af skiftene undgås. Der vil stadigt skulle skiftes hver gang der scheduleres hvad enten det skyldes at tråden har opbrugt sin kvote eller at den har brug for at sove og derfor frivilligt giver CPUen fra sig.
Men vil man lave optimeringer baseret på delt hukommelse, så er det ikke kommunikation mellem to CPUer man skal satse på, men derimod kommunikation direkte mellem applikationen og hardwaren. Det kan noget grafikhardware allerede i nogen udstrækning gøre. Jeg kender ikke samtlige detaljer, men pointen er at driveren er involveret i starten for at placere hardwarens hukommelse i applikationens adresserum. Derefter er driveren kun involveret i den udstrækning der er behov for synkronisering (altså hver gang applikationen producerer data hurtigere end grafikkortet kan behandle det).
Har applikationen direkte adgang til hardware hukommelse skal der typisk anvendes noget hardwarespecifikt librarykode. Skal denne kode kaldes for driverkode? Den er hardwarespecifik, men set fra operativsystemets synspunkt er det bare librarykode, der kører med applikationens privilegier. Hvis det er denne kode, som nVidia vil lave multitrådet, så giver overvejelserne om begrænsninger i OS ingen mening fordi OS slet ikke er involveret i de performancekritiske dele af kommunikationen.
Med kernekode er det helt anderledes. Du kan ikke finde noget programflow, for det er der ikke. Kernen kaldes forskellige steder i applikationen, og i sidste ende er det applikationens flow, der er afgørende.
Så er der selvfølgeligt lige den detalje, at en kerne har en scheduler. Når man kigger på schedulerkode gælder den sædvanlige opfattelse af programflow ikke. Når scheduleren kaldes returnerer man netop ikke dertil hvor man kom fra, hvilket return ellers altid gør.
Jeg har engang selv prøvet at skrive en scheduler i Turbo Pascal (og ved en senere lejlighed også en i C). Jeg gjorde det mest for sjovt, men det var bestemt lærerigt. Man lærer mest af de fejl man selv begår. Det var ret interessant at man faktisk kunne singlesteppe gennem den jeg skrev i Turbo Pascal, og dermed se præcist hvordan funktionerne returnerede til et andet sted end der hvor de blev kaldt fra.
[url=#18]#18[/url] Redeeman
Kaldene er altså mere (i programmør-terminologi) ``funktionskald'' end ``signaler''.Ja, på de systemer jeg kender er det i hvert fald funktionskald, dog med den lille finesse, at caller og callee har forskellige privilegier.
Driveren bør netop være en sleepende proces, da den vel ellers skal bede operativsystemet om sine ressourcer og hardware-tilladelser, ved hvert kald?Nej, slet ikke. Drivere kører normalt som kerne kode hvilket betyder, at hardwaren ikke lægger nogen begrænsninger på, hvad driveren må og ikke må. Driveren er selv ansvarlig for at vide, hvad den må. Det er også derfor fejlbehæftede drivere kan have så alvorlig inflydelse på systemets stabilitet.
Hvis man har brug for at lave rettighedscheck, allocere resourcer (som f.eks. hukommelse I/O adresser osv.) sker det typisk en gang, hvorefter driveren kan huske det til senere fordi der i kernen ligger passende datastrukturer.
At køre dele af driverkoden som en seperat tråd er en ulempe for performance, fordi man så både har skiftet mellem privilegieniveauer og skiftet mellem tråde. Skiftet mellem privilegieniveauer er nødvendigt fordi datastrukturer involveret i kommunikationen og trådschedulering skal beskyttes.
Gøres der brug af delt hukommelse kan en del af skiftene undgås. Der vil stadigt skulle skiftes hver gang der scheduleres hvad enten det skyldes at tråden har opbrugt sin kvote eller at den har brug for at sove og derfor frivilligt giver CPUen fra sig.
Men vil man lave optimeringer baseret på delt hukommelse, så er det ikke kommunikation mellem to CPUer man skal satse på, men derimod kommunikation direkte mellem applikationen og hardwaren. Det kan noget grafikhardware allerede i nogen udstrækning gøre. Jeg kender ikke samtlige detaljer, men pointen er at driveren er involveret i starten for at placere hardwarens hukommelse i applikationens adresserum. Derefter er driveren kun involveret i den udstrækning der er behov for synkronisering (altså hver gang applikationen producerer data hurtigere end grafikkortet kan behandle det).
Har applikationen direkte adgang til hardware hukommelse skal der typisk anvendes noget hardwarespecifikt librarykode. Skal denne kode kaldes for driverkode? Den er hardwarespecifik, men set fra operativsystemets synspunkt er det bare librarykode, der kører med applikationens privilegier. Hvis det er denne kode, som nVidia vil lave multitrådet, så giver overvejelserne om begrænsninger i OS ingen mening fordi OS slet ikke er involveret i de performancekritiske dele af kommunikationen.
måske jeg skulle sætte mig ind i stoffet, i stedet for gisninger som disse.Det kan anbefales at læse lidt kernekode. Man vil opdage, at sådan noget har en helt anden struktur end applikationskode. Med en applikation vil man for det meste kunne finde et programflow, nogle er meget sekventielle andre har en eller anden form for eventloop men man kan næsten altid starte ved main og så finde ud af, hvordan det hænger sammen.
Med kernekode er det helt anderledes. Du kan ikke finde noget programflow, for det er der ikke. Kernen kaldes forskellige steder i applikationen, og i sidste ende er det applikationens flow, der er afgørende.
Så er der selvfølgeligt lige den detalje, at en kerne har en scheduler. Når man kigger på schedulerkode gælder den sædvanlige opfattelse af programflow ikke. Når scheduleren kaldes returnerer man netop ikke dertil hvor man kom fra, hvilket return ellers altid gør.
Jeg har engang selv prøvet at skrive en scheduler i Turbo Pascal (og ved en senere lejlighed også en i C). Jeg gjorde det mest for sjovt, men det var bestemt lærerigt. Man lærer mest af de fejl man selv begår. Det var ret interessant at man faktisk kunne singlesteppe gennem den jeg skrev i Turbo Pascal, og dermed se præcist hvordan funktionerne returnerede til et andet sted end der hvor de blev kaldt fra.
men cachen er delt (sjovt, nu hvor SRAM er så kostbart).Som jeg sagde før, så kan de eventuelt deles om cachen. Men de første dual core CPUer har vist seperate caches fordi der dermed skulle mindre designarbejde til før de kunne sættes i produktion. Jeg læste vist på et tidspunkt at nogle af de kraftigste dual core CPUer ville have 12MB cache til hver core. Det ville være mere effektivt med 24MB delt cache, men det ville også være mere compliceret. Selv hvis cachen ikke er delt er cache hukommelse mere kompliceret end SRAM. Med SRAM angiver adressen hvilken hukommelsescelle, der skal tilgås. Cache RAM er til gengæld associativ. Desuden har cachen nødvendigvis en eller anden replacement strattegi jeg kan forestille mig, at LRU er urealtisk at implementere på et så lavt niveau, så jeg gætter på, at det fleste bruger FIFO.
[url=#18]#18[/url] Redeeman
athlon xp er IKKE SMPJeg vil gætte på han mente, at Athlon XP har support for SMP. Du kan ikke bruge en vilkårlig CPU i et SMP system, der er brug for protokoller til at styre busadgangen og cache coherency.
[url=#20]#20[/url] SKREWZ
Med SDRAM sidder denne SRAM og styringen af det på hukommelsesmodulet sammen med DRAMen. Jeg kender ikke den eksakte størrelse af SRAMen, men jeg mener et par KB per chip er en passende størrelse.
Det jeg prøvede at forklare omkring cache var, at det er endnu mere compliceret end SRAM. Selve de enkelte lagerceller er sikkert SRAM celler (for i cache er der ikke tid til overheadet ved en DRAM), men logikken omkring dem for at styre associativ tilgang er mere compliceret end simpel SRAM.
Kommentaren om SRAM var et spørgsmål om, at CPU-cachen er bygget op af SRAM, og jeg havde hørt at den slags hukommelse var mere kostbart end eksempelvis DRAM.Det er korrekt at SRAM kræver en del transistorer per bit hukommelse hvorimod DRAM kun kræver en transistor og en kondensator per bit. Dermed bliver SRAM naturligt nok dyrer per MB. Men SRAM er hurtigere fordi det kan tilgås direkte hvorimod DRAM kræver noget mere compliceret logik for at tilgå indholdet. Faktisk fungerer DRAM på den måde at en del af indholdet kopieres over i en lille SRAM hvor det så kan læses/ændres og kopieres derefter tilbage igen. Faktisk er det også nødvendigt at kopiere de data man ikke tilgår frem og tilbage en gang imellem fordi kondensatoren ellers bliver afladet og data i hukommelsen dermed beskadiges.
Med SDRAM sidder denne SRAM og styringen af det på hukommelsesmodulet sammen med DRAMen. Jeg kender ikke den eksakte størrelse af SRAMen, men jeg mener et par KB per chip er en passende størrelse.
Det jeg prøvede at forklare omkring cache var, at det er endnu mere compliceret end SRAM. Selve de enkelte lagerceller er sikkert SRAM celler (for i cache er der ikke tid til overheadet ved en DRAM), men logikken omkring dem for at styre associativ tilgang er mere compliceret end simpel SRAM.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund