Denna delen av 99 uppdateras inte längre utan har arkiverats inför framtiden som ett museum.
Här kan du läsa mer om varför.
Mac-nyheter hittar du på Macradion.com och forumet hittar du via Applebubblan.

Carbon mot Cocoa

Tråden skapades och har fått 22 svar. Det senaste inlägget skrevs .
1

Jag har konverterat en del av mina gamla program och moduler till Carbon på sistone, men det är rent chockerande hur långsamt det är. Är Carbon mycket långsammare än Cocoa, eller är det bara OSX som är så mycket långsammare än MacOS9? Vad säger ni som jobbar i Cocoa? Finns här någon som har erfarenheter av båda?

  • Oregistrerad
  • 2003-04-21 13:39

Har ingen erfarenhet av carbon som programmerings verktyg men använt cocoa en hel del.
Mina erfarenheter säger mig att carbon program är allmänt långsamma och cocoa är snabbare. Tror det beror på språket(obj.c och c++).

Sen ser alla carbon program så tråkiga ut med så man undviker dem även om de vore snabba.

Alla API-er har väl sina flaskhalsar. Språk med för den delen. Det går inte att uttala sig generellt om att A är snabbare än B.

Kan du ge något exempel på kod som blir märkbart långsammare?

/P

Jag har inte lärt mej Cocoa än, så jag kan inte jämföra med det, så jag jämför Carbon med Classic och gamla Macar med gamla MacOS.

En vanlig 2D-animation mest baserad på en massa CopyBits går väldigt mycket långsammare. Min G4/733 blir ifrånsprungen, lätt, av en PB280c (66 MHz)! Visserligen kör G4'an i 24-bitars färg medan Duon kör i 256, och OSX ger ett extra dubbelbuffringssteg (än så länge, jag kan gå runt det) men i alla fall. Animationerna på Duon är minst dubbelt så snabba. Med tio gångers skillnad på processorn och liknande skillnad på bussen (CopyBits ska gå supersnabbt på en G4) så är det för mycket.

Frågan är om Cocoa skulle hjälpa, dvs att Carbon har så mycket klister och bjäfs som slöar ner medan Cocoa kanske har kortare vägar. Eller?

Jag har hört uppgifter om att även OpenGL skulle vara segt i OSX. Stämmer det?

Det är detta jag hävdat hela tiden. Vissa saker är märkligt slöa i OS X.

Citat:

Skrevs ursprungligen av Ingemar Ragnemalm
Jag har hört uppgifter om att även OpenGL skulle vara segt i OSX. Stämmer det?

Det stämmer. I OpenGL-spel med många polygoner (Warcraft III exempelvis) tuggar det på bra mycket långsammare i OS X än om jag kör spelet i OS 9.

Även Quake III går söligare. Inte de "vanliga" Quake III banorna, de har inte så många polygoner, men om jag vill köra exempelvis den så kallade MODen "Urban Terror" för Quake III i OS X så går det mycket sämre än i 9:an.

Trist.
Vad sysslar Apple med? Om inte prestanda optimeras (mycket) mer i OS X kommer inte (ska vi säga tillräckligt?) många Windows-användare att byta. OS Xs fräscha utseende räcker tyvärr inte... De flesta vill ha fart!!! (främst i spel då, såklart...)

Jag hade i och för sej förutspått att ett avbrottsstyrt OS blir långsammare än ett kooperativt, och jag fick rätt, men så rätt ville jag inte ha!

Jag undrar vad problemet är. För många lager mellan anropen och hårdvaran? För mycket pipeline-skjutningar i alla avbrott?

Nu hoppas jag på Jaguar, eller möjligen nåt fiffigt sätt att ställa systemet i "spelvänligt läge" eller liknande.

Tja, Windows har länge varit flersnoppande (multitasking, lite dålig vits, jag vet...;)) och där går saker som på räls. (när det inte kraschar, såklart...)

Be OS. DET VAR SNABBT DET!!! Och jätte-multitasking...
Varför köpte inte Apple det istället?

Jag kör Jaguar. Lite snabbare än i tidigare OS X versioner är Open GL, men inte mycket.

  • Medlem
  • Stockholm
  • 2003-04-24 16:26

Vill du testa ett program som utnyttjar OpenGLtill max på MaxOSX, ta hem Sketchup (www.sketchup.com). (Tidsbegränsad demo finns). Men Jaguar är ett måste. det går mycket snabbare än tidigare tom på min gamla Pismo (powerbookG3 Firewire) med ATI Rage128 kort inbyggt. Och på burk med dubbla processorer, mycket RAM och nytt grafikkort med mycket VRAM går det inte att jämföra.

Jag vet inte. Men jag tror det handlar om optimeringar som är missade.

John Carmack säger ju att OpenGL på OS X kickar OS9 rumpa Och i de flesta fall är jag bered att hålla med honom. Men inte i alla. Som sagt, optimeringar.

  • Medlem
  • 2003-04-24 16:48
Citat:

Skrevs ursprungligen av star-affinity
Tja, Windows har länge varit flersnoppande (multitasking, lite dålig vits, jag vet...;)) och där går saker som på räls. (när det inte kraschar, såklart...)

Min erfarenhet av multitasking i Windows är den rakt motsatta. Märkligt. Så länge man inte gör något annat så fungerar allt bra, men under stress blir Windows sjukt segt. Markören börjar hoppa, och fönster ritas upp i ultrarapid. Min erfarenhet av spel i Windows är inte den bästa heller (då inte sagt att OSX skulle vara bättre).

Det ät möjligt. Jag kör inte Windows så hårt och så ofta.
Jag menar mest att saker och ting (spel) inte behöver slöas ned alldeles för mycket bara för att operativsystemet har "äkta multitasking".

Be OS är ett bra exempel.
Windows ett annat. (i varje fall vad gäller spel).

  • Medlem
  • 2003-04-24 19:02

Som tidigare nämnts, så beror det säkert på optimeringar. Windows2000 var inte heller så snabbt när det lanserades.

Jag tror att den dubbla dubbelbuffringen smärtar mycket. Jag skulle vara nyfiken på att se vad du får för resultat om disablade din egen dubbelbuffring (och endast använde OS X egen) respektive disablade OS X egen buffring. Du verkar veta om det själv, så jag kan egentligen inte tala med erfarenhet om vad du kommer att få för resultat, bara att det vore kul att höra vad du kommer fram till.

  • Oregistrerad
  • 2003-04-25 00:54
Citat:

Skrevs ursprungligen av Ingemar Ragnemalm
Jag hade i och för sej förutspått att ett avbrottsstyrt OS blir långsammare än ett kooperativt, och jag fick rätt, men så rätt ville jag inte ha!

Jag undrar vad problemet är. För många lager mellan anropen och hårdvaran? För mycket pipeline-skjutningar i alla avbrott?

Nu hoppas jag på Jaguar, eller möjligen nåt fiffigt sätt att ställa systemet i "spelvänligt läge" eller liknande.

Är inte alla OS avbrottsbaserade, menar själva maskinen skickar ju olika typer av traps ju? Eller misstolkar jag dig?

  • Oregistrerad
  • 2003-04-25 21:37

Det handlar om hur CPUn fördelar tiden mellan processerna. I ett non-preemptive/cooperative system så kan OSet bara byta process vid vissa punkter i koden, typiskt när programmet gör ett anrop in i kärnan. Det innebär att ett program som inte gör dessa anrop aldrig kommer att bytas ut mot ett annat program. Exempelvis

while(true);

skulle låsa datorn helt.

I ett preemptive så har varje process en viss bestämd tid som den får köra (en quantum) och när denna tid är slut så kan OSet gå och avbryta den process som körs och låta en annan köra istället. I detta fall skulle datorn fortsätta att fungera även om man hade kod som ovan ... fast man slösade ju lite

Fördelen med den första varianten är att det är ganska enkelt att implementera och att man kan se till att man inte behöver spara så mycket information vid processbyta. Nackdelerna är att en process kan låsa hela datorn och det kan bli svårare att låta högprioriterade processer köra så fort som möjligt.

Fördelen med den andra är att processerna kan avbrytas när som helst, nackdelen är att man antagligen får ägna mer tid åt att spara information.

  • Oregistrerad
  • 2003-04-25 23:47
Citat:

Skrevs ursprungligen av Jan Erik Moström
Det handlar om hur CPUn fördelar tiden mellan processerna. I ett non-preemptive/cooperative system så kan OSet bara byta process vid vissa punkter i koden, typiskt när programmet gör ett anrop in i kärnan. Det innebär att ett program som inte gör dessa anrop aldrig kommer att bytas ut mot ett annat program. Exempelvis

while(true);

skulle låsa datorn helt.

I ett preemptive så har varje process en viss bestämd tid som den får köra (en quantum) och när denna tid är slut så kan OSet gå och avbryta den process som körs och låta en annan köra istället. I detta fall skulle datorn fortsätta att fungera även om man hade kod som ovan ... fast man slösade ju lite

Fördelen med den första varianten är att det är ganska enkelt att implementera och att man kan se till att man inte behöver spara så mycket information vid processbyta. Nackdelerna är att en process kan låsa hela datorn och det kan bli svårare att låta högprioriterade processer köra så fort som möjligt.

Fördelen med den andra är att processerna kan avbrytas när som helst, nackdelen är att man antagligen får ägna mer tid åt att spara information.

Oki då misstolkade jag vad avbrottsbaserat menades i detta sammanhang

  • Oregistrerad
  • 2003-04-26 07:57

Njaa, det behövs ju avbrott för att kunna avbryta den process som körs men "vanliga" avbrott hanteras ju av bägge typerna. Så beroende på hur man tolkar det

  • Oregistrerad
  • 2003-04-26 12:53
Citat:

Skrevs ursprungligen av Jan Erik Moström
Njaa, det behövs ju avbrott för att kunna avbryta den process som körs men "vanliga" avbrott hanteras ju av bägge typerna. Så beroende på hur man tolkar det

Jo visserligen

Citat:

Skrevs ursprungligen av ace4711
Jag tror att den dubbla dubbelbuffringen smärtar mycket. Jag skulle vara nyfiken på att se vad du får för resultat om disablade din egen dubbelbuffring (och endast använde OS X egen) respektive disablade OS X egen buffring. Du verkar veta om det själv, så jag kan egentligen inte tala med erfarenhet om vad du kommer att få för resultat, bara att det vore kul att höra vad du kommer fram till.

Ja, det kan ligga en del där. Jag tycker inte det borde göra så mycket, för en CopyBits ska gå väldigt fort på en QuickSilver, men jag ska testa.

Jag ser också varianten att ta mej förbi systemets dubbelbuffring och skriva direkt i bildminnet. Det är lite farligt, men värt att prova. Det borde förlora mot CopyBits, men CopyBits hastighet är inte helt pålitlig har jag märkt.

En fråga till från mej som inte orkar (har tid) att läsa in mej på Cocoa riktigt än:

Hur är det med portabiliteten? Om man har ett program skrivet för Carbon eller Cocoa, och vill porta det till Den Mörka Sidan (MSW), eller Linux för den delen, vilken är bäst?

Det som oroar mej är Objective-C som språk. Finns det till andra plattformar? API'erna kan man skriva klister för, även om det är mycket jobb, men om språket är helt olika så är det ofta omöjlilgt att kompilera samma kod mot två olika plattformar.

Säga vad man vill om C++ (och det gör jag som ni vet) men portabilitet är det språkets trumfkort över alla andra. Kan man/bör man använda Cocoa från andra språk än Objective-C och Java?

Citat:

Skrevs ursprungligen av Ingemar Ragnemalm

Säga vad man vill om C++ (och det gör jag som ni vet) men portabilitet är det språkets trumfkort över alla andra. Kan man/bör man använda Cocoa från andra språk än Objective-C och Java? [/B]

Man kan använda Objective-C++, vilket är typ som det låter. Du har tillgång till både Objective-C och C++. Vilket kanske kan underlätta en del.

  • Oregistrerad
  • 2003-05-16 21:39
Citat:

Skrevs ursprungligen av Ingemar Ragnemalm
En fråga till från mej som inte orkar (har tid) att läsa in mej på Cocoa riktigt än:

Hur är det med portabiliteten? Om man har ett program skrivet för Carbon eller Cocoa, och vill porta det till Den Mörka Sidan (MSW), eller Linux för den delen, vilken är bäst?

Det som oroar mej är Objective-C som språk. Finns det till andra plattformar? API'erna kan man skriva klister för, även om det är mycket jobb, men om språket är helt olika så är det ofta omöjlilgt att kompilera samma kod mot två olika plattformar.

Säga vad man vill om C++ (och det gör jag som ni vet) men portabilitet är det språkets trumfkort över alla andra. Kan man/bör man använda Cocoa från andra språk än Objective-C och Java?

Cocoa är portat till viss mån iom GNUStep, och själva obj.c ingår i gcc så ska gå att kompilera på andra miljöer med, har dock bara testat på solaris och där pajade länkningen pågrund av att Lunds Universitet saknade filer. Dock gick kompileringen väldigt fint annars bara två rader att skriva. Kolla på www.utvecklaren.com för att se min enkla hello world.

Om jag inte missminner mig skall det väl traditionellt sätt finnas kompilatorer till alla övriga plattformar. Under NeXTStep-eran var ju Mac-plattformen den ända som inte hade någon portad version av OpenStep om jag förstått saken rätt. Huruvida API:erna har fortsatt utvecklas vet jag dock inte så det låter jag vara osagt...

/Jont Olof

1
Bevaka tråden