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.

Bättre prestanda med Tiger?

Tråden skapades och har fått 20 svar. Det senaste inlägget skrevs .
1
  • Oregistrerad
  • 2005-04-27 20:33

Kommer iMacen att prestera bättre med Tiger? Har jag rätt när jag tror att iMac G5 har en 64-bitars cpu precis som PowerMacen? Det skrivs nämligen att den kommer jobba snabbare i Tiger... Nån som vet mer?

:rolleyes:

  • Medlem
  • Alvesta
  • 2005-04-27 20:51

Ja, Tiger är snabbare men det har inget med 64-bitar att göra.

  • Oregistrerad
  • 2005-04-27 21:00

Nehe ok. Då förstår jag, men har iMacen 64-bitars processor?

Om det är en iMac G5, ja.

  • Oregistrerad
  • 2005-04-27 21:18

Känns det då nödvändigt med en 64-bitars processor, vad gör den för nytta? Om man inte utvecklar det?

Ursprungligen av Wheat:

Känns det då nödvändigt med en 64-bitars processor, vad gör den för nytta? Om man inte utvecklar det?

64-bitars processor innebär bara att processorn kan adressera mer minne. Nog så viktigt för vissa tillämpningar men inget som har betydelse för gemene man. I dagsläget, kanske ska tilläggas... ("640 kB is enough for anyone" )

  • Oregistrerad
  • 2005-04-27 21:44

Ovetande jag

Jag trodde att Tiger skulle vara optimerat för 64-bitars processorer, där se man :rolleyes:

  • Oregistrerad
  • 2005-04-27 21:46

Det är detta jag menar, Tiger ger dig 64-bitars bearbetning.

Ursprungligen av Wheat:

Ovetande jag
Jag trodde att Tiger skulle vara optimerat för 64-bitars processorer, där se man :rolleyes:

Optimerat och optimerat... Tiger har helt enkelt fullt stöd för 64-bits adressering.
Read all about it

  • Oregistrerad
  • 2005-04-27 22:41
Ursprungligen av Johan Sölve:

Optimerat och optimerat... Tiger har helt enkelt fullt stöd för 64-bits adressering.
Read all about it

Wehoo, thats what I needed!
Tackar

  • Medlem
  • Mölndal
  • 2005-04-27 21:54

Jag har hört att Tiger är grymt mycket snabbare på det mesta, inkl Safari. Fråga mig inte hur de gjort.

64-bitars bearbetning minsann. Gäller det hela datorn eller bara modermodemet?

  • Medlem
  • Höganäs
  • 2005-04-27 23:03

Alltså kan vi nu använda kommandoradsprogram för att smidigt räkna på den mänskliga genupsättningen. Perfekt!

Åsså kan vi adressera - hur mycket? - ok. Jättemycke minne - långt mer än 4 GB (Som ju hittills känts något som en mopedstrypning).

Vadå?
64 bitar ett säljargument? Näää. Det tror jag inte. Varför ska datortillverkarna vilja få oss att byta dator?

/Micke, som uppenbart bara har en G4-processor

  • Medlem
  • Gävle
  • 2005-04-28 00:15

kan inte 64-bits cpuer ta in dubbelt så mycket i processorn varje hz(kom inte på något bättre ord jus nu, lite trött) också? och därmed beräkna saker snabbare.

  • Medlem
  • Alvesta
  • 2005-04-28 00:34
Ursprungligen av nr3:

kan inte 64-bits cpuer ta in dubbelt så mycket i processorn varje hz(kom inte på något bättre ord jus nu, lite trött) också? och därmed beräkna saker snabbare.

Nej. De kan adressera mer internminne. 64-bitarsprocessorer och program blir snabbare om datan som behandlas överstiger 4 Gb (taket för 32-bitar) eftersom virtuellt minne inte behöver utnyttjas förutsatt att det finns tillräckligt med riktigt RAM-minne.

Plus att en 32-bitarsprocessor måste dela upp beräkningar (tal?) som är större än 32 bitar, och använda två klockcykler för att utföra beräkningen, medan en 64-bitars kan köra det på en. Dock kan två beräkningar som understiger 32 bitar inte knölas in i en klockcykel bara för att processorn kan hantera 64 bitar.

Den beskrivningen är väldigt förenklad, och säkert inte så kompetent ur teknisk synvinkel. Men tydligen är det väldigt få av de uppgifter som brukar göras på en vanlig konsumentdator, som behöver mer än 32 bitar.

Så i väldigt stora beräkningar, är G5an snabbare eller?
I vilka program gör man sånna beräkningar?

  • Oregistrerad
  • 2005-04-28 16:03

Nu är inte jag någon fena på detta, men det låter som att den inte är snabbare i rent hemmanvändande, men i stora processer klarar den mer. Onödigt för oss "vanliga" människor alltså?

Ursprungligen av Galeriel:

I vilka program gör man sånna beräkningar?

Det är en fråga jag också skulle vilja ha ett svar på. Talar vi om bild-, musik-, och filmredigering, eller talar vi om vetenskapliga uppgifter som har att göra med DNA eller simulering av jet-drift? Om man har nytta av det i bildredigering, drar man då nytta av 64 bitar i det mesta man gör, eller gäller det mest gaussisk oskärpa och annat tungt på bilder i storleksordningen 100 MB?

  • Medlem
  • Uppsala
  • 2005-04-28 18:01

Tiger Finder-program borde gå i 64 bitar ! (att Finder hanterar 64 bit)

Då blir det snabbare "skrivbordet" ( det som många har längtat efter )

inklusive mej

  • Oregistrerad
  • 2005-04-28 19:10

Jag hoppades på en snabbare responstid över lag. Jag är iofs ganska ny med Mac så jag är troligen van vid win responsen. Onödigt om man tänker efter, jag tror jag har blivit en lugnare person sen jag skaffa Mac

Detta kanske säger en del om vad 64 bitar betyder:

Citat:

Panther introduced rudimentary 64-bit support to Mac OS X. It expanded the virtual address space (in the kernel, anyway) to 64 bits and allowed the use of 64-bit registers and the instructions that manipulate them (i.e., 64-bit math). But processes other than the kernel still saw a 32-bit address space. A single process could work with more than 4GB of memory (remember, the Power Mac G5 can hold up to 8GB RAM), but doing so required the programmer to manually juggle several 32-bit-addressable chunks of memory at once.

Tiger takes Mac OS X another small step in the 64-bit direction by allowing any process to see a 64-bit address space. Such a process must use 64-bit pointers in its code, of course, and that means that any libraries it uses must also be compiled to use 64-bit pointers.

In Tiger, the only 64-bit library is "libSystem," which is basically the BSD layer. A 32-bit version of libSystem is also included, of course (otherwise 32-bit applications would not run on Tiger).

A process can do a lot using only libSystem: file and network i/o, math, inter-process communication, er...more math. But the notable thing it can't do is any sort of GUI operation. (Curses doesn't count, sorry.)

For GUI applications that need to address more than 64-bits of memory as part of their work, the recommended strategy in Tiger is to spin off a 64-bit "worker thread" that only uses libSystem and communicates its results back to the host application using one of the various inter-process communication mechanisms.

This confinement of 64-bit processes to a non-GUI jail might seem severe, but in practice, a large proportion of processes that need to be 64-bit are already "faceless" worker processes doing computations on behalf of some larger system: offline rendering, server processes, scientific computing, etc. It's also a step up from Panther's 64-bit support, which is something at least.

It's clear that the road to "full 64-bit support" will be a long one. There are few benefits to being a 64-bit process for the vast majority of GUI applications. Nevertheless, it's safe to assume that, eventually, all Macs will include 64-bit CPUs. The introduction of 64-bit versions of all Mac OS X subsystems (Carbon, Cocoa, Core Foundation, QuickTime, Quartz, etc.) seems inevitable.

I just wonder how much benefit there will be from introducing any of that support piecemeal. For example, it'd seem unfair for Carbon to be 64-bit while Cocoa was not. All the higher-level GUI libraries rely on lower-level services like Quartz and Core Foundation anyway. So it seems to me that the best move in the future will be to roll out a complete 64-bit system all in one shot. That's a tall order, which is why I think it'll be a while.

Källa till citatet.

64 bitar lär inte göra saker snäppigare om jag förstår saken rätt. Det verkar utifrån från citatet som att det är ganska få tunga uppgifter som tjänar på det?

Om man läser resten av den maffiga artikeln på Ars Technica så hittar man å andra sidan något om att kernlen har blivit multitrådad. Jag är inte tillräckligt insatt för att förstå vad det betyder, men det kan kanske ge en bättre respons i gränssnittet? Eller så kanske det minimerar de där tillfällena när badbollen hänger kvar irriterande länge? Någon som vet?

1
Bevaka tråden