Omskrevet kjerne!

[Dj_Offset]

sensur

[A_N_K]

Quote:

Den 2002-07-28 13:29, Dj_Offset skrev: At C++ har dårligere ytelse er etter min mening en myte som bygger litt på at C++ kompilatoren generelt sett er litt dårligere enn C kompilatoren. GCC 3.1.1 er ute og gir vesentlig bedre ytelse for C++.

Objektorientering gir generelt overhead, så vidt jeg kan se er det ingen som bestrider det. Men gode kompilatorer kan delvis rette på det. Det er en god C/C++ sammenligning på

http://www.coyotegulch.com/reviews/intel_c...gcc_bench2.html

I den ene testen gjør Intel C++ 6.0 raskere 00-kode enn C stil! Men i denne testen vinner G++ med C stil kode ...

[Dj_Offset]

sensur

[A_N_K]

Quote:

Den 2002-07-28 14:53, Dj_Offset skrev: Javel? Dårlig påstand, selv om du delvis har rett. Forskjellen er såpass stor i implementasjonen at disse implementasjonene i bunn ikke kan sammenlignes.

Jaha? Hvis OO ikke gir overhead, hvorfor snakker Alexander Stepanov (den ene forfatteren av det omtalte STL) om "abstraction penalty"? Jeg kan ikke prinsipielt se at det er ett eneste tilfelle hvor OO skal være raskere enn strukturert kode (i praksis kan dette skje, men da har åpenbart skaperne av kompilatoren gjort en bedre jobb med optimisering av OO enn standard strukturert kode). Det KAN være like raskt, men da gjennom optimisering (inlining). Hvis du sjekker linken min kan du se at spesielt Intel C++ faktisk klarer å eliminere OO overhead i visse tilfeller.

Ser ut som du tolker innlegget mitt som et angrep på OO. Tvert imot! Du sier jo selv at strenger er treigere, men mer robuste. Det er jo det som er poenget. OO kan gi overhead, men har en del fordeler. Jeg bruker selv std::string, osv. Men for rå ytelse vil jeg tro at C stil C++ vil være raskest.

[Dj_Offset]

sensur

[A_N_K]

DJ: Tillat meg å generalisere litt; OO == abstraksjon. Selvfølgelig kommer graden av abstraksjon og overhead an på hvor dyp OO du har, og hvordan den blir implementert (virtuelle klasser f.eks). En ting jeg ikke har fått med meg forresten; går det an å inline klassefunksjoner utenom interfacet? Dvs. hvis du implementerer en funksjon i klassekroppen blir den jo automatisk inlinet.

Hadde en lærer som mente at Intel hadde prøvd seg på en objektorientert prosessor en gang, ble ikke så bra visstnok :]

Edit: Bare så det er sagt, synes jeg OO er mer oversiktlig, spesielt med større programmer. Lærer meg Windows API nå, og det er noe frustrerende. Mener å huske at John Carmack sa i et ikke alt for gammelt intervju at teamet hadde gått over til C++ for Doom3 også, til tross for at de har foretrukket C tidligere.

Enda en edit:

Fant enda en svært interessant kompilatorsammenligning. Intel C++ er ikke tatt med, men G++ og KAI (kjøpt opp av Intel) derimot. Mye av testingen går på OO-ytelse.

http://annwm.lbl.gov/bench/

 

En litt mindre omfattende bench, med fokus på ytelse, kompileringstider (ICC, G++):

http://people.redhat.com/dnovillo/SPEC/

 

<font class=editedby>[ Denne Melding var redigert av: A_N_K på 2002-07-28 16:28 ]</font>

 

[ Denne Melding var redigert av: A_N_K på 2002-07-28 19:15 ]

[termos]

OMFG!

[cyclo]

Lol. Definisjonskrangel på sitt høyeste nivå...

 

 

Dessuten gir polymorfisme bedre seksliv (husker ikke link)

[Dj_Offset]

sensur

[Dj_Offset]

sensur

[A_N_K]

Quote:

Den 2002-07-29 14:15, Dj_Offset skrev: Mener du noe alla, dette? Code: class foo { (...) int do_something(); }; inline int foo::do_something() { return something_smart; }

Det var nok det jeg tenkte på. Var bare ikke sikker på om det gir den ønskede effekten, siden jeg har lest at inlining i klasser foregår ved å implementere i klassekroppen. Men kompilatoren klager ikke, så det burde gå.

 

Quote:

Har du sett på Qt? http://www.trolltech.com/qt/ Plattform uavhengig er det også :wink:

Tenkt på å kikke på Qt en eller annen gang senere, når jeg har kommet gjennom WinAPI. Qt pakker jo inn API-kall uansett. Men i forbindelse med Linux går jeg vel like gjerne rett på Qt. Men hvordan integrerer Qt med ulike window managers, Gnome har vel et eget toolkit, GTK?

[Dj_Offset]

sensur

[CAT0]

[ Denne Melding var redigert av: hanscats på 2002-07-30 00:48 ]

[A_N_K]

Quote:

Den 2002-07-30 00:08, Dj_Offset skrev: Nei, Qt er _IKKE_ en API wrapper! Den tegner sitt eget sett av widgets på windows gjennom GDI og i X11 ved hjelp av XLibs. Det er dette som gjør Qt plattformuavhengig på kildekode nivå. (Alle windows, stort sett alle POSIX systemer med X11, Linux framebuffer og MacOSX).

Det står jo at det bruker WinAPI for events i alle fall. Når det gjelder ytelse, står det bare at Qt kjører minst like raskt som MFC (som er en wrapper), og har samme minneforbruk. Hadde vel uansett føltes bedre enn å kjøre en MS-wrapper (MFC) i noe tilfelle :smile: Føler meg ikke helt hjemme med den MS-syntaksen ..

 

Quote:

Et Qt program har ingen spesiell integrasjon med window managere. Det fungerer på samme måte som om du skulle åpne et Gnome program i KDE eller omvendt. (KDE er bygget opp av Qt så det er kort vei fra Qt til KDE) Se forøvrig denne: http://www.trolltech.com/products/qt/white...tepaper-15.html

Ser det står at Qt emulerer utseendet til plattformen det kjører på, men det vil altså ikke se ut som et standard KDE-vindu f.eks? Man må da bruke KDE-rammeverket, er det sånn å forstå?

[Dj_Offset]

sensur

[A_N_K]

Quote:

Den 2002-07-30 19:22, Dj_Offset skrev: Nja, det står at Qt bruker Win32 GDI APIet til å tegne og håndtere events.

'Qt/Windows uses the Win32 API and GDI for events and drawing primitives.'

GDI er grafikkspråk, ala DirectDraw kan du si. Så vidt jeg kan se må Qt-programmer kunne ta imot events fra Windows, noe som ikke har med GDI å gjøre (eller har jeg misforstått totalt!?).

Quote:

MFC er blant annet også bygget oppå GDI. Qt er _ikke_ bygget på MFC -- det ville vært tregt for det første, og ikke spesielt portabelt.

Jeg sa ikke noe i den retning heller.

[Dj_Offset]

sensur

[Gjest mafister]

polymorph wanna cracker?

[nesquik]

Hmm. For å få en ting klart: Jo lenger opp i nivåene du kommer jo tregere blir programmet. Lager du et språk som skjønner kode ala "les fila. bytt ut alle a'er med f'er. lagre filen som %orginaltfilnavn.ny" vil dette selvsagt kompileres til drittreg kode. For å trekke tråden videre, C er lavere språk enn C++.

 

Dette betyr at du har mer kontroll over C programmer, på godt og vondt. Du kan lettere gjøre "feil" i C men du kan også få ytelses øking. Det skal også sies at det i dag finnes så gode kompilatorer at denne differansen er så liten at den er neglesjerbar. Det er også grunnen til at man sjelden sjelden bruker asm.

 

Forøverig syns jeg opprinnelses posten var morsom...

hook, line, and sinker

[SnowDOG_]

Eg må si at kenski er en geni!!!!

Har får akkurat det han er ute etter.

Han klarer det på en måte som få andre klarer.

 

Hadde han bare brukt den intelligensen til noe nyttig hadde han muligens blitt noe stort!!

 

Altså han sier det som skal til for at alle dere DUMBASSES skal starte en krangle om whatever det er snak om! klarer dere ikke se ka han gjør???

Han vil bare starte diskusjoner og krangel og dritt slenging! men dere skjønner jo ikke det.