mboost-dp1
unknown
#2
Men det er in-kernel support. Dvs. det er meget hurtigere end hvis det gik igennem et eksternt lib.
Men det er in-kernel support. Dvs. det er meget hurtigere end hvis det gik igennem et eksternt lib.
Nice - man kan håbe at dette vil åbne for endnu mere hardware support i GNU/Linux systemer.
Jeg har ingen idé om hvor mange C proggere der er i forhold til C++ proggere - men cool - flere til at skrive kerne code - hvis teknikken bliver accepteret :-).
Jeg har ingen idé om hvor mange C proggere der er i forhold til C++ proggere - men cool - flere til at skrive kerne code - hvis teknikken bliver accepteret :-).
#9
[hvis #6 ikke aner hvad C++ er...hjælper #3 nok ikke meget :)
Nej ikke umildbart.. ;)
[Nu er jeg IKKE ude på at starte en Lin vs win flamewar igen - men et øjeblik tænkte jeg lige (med henblik på #6) - "hva' fa'en laver han så med linux?" hehe :)]
Kan man kun bruge GNU/Linux hvis man er programmør?...
Det vidste jeg ikke... :P
Jeg er da gentoo bruger, så det at jeg ikke er udvikler, betyder langtfra at jeg er nogen n00b... ;)
[hvis #6 ikke aner hvad C++ er...hjælper #3 nok ikke meget :)
Nej ikke umildbart.. ;)
[Nu er jeg IKKE ude på at starte en Lin vs win flamewar igen - men et øjeblik tænkte jeg lige (med henblik på #6) - "hva' fa'en laver han så med linux?" hehe :)]
Kan man kun bruge GNU/Linux hvis man er programmør?...
Det vidste jeg ikke... :P
Jeg er da gentoo bruger, så det at jeg ikke er udvikler, betyder langtfra at jeg er nogen n00b... ;)
#3 Men det er in-kernel support. Dvs. det er meget hurtigere end hvis det gik igennem et eksternt lib.
Du tager fejl. Det er skift mellem kernel mode og user mode, der tager lang tid. Hvis en opgave kræver kerne kode, så kan en ren kerne implementation være hurtigere end en kombination af kerne og user kode. Man kunne også blot prøve at forbedre designet, så antallet af skift bliver reduceret.
Men at kaste en exception kan gøres i ren user mode kode, så der er næppe noget at vinde i performance i forhold til eksisterende C++ programmer.
Men faktisk har du også misforstået hvad det overhovedet drejer sig om, for der er tale om kode, der slet ikke skal bruges af user mode programmer.
Hidtil har kernen været skrevet i C (plus en smule assembler). Programmer ovenpå kernen kan så være skrevet i mange forskellige sprog som f.eks. Ada, Beta, C, C++, Fortan, mfl. eller sågar en kombination af flere. Det nye er, at de prøver at give mulighed for at køre C++ kode i kernen. Hvis man da kan kalde det for nyt, for det er vist blevet foreslået adskillige gange før, og afvist hver gang.
Jeg læste nogle af kommentarerne på slashdot, og der var også flere, som havde misforstået det. Men det fremgår nok heller ikke helt tydligt, hvad der egentlig foregår. Jeg var da også i tvivl indtil jeg læste afsnittet omkring symbolhåndtering i modul loaderen.
Det blev nævnt, at dette forsøg på at implementere C++ support i kernen ser væsentligt mere seriøst ud end de tidligere, om det betyder, at idéen har en chance den her gang, tør jeg ikke gætte på. Men har man god tid kan man jo undersøge, om det bliver diskuteret på kernel mailing listen.
At de kan forbedre performance på exceptions med en faktor seks er naturligvis ikke uinteressant. Går det udover afviklingshastigheden i normale tilfælde uden exceptions er det selvfølgelig mindre interessant. Måske kan deres exception håndtering bruges i user mode, jeg kan ikke lige komme i tanke om nogen grund til, at det ikke skulle virke.
Du tager fejl. Det er skift mellem kernel mode og user mode, der tager lang tid. Hvis en opgave kræver kerne kode, så kan en ren kerne implementation være hurtigere end en kombination af kerne og user kode. Man kunne også blot prøve at forbedre designet, så antallet af skift bliver reduceret.
Men at kaste en exception kan gøres i ren user mode kode, så der er næppe noget at vinde i performance i forhold til eksisterende C++ programmer.
Men faktisk har du også misforstået hvad det overhovedet drejer sig om, for der er tale om kode, der slet ikke skal bruges af user mode programmer.
Hidtil har kernen været skrevet i C (plus en smule assembler). Programmer ovenpå kernen kan så være skrevet i mange forskellige sprog som f.eks. Ada, Beta, C, C++, Fortan, mfl. eller sågar en kombination af flere. Det nye er, at de prøver at give mulighed for at køre C++ kode i kernen. Hvis man da kan kalde det for nyt, for det er vist blevet foreslået adskillige gange før, og afvist hver gang.
Jeg læste nogle af kommentarerne på slashdot, og der var også flere, som havde misforstået det. Men det fremgår nok heller ikke helt tydligt, hvad der egentlig foregår. Jeg var da også i tvivl indtil jeg læste afsnittet omkring symbolhåndtering i modul loaderen.
Det blev nævnt, at dette forsøg på at implementere C++ support i kernen ser væsentligt mere seriøst ud end de tidligere, om det betyder, at idéen har en chance den her gang, tør jeg ikke gætte på. Men har man god tid kan man jo undersøge, om det bliver diskuteret på kernel mailing listen.
At de kan forbedre performance på exceptions med en faktor seks er naturligvis ikke uinteressant. Går det udover afviklingshastigheden i normale tilfælde uden exceptions er det selvfølgelig mindre interessant. Måske kan deres exception håndtering bruges i user mode, jeg kan ikke lige komme i tanke om nogen grund til, at det ikke skulle virke.
Så længe Linus har den holdning til C++, han har, så kommer det patch aldrig ind i Linux kernen. Men hvis der er nogen, der har lyst til at forke, skal det da stå dem frit for...
Og jeg kan for den sags skyld kun erklære mig enig. Højniveausprog, der gør ting for en (f.eks. hukommelsesallokering) hører ingen steder hjemme i low-level programmering (og en kerne er noget af det mest low-level, man kan lave).
Og jeg kan for den sags skyld kun erklære mig enig. Højniveausprog, der gør ting for en (f.eks. hukommelsesallokering) hører ingen steder hjemme i low-level programmering (og en kerne er noget af det mest low-level, man kan lave).
Dette er ikke nødvendigvis godt. Det er muligvis ydelsesforbedrende, men hvis det sker på bekostning af modulariteten, er jeg ikke glad. Jeg aner ikke, om det faktisk gør.
Desuden bryder jeg mig ikke om tanken om andet end meget lowlevel-sprog i en kernel. Bliv væk, C++.
#14 - uden at ane hvad Torvalds holdning er, så gætter jeg på at jeg deler den.
Desuden bryder jeg mig ikke om tanken om andet end meget lowlevel-sprog i en kernel. Bliv væk, C++.
#14 - uden at ane hvad Torvalds holdning er, så gætter jeg på at jeg deler den.
#12 - Hvis jeg forstår dig ret, så er denne her "optimering" til C++ på kerneniveau, men det har ikke nogen reel betydning, da de fleste C++ typisk er almindelige brugerprogrammer der ikke kører helt nede på kerneniveau? Mig bekendt er de fleste C++ skrevede programmer til Linux diverse små grafiske brugerapplikationer, mens det meste low-level kernehalløj er ren C.
Er det nogenlunde rigtigt forstået? Bare et nysgerrigt spørgsmål, da man jo godt vil fatte bare lidt af det der sker inden for udviklingen af Linuxkernen, uden at være erfaren programmør :)
#14 - Linus er nu efterhånden kendt for at lytte til hvad andre siger. Han erkender tit at hans egen opfattelse ikke altid er den rigtige, og må bøje sig for flertallet af andre kerneudviklere. Men det kan jo være at lige det her er et meget ømt punkt ;)
Er det nogenlunde rigtigt forstået? Bare et nysgerrigt spørgsmål, da man jo godt vil fatte bare lidt af det der sker inden for udviklingen af Linuxkernen, uden at være erfaren programmør :)
#14 - Linus er nu efterhånden kendt for at lytte til hvad andre siger. Han erkender tit at hans egen opfattelse ikke altid er den rigtige, og må bøje sig for flertallet af andre kerneudviklere. Men det kan jo være at lige det her er et meget ømt punkt ;)
#16 Hvis jeg forstår dig ret, så er denne her "optimering" til C++ på kerneniveau
Det er ikke helt rigtigt forstået. Hidtil har der overhovedet ikke været support for C++ i kernen. Så det er ikke bare en optimering, de har implementeret supporten "fra grunden". Som jeg læser det har de taget en del af koden fra det eksisterende user mode C++ runtime environment. Men de har samtidig lavet nogle forbedringer af bla. exception performance. Det lyder som om porteringen til kernel mode og optimeringer er uafhængige. De kunne måske have lavet de samme optimeringer til C++ i user mode (hvilket, der sikkert ville blive taget glædeligt imod).
men det har ikke nogen reel betydning, da de fleste C++ typisk er almindelige brugerprogrammer der ikke kører helt nede på kerneniveau?
Da der pt. ikke er C++ i kernen er det ikke bare det meste, men faktisk alt C++ kode, der kører i user mode. Det er dog kun på Linux, så vidt jeg har forstået findes der systemer, hvor man kan skrive sine drivere i C++. Om det så er fordi disse systemer har C++ support i kernen eller kører driverne på et højere lag end kernen, ved jeg ikke.
Der er blevet fortalt om nogle af ulemperne ved C++ i kernen (og der er flere af dem), men lad mig da lige nævne noget, der måske er en fordel. Ved at understøtte C++ i kernen bliver det måske lettere at portere en driver fra andre operativsystemer til Linux (Hvis driveren er skrevet i C++).
Hvis sådan en driver bliver frigivet som opensource vil der sikkert hurtigt være nogen, der erstatter den C++ specifikke kode, så driveren kommer til at kunne køre uden C++ runtime support.
Hvis driveren kun bliver frigivet som objektkode vil der pludselig bliver afhængigheder af C++, som ikke vil være nemme at slippe af med. Og jeg frygter, at det vil gøre closedsourcedrivere værre end de allerede er i dag.
Det er ikke helt rigtigt forstået. Hidtil har der overhovedet ikke været support for C++ i kernen. Så det er ikke bare en optimering, de har implementeret supporten "fra grunden". Som jeg læser det har de taget en del af koden fra det eksisterende user mode C++ runtime environment. Men de har samtidig lavet nogle forbedringer af bla. exception performance. Det lyder som om porteringen til kernel mode og optimeringer er uafhængige. De kunne måske have lavet de samme optimeringer til C++ i user mode (hvilket, der sikkert ville blive taget glædeligt imod).
men det har ikke nogen reel betydning, da de fleste C++ typisk er almindelige brugerprogrammer der ikke kører helt nede på kerneniveau?
Da der pt. ikke er C++ i kernen er det ikke bare det meste, men faktisk alt C++ kode, der kører i user mode. Det er dog kun på Linux, så vidt jeg har forstået findes der systemer, hvor man kan skrive sine drivere i C++. Om det så er fordi disse systemer har C++ support i kernen eller kører driverne på et højere lag end kernen, ved jeg ikke.
Der er blevet fortalt om nogle af ulemperne ved C++ i kernen (og der er flere af dem), men lad mig da lige nævne noget, der måske er en fordel. Ved at understøtte C++ i kernen bliver det måske lettere at portere en driver fra andre operativsystemer til Linux (Hvis driveren er skrevet i C++).
Hvis sådan en driver bliver frigivet som opensource vil der sikkert hurtigt være nogen, der erstatter den C++ specifikke kode, så driveren kommer til at kunne køre uden C++ runtime support.
Hvis driveren kun bliver frigivet som objektkode vil der pludselig bliver afhængigheder af C++, som ikke vil være nemme at slippe af med. Og jeg frygter, at det vil gøre closedsourcedrivere værre end de allerede er i dag.
#16
'Hvis jeg forstår dig ret, så er denne her "optimering" til C++ på kerneniveau, men det har ikke nogen reel betydning, da de fleste C++ typisk er almindelige brugerprogrammer der ikke kører helt nede på kerneniveau? Mig bekendt er de fleste C++ skrevede programmer til Linux diverse små grafiske brugerapplikationer, mens det meste low-level kernehalløj er ren C.
Er det nogenlunde rigtigt forstået? Bare et nysgerrigt spørgsmål, da man jo godt vil fatte bare lidt af det der sker inden for udviklingen af Linuxkernen, uden at være erfaren programmør :)'
Du har fuldstændig ret. Men grunden til at folk ikke har brugt andet end C i kernen, er jo netop at det ikke har været muligt. Nu når det er muligt at skrive c++, kan det være at flere bruger det til at lave små sjove ting. For slutbrugeren har det ingen betydning overhovedet - andet end udviklingen på et tidspunkt går end smule hurtigere da det er lettere at programmere i c++.
Det minder mig lidt om min webbank, som ikke ville supporte Linux, fordi de kunne se på deres statistikker at der ikke var nogen der brugte det. Dette var jo ikke så overraskende, eftersom Linux ikke virkede med deres system...
Personligt vil jeg nok vente et par år (eller til det kommer med som standard i kernen), for at se hvordan stabiliteten er i forhold til kernen, før jeg begynder at lave noget kernemulletjavs i c++.
'Hvis jeg forstår dig ret, så er denne her "optimering" til C++ på kerneniveau, men det har ikke nogen reel betydning, da de fleste C++ typisk er almindelige brugerprogrammer der ikke kører helt nede på kerneniveau? Mig bekendt er de fleste C++ skrevede programmer til Linux diverse små grafiske brugerapplikationer, mens det meste low-level kernehalløj er ren C.
Er det nogenlunde rigtigt forstået? Bare et nysgerrigt spørgsmål, da man jo godt vil fatte bare lidt af det der sker inden for udviklingen af Linuxkernen, uden at være erfaren programmør :)'
Du har fuldstændig ret. Men grunden til at folk ikke har brugt andet end C i kernen, er jo netop at det ikke har været muligt. Nu når det er muligt at skrive c++, kan det være at flere bruger det til at lave små sjove ting. For slutbrugeren har det ingen betydning overhovedet - andet end udviklingen på et tidspunkt går end smule hurtigere da det er lettere at programmere i c++.
Det minder mig lidt om min webbank, som ikke ville supporte Linux, fordi de kunne se på deres statistikker at der ikke var nogen der brugte det. Dette var jo ikke så overraskende, eftersom Linux ikke virkede med deres system...
Personligt vil jeg nok vente et par år (eller til det kommer med som standard i kernen), for at se hvordan stabiliteten er i forhold til kernen, før jeg begynder at lave noget kernemulletjavs i c++.
writing kernel code in C++ is a BLOODY STUPID IDEA.
Mere tydeligt kan man vist ikke sige: "Det her patch kommer aldrig med i mainline" uden rent faktisk at ytre de ord.
Mere tydeligt kan man vist ikke sige: "Det her patch kommer aldrig med i mainline" uden rent faktisk at ytre de ord.
Mit primære sprog er C++, men hvis jeg skulle skrive en kernel ville det ganske bestemt være i C og assembler.
Folk siger at man kan skrive kode der performer fint i C++, og det er også rigtigt. Jeg skriver selv spilkode, så jeg ved det kan lade sig gøre, hvis man ved hvad der sker bag kulisserne i C++.
Problemet er bare, at hvis man tillader C++ i kernelen, så vil du have mange flere muligheder for at skrive kode der performer dårligt.
Tag f.eks. noget så rart som C++'s virtual funktioner.
Der er mange der bruger dem fordi de er praktiske, uden at vide at de koster en virtual tabel i rammen, og at det rent faktisk er funktionspointere, hvilket kan forårsage et dyrt cache miss.
Så alt i alt er er jeg enig med Linus. At åbne for C++ i kernelen er en dårlig ide.
Folk siger at man kan skrive kode der performer fint i C++, og det er også rigtigt. Jeg skriver selv spilkode, så jeg ved det kan lade sig gøre, hvis man ved hvad der sker bag kulisserne i C++.
Problemet er bare, at hvis man tillader C++ i kernelen, så vil du have mange flere muligheder for at skrive kode der performer dårligt.
Tag f.eks. noget så rart som C++'s virtual funktioner.
Der er mange der bruger dem fordi de er praktiske, uden at vide at de koster en virtual tabel i rammen, og at det rent faktisk er funktionspointere, hvilket kan forårsage et dyrt cache miss.
Så alt i alt er er jeg enig med Linus. At åbne for C++ i kernelen er en dårlig ide.
#10 Nej GNU (gcc/g++) er en compiler som er fri den kan du bruge hvor som helst også på FreeBSD og andre Linux / Unix Cloner også windows.
Men borset fra det er det en ganske nice compiler som godt vil og dette nye fremskridt er en god ting bare en ting som under mig lidt er at hvis jeg skulle komme til at glemme at lave en Exception Handle til en stump kode og dette stump kode Eksekvere sig selv i "Funny ram" pga en fejl, hvor ender det så og i værste tilfælde vil det have effekt på den kørende Kernal i så fald så ser det ud til at det hedder By By Linux (Reboot.)
håber at de har lavet en over ordnet Exception handle for disse små forudsigelser, for det er noget som vil have uhyggelig effect.
Men borset fra det er det en ganske nice compiler som godt vil og dette nye fremskridt er en god ting bare en ting som under mig lidt er at hvis jeg skulle komme til at glemme at lave en Exception Handle til en stump kode og dette stump kode Eksekvere sig selv i "Funny ram" pga en fejl, hvor ender det så og i værste tilfælde vil det have effekt på den kørende Kernal i så fald så ser det ud til at det hedder By By Linux (Reboot.)
håber at de har lavet en over ordnet Exception handle for disse små forudsigelser, for det er noget som vil have uhyggelig effect.
#19 der tager han jo selv fundamentalt fejl. Exceptions medfører at du intet kan sige om dit system, og faktisk burde reboote, uanset om du catcher og gør ved. Så jeg kan ikke se at det er noget problem. Exceptions er jo blot en mekanisme til at fortælle at noget ekceptionelt er sket.
Derudover er ethvert godt C program også lovligt C++, dermed mener jeg, at det kun er en fordel at kunne (SPARSOMT) benytte nogle af de styrker som C++ giver dig. F.eks. "compile-time programmering" vha. templates.
annoia, jep, jeg jublede også, lidt af samme grund.
Derudover er ethvert godt C program også lovligt C++, dermed mener jeg, at det kun er en fordel at kunne (SPARSOMT) benytte nogle af de styrker som C++ giver dig. F.eks. "compile-time programmering" vha. templates.
annoia, jep, jeg jublede også, lidt af samme grund.
#21
[Nej GNU (gcc/g++) er en compiler som er fri den kan du bruge hvor som helst også på FreeBSD og andre Linux / Unix Cloner også windows.]
Ved ikke hvem du skrev til, men det var ihvertfald ikke mig.
Jeg er associate medlem af FSF, så jeg tror nu jo jeg ved hvilken status deres software har... :)
[Nej GNU (gcc/g++) er en compiler som er fri den kan du bruge hvor som helst også på FreeBSD og andre Linux / Unix Cloner også windows.]
Ved ikke hvem du skrev til, men det var ihvertfald ikke mig.
Jeg er associate medlem af FSF, så jeg tror nu jo jeg ved hvilken status deres software har... :)
#20
Det er rigtigt at c++ åbner nogle muligheder for at skrive dårlig kode hvis man ikke er bevidst om hvad der foregår bag kulissen. Men er det ikke et eller andet sted et krav man kan stille til folk der bidrager til kernen? Jeg mener, der er mange (mange!) ting man skal være sig bevidst alligevel, i forhold til almindelig usermode programmering.
Jeg forstår ikke rigtig denne aversion imod c++ på kerneniveau..
Det er rigtigt at c++ åbner nogle muligheder for at skrive dårlig kode hvis man ikke er bevidst om hvad der foregår bag kulissen. Men er det ikke et eller andet sted et krav man kan stille til folk der bidrager til kernen? Jeg mener, der er mange (mange!) ting man skal være sig bevidst alligevel, i forhold til almindelig usermode programmering.
Jeg forstår ikke rigtig denne aversion imod c++ på kerneniveau..
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