Vilka nya program är optimerade för G5

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

kommer fcp4 att komma optimerad för G5 ?

och gäller detsamma för dvdstudio pro 2

osv

Det borde de vara. Apple måste visa vad 64 bitars program kan prestera.
Och vad bättre än de egna programmen?

  • Medlem
  • Sundbyberg
  • 2003-06-24 16:36

Känner jag Apple rätt kommer de optimerade programmen först i nästa version... typ till sommaren.

  • Medlem
  • Stockholm
  • 2003-06-24 16:45

Adobe slöar iallafall inte. Kolla in länken i den här tråden.

ja - det måste ju hända en hel del mot att köra 32-bitarsprogram "simulerat" eller hur det nu är idag. FCP helt native 64-bitars version lär bli rejält snabbare

om inte jag minns fel så släpps FCP4 och shake3 i september, dvs efter G5 finns i handeln och runt samma tid panther kommer att finnas tillgänglig, känns som det hör ihop på nått sätt

och 64bitars delen av G5'an kommer nog kunna göra sitt vid MPEG4 encoding av DVSs med, skall bli kul att se/göra

FYI: FCP4 är redan släppt.

  • Medlem
  • Sundbyberg
  • 2003-06-25 11:27
Citat:

Skrevs ursprungligen av el gringo
FYI: FCP4 är redan släppt.

Släppt och släppt... kartongen har inte landat än!;)

Citat:

Skrevs ursprungligen av el gringo
FYI: FCP4 är redan släppt.

oops, my bad :/

men shake släpps väl till hösten?

Om apple vill slå sig (ännu mer) in på filmeffekt marknaden borde dom ju se till att deras kompositions program är så optimerad så möjligt för G5..

Citat:

Skrevs ursprungligen av el gringo
ja - det måste ju hända en hel del mot att köra 32-bitarsprogram "simulerat" eller hur det nu är idag. FCP helt native 64-bitars version lär bli rejält snabbare

Återigen den gamla vanföreställningen att 64bits PPC skulle "emulera" 32 bits kod.

När Apple, IBM och Motorola klurade ut koncepted för PPC i början av 90-talet så var 64bit redan inräknat. Dessutom gjordes "planen" för PPC:ns utveckling sådan att den skulle tåla att lösa oförutsedda tillägg i framtiden enhetligt med grundprinciperna.

Detta visar sig i exempelvis AltiVec som är en oförutsedd funktion som tiden visade behövdes efter att konceptet PPC fötts. Utrymmet i instruktionsuppsättningen fanns redan tillgänglig (men paxxad om man så vill) och det kunde lätt inkluderas utan att första instruktionsuppsättningen. Något man inte kan säga om x86 som idag har instruktionslängder från 1 till 18 bytes för att kompensera för allt nytt som lagts till under åren (PPC har 4 bytes rakt av, vilket ger enklare logik på chippet).

PPC behandlar 64 bit ungefär såhär: jag har 64 stolar i restaurangen, om hovmästaren är gammalmodig och bara känner till 32 (han är ett program kompilerat för 32 bits kod) av dessa stolar så struntar jag väl i att ta in fult med gäster då.
Visst vi får aldrig fullt med gäster och kan inte dra in optimalt med pengar, men det fungerar, och det fungerar lika perfekt som förr då det faktiskt bara fanns 32 stolar.

Det hela är egentligen lite befängt. Måste G4 "emulera" G3 kod bara för att den har AltiVec? Nej! För AltiVec är ett tillägg på det som G3 redan hade. På samma sätt är 64 bit bara ett tillägg på det som 32 bit redan hade.

Jaja, hoppas detta är något lite klarare nu iaf...

Citat:

Skrevs ursprungligen av Fredrik Olsson
Återigen den gamla vanföreställningen att 64bits PPC skulle "emulera" 32 bits kod.

När Apple, IBM och Motorola klurade ut koncepted för PPC i början av 90-talet så var 64bit redan inräknat. Dessutom gjordes "planen" för PPC:ns utveckling sådan att den skulle tåla att lösa oförutsedda tillägg i framtiden enhetligt med grundprinciperna.

Detta visar sig i exempelvis AltiVec som är en oförutsedd funktion som tiden visade behövdes efter att konceptet PPC fötts. Utrymmet i instruktionsuppsättningen fanns redan tillgänglig (men paxxad om man så vill) och det kunde lätt inkluderas utan att första instruktionsuppsättningen. Något man inte kan säga om x86 som idag har instruktionslängder från 1 till 18 bytes för att kompensera för allt nytt som lagts till under åren (PPC har 4 bytes rakt av, vilket ger enklare logik på chippet).

PPC behandlar 64 bit ungefär såhär: jag har 64 stolar i restaurangen, om hovmästaren är gammalmodig och bara känner till 32 (han är ett program kompilerat för 32 bits kod) av dessa stolar så struntar jag väl i att ta in fult med gäster då.
Visst vi får aldrig fullt med gäster och kan inte dra in optimalt med pengar, men det fungerar, och det fungerar lika perfekt som förr då det faktiskt bara fanns 32 stolar.

Det hela är egentligen lite befängt. Måste G4 "emulera" G3 kod bara för att den har AltiVec? Nej! För AltiVec är ett tillägg på det som G3 redan hade. På samma sätt är 64 bit bara ett tillägg på det som 32 bit redan hade.

Jaja, hoppas detta är något lite klarare nu iaf...

Jag tror jag får läsa ditt inlägg...en gång...nä vänta - två gånger till...men tack för att du försökte förklara

och vem menar du är "hovmästaren"?

"PPC behandlar 64 bit ungefär såhär: jag har 64 stolar i restaurangen, om hovmästaren är gammalmodig och bara känner till 32 (han är ett program kompilerat för 32 bits kod) av dessa stolar så struntar jag väl i att ta in fult med gäster då. Visst vi får aldrig fullt med gäster och kan inte dra in optimalt med pengar, men det fungerar, och det fungerar lika perfekt som förr då det faktiskt bara fanns 32 stolar."

Citat:

Skrevs ursprungligen av el gringo
[B]och vem menar du är "hovmästaren"?

Hovmästaren är lite dumt att säga eftersom det numer så gott som alltid körs mer än ett program. Ett program är i mitt fall en hovmästare. Jag gör om det:

Hovmästaren är Mac OS X (Eller något annat fint OS). Ett program är en grupp gäster. Restaurangen kan bara ta emot en grupp med gäster i taget. Förr i tiden fick det bara plats med 32 gäster i restaurangen. Nu har den byggts ut till 64 platser (men fortfarande bara en grupp i taget de kanske är ilska på varandra eller något men det kvittar för hovmästaren kan magiskt skyffla in och ur gästerna ur en kryofrys och låta dem äta i korta små intervall så snabbt att gästerna inte märker det och tror att det bara är de som äter hela tiden iaf, detta är multitasking ).

En del grupper är fortfarande bara 32 personer för de vet inte om (är inte kompilerade för) att det nu finns 64st tillgängliga.

Detta är ju inget problem alls. 32 gäster får gott och väl plats på 64 stolar. Det är inte optimalt ur restaurangens synvinkel men de gamla gästerna (programmen) behöver inte lida ett dugg.

Blev det klarare?

okey - så det finns plats för 64 gäster i den nya G5an...

om jag kör ett gammalt 32-bitars program och ett nytt 64-bitars program...vad händer då? äter hälften av 64bitarsprogrammet själv medan den andra hälften får dela sin måltid med 32-bitarsprogrammet? och vad innebär det i praktiken på "hastigheten"?

Citat:

Skrevs ursprungligen av el gringo
okey - så det finns plats för 64 gäster i den nya G5an...

om jag kör ett gammalt 32-bitars program och ett nytt 64-bitars program...vad händer då? äter hälften av 64bitarsprogrammet själv medan den andra hälften får dela sin måltid med 32-bitarsprogrammet? och vad innebär det i praktiken på "hastigheten"?

Nej, en grupp gäster kan bara äta i taget. Så när ett 32 bits program körs så används hälften av platserna (Eller endast 32 bits funktioner), när ett 64 bits program körs så används alla platser.

Endast ett program kan köras i taget. Vad Mac OS X gör är att den låter varje program köras ett litet kort tag och byter sedan till nästa. Så håller den på och byter mellan alla programmen som är igång flera gånger per sekund. Så ofta att du som användare upplever det som att alla programmen körs hela tiden.

Det är upp till OS X att se till att ett 64 bits program får tillgång till alla 64 bits funktioner och att ett 32 bits program håller sig till 32 bits. Det är därför Apple måste uppdatera OS X. Programmen i sig behöver inte uppdateras (Men det är ju bra om så görs).

Hastighetsmässigt betyder det inte speciellt mycket. PPC har 32 st GPR register och dessa (Tillsammans med FPU och lite annat smått och gott) använder programmen för att utföra sitt arbete, vilket betyder att de måste sparas av OS X när ett program byts så att programmet inte helt plötsligt får helt annan data att arbeta med än vad det ska vara. Dessa register är 32 bit eller 4 bytes nu. Dessa komer att bli 64bit eller 8 bytes. Så i praktiken betyder det att OS X måste spara 128 bytes mer till minnet varje gång ett program byts.
Detta är dock inte mycket att jämnföra med de 512 bytes som krävs för att spara alla AltiVec register. Så min gissning är att prestandan inte kommer att lida alls av detta.

Tack för en utförlig beskrivning, som gjorde mig lite mer upplyst

Nu drar jag till roskilde - tjolahopp!

1
Bevaka tråden