Newsgroup: it.comp.macintosh
Titolo: ppc intel e multitasking

dopo un bel po di mesi dal mio primo mac ocntinuo a godere quando faccio
un encoding video di 12 ore e nel frattempo posso comunque usare
fluidamente i programmi leggeri e il finder.
su win questa cosa non esiste.
ora mi chiedo..quanto di questo è attribuibile ai ppc e quanto ad osx?
osx su intel secondo voi sarà ugualmente multitasking??
-- 
Baciamo Le mani!
http://joefarina.altervista.org
 
iChat: 
joef...@mac.com

 osx su intel secondo voi sarà ugualmente multitasking??
sui P4 HT viene emulato un doppio processore, alcune applicazioni per Win
lo sfruttano, altre meno.
-- 
Stress da rientro? Scopri il magico universo delle pietre!

osx su intel secondo voi sarà ugualmente multitasking??
è un dubbio senza senso
mettiamocelo in testa osx  su intel non è qualcosa di astruso o fuori
dalla norma
è osx 'semplicemente' ricompilato per intel
la stessa differenza che c'è fra linux per sparc e linux per intel

 beh ma sul pc l'encoding invece di metterci 12 ore ne impiega 3 ;)
Dipende da PC, da Mac e da encoder :)
Qui si sta prendendo un encoding solo come compito *pesante*, che si
beve il bevibile. Ma che non tira a mano cose tipo networking e simili.
-- 
non vincono, non vinceranno, non hanno domani
la forza č nel puntello impugnato da oneste fortissime mani

 98-99%
A rigor di logica direi così anche io. Però... io posso dire che il mio
MacOS X è molto più responsivo (ma non solo nella GUI, anche negli
stream, nel lavoro) sotto carico perfino della mia Linux Box.
Diciamo percepibile ad occhio. E questo sul vecchio portatile, un
*portatile*, con il disco che ha. Confrontato con il fisso GNU/Linux.
Ora... io non voglio credere che il multitasking di MacOS X sia migliore
di quello di GNU/Linux.
Da un punto di vista puramente tecnico di la ho un signor scheduler, e
il codice di rete risulta meglio scritto di quello di MacOS X Panther
(che è più bloccante quando non dovrebbe).
A sto punto mi viene da pensare che i 32 registri del PPC qualcosa
contano. Il mio è chiaramente un ragionamento "per assurdo". Io sono un
mezzo logico e sono consapevole che qui non ci sono gli estremi per
ritenerlo vero. Eppure nemmeno non vero.
Sarebbe da indagare.
-- 
non vincono, non vinceranno, non hanno domani
la forza è nel puntello impugnato da oneste fortissime mani

 contano. Il mio è chiaramente un ragionamento "per assurdo". Io sono un
non credo sia un caso che intel stia buttando quanta piu' cache
possibile sui suoi processori ;) ne credo sia un caso che amd, con
l'architettura a 64 bit abbia aggiunto un po' di registri (oltre a una
mmu un attimino piu' decente)
-- 
Deh! Impiacciami, imploroti
sgabazzone rampante!

 Sarebbe da indagare.
sarebbe davvero interessante reperire un confronto


 la stessa differenza che c'è fra linux per sparc e linux per intel
non mi pare senza senso...il processore è diverso.
osx su g5 e su g4 E' diverso in termini di rendimento.
comincioa pensare che no nsono riuscito a farmi capire


 sul p4 ht di mio padre no.
neanche se metti l'encoding in una "cpu" e il resto nell'altra "cpu" 
tramite task manager?
-- 
Giorno^3
giorno at gmail dot com
Forum Italiano TennisTavolo: 
www.fitet.it


I vecchi dec alpha andavano alla grande e tengono botta tuttora
ad esempio per far girare un DB 

 tramite task manager?
va meglio, ma non come osx...giuro che sono imparziale.


 osx su intel secondo voi sarà ugualmente multitasking??
Chiaramente si.
Ciao ... Dino

 che ti pare.
Sto paio di pippe. Lavorando con Archicad, ti garantisco che quando fa
elaborazioni 3D in serie, sul PC non lavori. E ho provato di tutto
(avevo sperato molto nell'HT).
Inoltre in background l'elaborazione rallenta in modo tremendo, e questo
su un P4/2.8 HT. Su un dual G5 2.3 non c'è paragone: i rendering in
background procedono quasi a velocità piena e il finder e anche gli
altri programmi non sembra neppure risentirne, compreso un secondo
Archicad con cui magari lavoro su un'altro file o con VectorWorks.
Sul PC solo per aprire un programma viene da piangere.
E no, su questo del multitasking con applicazioni pesanti in backgrond,
non toccarmi il Mac / Mac OS.

 ora mi chiedo..quanto di questo è attribuibile ai ppc e quanto ad osx?
ho provato svariati s.o. sul mio vecchio pc e TUTTI avevano una gestione
dei processi e quindi una prontezza di risposta migliore.
quindi direi che buona parte e` attribuibile al s.o., fermo restando che
un processore ben progettato da sicuramente una mano.
-- 
@}-,---',-'----,-'-,-'--,-',---,'--'-,-',- Masque
`, NP: The Who - Water

(avevo sperato molto nell'HT).
Provato a impostare il processo mangia risorse a priorita' bassa nel
taskmanager? Solo per cuoriosita'! 

 taskmanager? Solo per cuoriosita'! 
Sì.
Comunque se con l'applicazione in primo piano e niente di pesante in
background, il PC P4/2.8 si difendeva bene, e forse era anche più
veloce, almeno del G5 DP/2.0 (tieni presente che comunque Archicad non
sfrutta i due processori), passando Archicad in background non c'è
confronto: il G5 DP/2.0 resta perfettamente utilizzabile e esegue le
elaborazioni in background molto più velocemente (e questo l'ho notato
senza dover usare cronometri) del PC P4/2.8 HT con Win XP pro e tutti
gli stracazzi, qualsiasi configurazione di priorità si usi.

 mmu un attimino piu' decente)
Mah, io preferisco la soluzione registri ad imbottirmi di cache. :)
-- 
non vincono, non vinceranno, non hanno domani
la forza č nel puntello impugnato da oneste fortissime mani

 Linux x86 (non ho modo di testarlo di persona)
Forse. O forse sono poco ottimizzati. Per dire sulle schede video...
alla fine non viene usata l'accelerazione come con i driver nativi che
invece su Linux x86 e su MacOS X ci sono.
-- 
non vincono, non vinceranno, non hanno domani
la forza č nel puntello impugnato da oneste fortissime mani

 MacOS X č molto piů responsivo 
  Respo-che? ;-)
-- 
    Nicola "nez" D'Agostino
  <!-- 
nezge...@geocities.com
 --remove/togli "getitout" -->

gli stracazzi, qualsiasi configurazione di priorità si usi.
Questa cosa mi era sfuggita: e' chiaro che un DP che non viene
sfruttato completamente (e quindi una delle sue CPU e' libera) sia
piu' reattivo di un SP, anche con HT! ^^
Senza andare su OSX, probabilmente vedresti la stessa cosa usando un
Dual Processor o un Dual Core nelle stesse condizioni del G5 sotto
Windows!
Se non ricordo male, HT ti da vantaggi se il processo non prende il
controllo di tutte le risorse della CPU (ad esempio e' necessario
ricaricare la lunga pipeline, cosi' altri processi possono usare le
risorse inutilizzate), perche' altrimenti la seconda CPU (logica) non
ha nulla da utilizzare! In sostanza, il DP ti da vantaggi sempre, l'HT
no! Dovresti confrontare la situazione del G5 DP con quella di un DP
reale o un Dual Core (possibilmente AMD) per avere un metro di
paragone piu' preciso! ^^

 paragone piu' preciso! ^^
Succede esattamente la stessa cosa che avviene sul g5dp, solo che 
chiaramente sara' molto piu' veloce.
Ciao ... Dino

 va meglio, ma non come osx...giuro che sono imparziale.
E grazie, paragoni un biprocessore con un processore singolo :)
Ciao ... Dino

 E grazie, paragoni un biprocessore con un processore singolo :)
no guarda stai a fare confusione.
non leggi manco i nick?
io ho un powerbook g4


 io ho un powerbook g4
Allora abbassa la priorita' del processo ciuccia cpu in xp dal
taskmanager e miracolosamente avrai un pc molto responsivo. Chiaramente
i tempi di calcolo saliranno, ma non puo' essere altrimenti.
Ciao ... Dino

 Ciao ... Dino
si ok ...conosco il meccanismo, ma comunque non hai la fluidità di un
"misero" g4 in osx.
sarà la gestione del bus o della cache e della ram..non so...ma è così.
un p4 ht 3.6 con un processo pesante con l'encoding diventa più
"tartarugoso" di un g4.
poi magari il p4 finisce in 9 ore mentre il g4 ne impiega 12, ma non ha
senso fare operazioni da un secondo in 4 secondi nel frattempo.


 "tartarugoso" di un g4.
Dipende da cosa fa l'encoding. Quando mi dilettavo con virtualdub e la 
codifica divx, ricordo che il pc era usabilissimo ed era un misero 
athlon 850. Abbassavo la priorita' del processo e potevo dimenticare ci 
fosse.
Ciao ... Dino