Apple abbandona PowerPC e passa a Intel

[nanu10]

Originariamente inviato da erick81

Già, tra G4 e Pentium M non c'è storia già adesso (anche perchè quest'ultimo raggiunge frequenze che G4 si sogna), così come non ce ne sarebbe tra un dual G4 e Yonah.

erick81 vorrei proprio sapere che computer hai, e se hai mai provato un ibook... guarda io prima di comprare il mac, questo inverno, mi ero assemblato un bel athlon 2500+ barton portato a 3200+ con abit nf7s e 512 mb ram, certo ora se lo confrontiamo con un athlon 64 non c'è paragone, ma non penso che sia cmq meno potente di qualsiasi pentium M ora in commercio e se lo è, lo è cmq di poco, bene il mio ibook non me lo ha mai fatto rimpiangere, pur essendo basato su un G4 "obsoleto", tutto questo per dirti che conta "l'esperienza" di uso, e quella del mio ibook con G4 è superiore forse a quella di qualsiasi portatile basato su pentium M con centrino che monta Windows XP poi... de gustibus

[scorpionkkk]

Originariamente inviato da Criceto

L'approccio del Cell ha il vantaggio fondamentale che ogni SPE può lavorare indipendentemente sulla sua memoria, senza intasare il bus di sistema, quindi potenzialmente riesce a lavorare contemporanemante con molti più dati alla volta rispetto ad un processore normale.
C'è un articolo dove sfruttando questa tecnica hanno implementato un algoritmo FFT che ha prestazioni di 100 (CENTO!!) volte superiori ad un processore normale da 3.2 Ghz.

ogni approccio simd distribuito o mimd ha processori che lavorano indipendentemente l'uno dall'altro e sul bus mettono i risultati..non è questo il segreto di Cell...il segreto di Cell sono i $$$: stesse prestazioni di macchine dedicate più complesse ,alta integrazione e costo irrisorio grazie agli alti volumi di vendita che ripagano la parte full custom del progetto.

Inoltre ti sei risposto da solo:come vedi processori del genere sono eccelsi per alcune tipologie di utilizzi tra cui appunto la FFT che sfrutta non solo il calcolo vettoriale ma anche le molteplici modalità d'indirizzamento tipiche dei DSP.
Ed infatti è di molto più veloce perchè con i DSP in un'unica istruzione(la MAC) posso dire di fare il prodotto di die vettori e fare la somma con un altro..in questo modo mi calcolo appunto la trasformata di Fourier con tante istruzioni quanti sono gli integrali del dominio..mentre con un processore normale dovcrei spenderene almeno 5 per ogni integrale.

[erick81]

Originariamente inviato da nanu10

erick81 vorrei proprio sapere che computer hai, e se hai mai provato un ibook... guarda io prima di comprare il mac, questo inverno, mi ero assemblato un bel athlon 2500+ barton portato a 3200+ con abit nf7s e 512 mb ram, certo ora se lo confrontiamo con un athlon 64 non c'è paragone, ma non penso che sia cmq meno potente di qualsiasi pentium M ora in commercio e se lo è, lo è cmq di poco, bene il mio ibook non me lo ha mai fatto rimpiangere, pur essendo basato su un G4 "obsoleto", tutto questo per dirti che conta "l'esperienza" di uso, e quella del mio ibook con G4 è superiore forse a quella di qualsiasi portatile basato su pentium M con centrino che monta Windows XP poi... de gustibus

http://www.x86-secret.com/articles/c...n/dothan-5.htm

Il Pentium M Dothan (Sonoma per alcuni scienziati), clock for clock, è molto simile ad un Athlon 64 FX (1 MB L2 cache, DC MCH), che, a sua volta, è molto simile all'Opteron, che, a sua volta, clock for clock, svernicia in svariate applicazioni un G5 (OS X su G5 e Win su X86), per cui...

[nanu10]

Originariamente inviato da erick81

http://www.x86-secret.com/articles/c...n/dothan-5.htm

Il Pentium M Dothan (Sonoma per alcuni scienziati), clock for clock, è molto simile ad un Athlon 64 FX (1 MB L2 cache, DC MCH), che, a sua volta, è molto simile all'Opteron, che, a sua volta, clock for clock, svernicia in svariate applicazioni un G5 (OS X su G5 e Win su X86), per cui...

ma questo non l'ho mai messo in dubbio... il mio discorso era un altro...

[erick81]

Originariamente inviato da nanu10

ma questo non l'ho mai messo in dubbio... il mio discorso era un altro...

Scusa, ma non stavamo parlando di prestazioni G4 vs Dothan?

Ciao

P.S. Comunque, ovviamente, al di là delle prestazioni, de gustibus!

[nanu10]

Originariamente inviato da erick81

Scusa, ma non stavamo parlando di prestazioni G4 vs Dothan?

Ciao

P.S. Comunque, ovviamente, al di là delle prestazioni, de gustibus!

mi fa piacere che ora ci siamo capiti!

[ugluck]

rimane il fatto che il vaio con Centrino (1,7) renda esattamente allo stesso modo o in alcuni casi pegigo del mio ibook gc a 1 ghz, a questo punto mi sembra di non poter credere alla maggior parte dei bench pubblicati in giro, oltrettutto PPC e Pentium non sono abbastanza simili per poterli confrontare mettendoli sullo stesso piano, l'unica è usarli per un po' e vedere chi va più forte nell'uso comune e con i loro rispettivi S.O. In questo caso g4 non è assolutamente inferiore a centrino, anzi. Aggiungerei che costa meno.

[erick81]

Originariamente inviato da ugluck

rimane il fatto che il vaio con Centrino (1,7) renda esattamente allo stesso modo o in alcuni casi pegigo del mio ibook gc a 1 ghz, a questo punto mi sembra di non poter credere alla maggior parte dei bench pubblicati in giro, oltrettutto PPC e Pentium non sono abbastanza simili per poterli confrontare mettendoli sullo stesso piano, l'unica è usarli per un po' e vedere chi va più forte nell'uso comune e con i loro rispettivi S.O. In questo caso g4 non è assolutamente inferiore a centrino, anzi. Aggiungerei che costa meno.

Che problema c'è per fare un bench, anche tra architetture e SO differenti?Si lancia un'applicazione comune e si misura il tempo impiegato per portarla a termine.

http://www.mediaworkstation.com/arti...jsp?id=25633-1

Visto che, semplificando, Opteron ha all'incirca le stesse prestazioni di Dothan, clock for clock...

Se vuoi un'analisi molto scientifica, su G5 ed OS X:

http://www.anandtech.com/mac/showdoc.aspx?i=2436

In fatto di bench, poi, Apple di taroccature ne sa qualcosa, vedi quelli certificati da Veritest, poi risultati una sola!

Lo stesso Jobs, tempo fa, si prendeva gioco dei P4, mentre adesso si scopre che un Prescott a 3,6 GHz (devkit) è più veloce di un G5 2,0 GHz DP...

[Criceto]

Originariamente inviato da erick81

Se vuoi un'analisi molto scientifica, su G5 ed OS X:

http://www.anandtech.com/mac/showdoc.aspx?i=2436

Non è scientifica per niente. Anzi è fatta molto male. Per le spiegazioni leggiti il forum a riguardo sullo stesso sito.

[erick81]

Originariamente inviato da Criceto

Non è scientifica per niente. Anzi è fatta molto male. Per le spiegazioni leggiti il forum a riguardo sullo stesso sito.

In che senso non la consideri affidabile?Anyway, l'altro link postato riguarda applicazioni reali.

[erick81]

P.S. Questi sembrano fatti bene, anche se ci si allontana dall'utilizzo reale (si consideri che vengono utilizzati G5 a 2500 MHz vs Opteron a 2000 MHz):

http://www.gromacs.org/benchmarks/single.php

[Criceto]

Originariamente inviato da erick81

P.S. Questi sembrano fatti bene, anche se ci si allontana dall'utilizzo reale (si consideri che vengono utilizzati G5 a 2500 MHz vs Opteron a 2000 MHz):

http://www.gromacs.org/benchmarks/single.php

Nessuno nega che gli ultimi Opteron e P4 siano degli ottimi processori e nella maggior parte dei casi siano più veloci dei G5, ma i test con MySQL e processi su Anandtech sono pesantemente fallati ma pare che vengano riportati solo quelli, ormai...

[erick81]

Originariamente inviato da Criceto

Nessuno nega che gli ultimi Opteron e P4 siano degli ottimi processori e nella maggior parte dei casi siano più veloci dei G5, ma i test con MySQL e processi su Anandtech sono pesantemente fallati ma pare che vengano riportati solo quelli, ormai...

Beh, i test server-oriented sono talmente a sfavore del G5 che il dubbio viene per forza!

Ciao

[zani83]

non è solo questione di potenza....
il mac si è tuffato nel palladium!!!ma il palladium non è solo "software"...si lega parecchio all'hardware quindi per un sistema mac quale processore migliore se non l'intel PENTIUM...tra poco palladium-ready?!
mentre è noto a tutti che IBM è molto più propensa allo sviluppo e alla libera circolazione delle idee, del software e tutto il resto....quindi probabilmente IBM non voleva integrare il PALLADIUM nei propri chip...
o almeno questa può essere una delle concause del passaggio della apple...
cmq leggete:
http://jack.logicalsystems.it/homepa.../Palladium.asp

[alessandrobraione]

Originariamente inviato da zani83

non è solo questione di potenza....
il mac si è tuffato nel palladium!!!ma il palladium non è solo "software"...si lega parecchio all'hardware quindi per un sistema mac quale processore migliore se non l'intel PENTIUM...tra poco palladium-ready?!
mentre è noto a tutti che IBM è molto più propensa allo sviluppo e alla libera circolazione delle idee, del software e tutto il resto....quindi probabilmente IBM non voleva integrare il PALLADIUM nei propri chip...
o almeno questa può essere una delle concause del passaggio della apple...
cmq leggete:
http://jack.logicalsystems.it/homepa.../Palladium.asp

Scusate se mi inserisco da "non-Apple maniac".
Anche questo conferma che siete un po' fondamentalisti.
Se Apple è dio e Job il suo profeta non vedete che, come il Diavolo Gates sono entrambi americani, cioè "il business prima di tutto".
Qualità del software ed hardware a parte, parlando solo dal punto di vista industriale (la Apple era nata per fare beneficienza o regali al mondo?), Apple non ha sfondato a suo tempo perchè il gran capo non aveva concesso la libertà che il più astuto Gates aveva dato ai produttori, e qesto non perchè "think different" ma perchè era più squalo di Gates, solo che ha scelto la strada sbagliata.
Che poi questo stramultimiliardario venga paragonato ad una specie di benefattore incompreso dell'Umanità mi sembra troppo, se parlate del creatore di LINUX quello sì che "thinks different".
Vi saluto cordialmente tutti anche se so già che incorrerò nella fatwa -o scomunica- dei più estremisti.

[Criceto]

Originariamente inviato da erick81

Beh, i test server-oriented sono talmente a sfavore del G5 che il dubbio viene per forza!

Non ti credere. Nei test con pagine statiche con Apache, l'Xserve vince pure nei test delle riviste per PC. Forse sono i test di Anandtech che sono fallati...

-----------------

This article is wrong all along!!!
By Anonymous (IP: 133.87.1.---) on 2005-09-03 06:27:24 UTC
I think that this article is full of mistakes that are done by purpose (i dont know, maybe!!) or are due to the misunderstanding of those guys about many computing ideas and principles. I really think that such articles that claim to be informative should not be allowed to be on internet as it is simply saying wrong things.

My big concern about their tests is that they are not fair and they never tend yo be fair to the apple side and osx. For example i believe that everyone who pretend to make precise testing should realize that if they got results that differ so much and are so unexplained, well the best thing is to try different testing methods and tools. So tools may work well for a given platform, others may not work well. So any tempt to highlight any os design flaw should be done after testing many different benchmarking tools. They don't do that, instead they try to find some reasons that are completely meaningless in the sense that they are saying things that are technically wrong. Trying to find such whatever threading problems in osx in order to hurt the platform is not really fair......

So to begin with, let me comment on the Apache results. Well they use Apachebench to test osx, and they get rather low request per second with osx. Well ok, but why don't they try something else to test Apache performance, in that case they could figure out that the problem is either the os or the benchmarking tool (they recognize themself that apple did tell them that thre is a bug in ApacheServer, while running it on osx, maybe? i did not test it).

Try to run WebBench on osx and linux ppc or x86, and have a look to the results. Well WebBench is a largely accepted benchmarking tool for test Apache performance, so it make sense to use it too. pcmag.com have tested a Xserve G5,

http://www.pcmag.com/article2/0,1895,1630329,00.asp,

and their result show something like almost 8000 request per second for 60 clients for a static configuration test.

Ohhhh!!!! What's going on here? What we have here is something completely different, a completely different image compared to their results. What does this tell us? Well two different bench tools can produce very different outputs. But moreover everything that follows in their article simply collapse because nothing tell us that the tools that they use for MySQL testing are not having a problem too. Moreover WebBench involve as weel many threads creation, so their theory about this threading problem of osx collpase too.

We simply dont get any global image of osx performance in server applications with their limited set of bench tools. Did they never think that the problem of those results could come from the benchmarking tools or the app itself that may have performance problems while running on osx.

Here is the comment of pcmag.com

"Performance-wise, the dual-processor Xserve G5 compares well with Linux-based x86 servers. This is not surprising, considering that Mac OS 10.x is based on FreeBSD UNIX. Using the included Apache server, we ran the Xserve G5 through our standard WebBench tests. It did quite well on the static WebBench test, outperforming a competitor's dual processor x86-64 server running Apache server on SuSe Linux-64."

Something rather different to their general statement, isn't it?

So now about MySQL. So first they mention fsync(). Let me correct. What are they talking about is wrong?, fsync() behaves the same as it does on all unixes: it writes the data from the host to the drive. However this is not good enough because drives will buffer the data and potentially write it in a different order than the app did.
To deal with this, MacOS X provides an fcntl() called F_FULLFSYNC which does what fsync does and in addition asks the drive to flush all buffered data to disk. This is the only way for an app to be able to make any guarantees about things like transactions which is why InnoDB in MySQL uses it! And i think that because its an os feature it works whenever you use MyISAM or not.

And i don't understand why their benchmark should lower the pressure on the disk. A database app like MySQl has to write and read data on disk while running, so what they are saying is simply wrong.

to be continued....
1 Reply Reply Score: 0

This article is wrong all along!!!
By Anonymous (IP: 133.87.1.---) on 2005-09-03 06:30:32 UTC
Lets now talk about their insane theory about threading in osx. Here is their statement

"Readers pointed out that there were two errors in this sentence. The first one is that Mac OS X does use kernelthreads, and this is completely true. My confusion came from the fact that FreeBSD 4.x and older – which was part of the OS X kernel until Tiger came along - did not implement kernelthreads; rather, only userthreads. It was one of the reasons why MySQL ran badly on FreeBSD 4.x and older. In the case of userthreads, it is not the kernel that manages the threads, but an application running on top of the kernel in userspace. "

What does it mean this? What does it mean that os x prior to Tiger did not implement kernel threads, my God! what are they saying, they should just go and take some os design course.

Kernel threads are of course in previous version of osx and in Freebsd. Mach itself implements a multithreaded VM layer for example, and anyway i mean, every thread that access the kernel runs in the kernel. An app that makes files IO or network task has one of its threads dealing with that which enter in the kernel space and runs in the kernel until it resumes. So i dont really understand what does it mean to say that and what is their aim to say that osx did not have kernel threads. I think they seem to confuse kernel thread and fine grained locking.

When a thread enters the kernel, it shares the same memory space as the entire kernel itself as well as any other interrupts which run in the bottom half of the kernel (kenel thread are said to run on the top half). So os designers had to implement many technics (i don't really enter in the details here) to protect the data being manipulated by the kernel. One of them and still partially used by FreeBSD was a giant lock which protects the kernel of any threads which wish to enter inside its memeory space. Actually Giant Lock was implemented to protect the kernel space particularly in case of multiprocessor machines where the principle of not preemptable kernel was not enough anymore to protect the kernel in such hardware. OS X before Tiger used something similar to the Giant Lock although not identical. Os x implements funnels that serialize the access to the Bsd portion of the kernel.

Funnels are built on top of Mach mutexes, and are used simply because Mach is thread safe, the bsd protion was not, they needed something to serialize both of them. Funnels are sleeps locks, and each funnel backs to into a mutex, and one a thread gains a funnel is is holding that funnel while is executing. The difference between a funnel and a mutex is that a mutex is hold across rescheduling.

There were a funnel for the file system and one for everything else, mainly the network code. In Tiger the funnels are gone and the BSD portion of the kernel implements now fine grained locking in order that SEVERAL threads can exist in the kernel at the same time. So they confuse both ideas, of course kernel threads did exist prior to Tiger otherwise the system can not do any file system or network operation. What Tiger does is that it allow better scaling for multiple processors architecture for threads that run in the kernel space (this scaling requirement did not concern threads that runs in the user space) with fine grained locking. Right now the the network stack and the file system in the BDS portion in Tiger are thread safe.

"In the case of userthreads, it is not the kernel that manages the threads, but an application running on top of the kernel in userspace. "

That's not true, many os today offers a 1:1 mapping for executing the threads whatever they are. So any threads including user or kernel thread are managed by the kernel. What a hell is this app running on top of the kernel in the user space? Thats simply dont make sense.....

Now lets come to their process and thread theory.

"However, it is important to understand that threads and processes are not completely different, but they are related to each other. In the case of Linux, creating a thread is very similar to creating a process. In fact, you use the same procedure, only with different flags or parameters. Linux implements all threads as if they were standard processes. You create a new thread with the clone() call, and the necessary flags, which describe the resources (memory) to be shared. The process creation is done with fork(). But fork() is nothing else than a clone() without the flags that describe the resources that must be shared. So, if you test fork() on Linux, you also get a rough idea of how fast threads are created.

What about Mac OS X? Well, when the Mach kernel is asked to create a Unix process (fork()), the mach kernel creates a task (which describes the resources available) and one thread. So, thread creation time is included in the fork () benchmark of Lmbench. "

That's not true at all. An os calls fork() for creating process (or Task), right! An application is also a process, actually it is a the child of a parent process which is launched when logging in.

A thread, right! ,shares the same address space as the process that launch it and share the same address space as the another threads launched by the same application. But what Lmbench measures is process creation not thread creation.

Thats not the same thing ,creating a process and a thread are two different things. The first one is created by the os, the second is created by an application with a system call, and why are they talking about clone() to create threads, that does not happen like this in osx. Yes Mach creates a process if it is asked to do so, and one thread belonging to this process. But after that any new threads is created by the app, not by the os. When MySQL runs, it creates threads, right, but the latency or performance hit that they are talking about can not be measured by Lmbench as MySQL creates threads and this tools measures process creation.

to be continued....
0 Replies Reply Score: 0

This article is wrong all along!!!
By Anonymous (IP: 133.87.1.---) on 2005-09-03 06:31:38 UTC
How can they measure anything about any thread problem in osx running this tool that does not tell anything about what they are talking about. They try to explain an obscur relation between thread and process, but they completely miss the point.....they just dont understand how it works....

Threads are not sequential flow control within a program (what does it it anyway to say that!!!!), they are lightweight peace of code that are time-sliced by the kernel. Advice too them: Take a book about threads, and read it.....

"And although MySQL is only one process, it must cooperate with other process via IPC. "

Which over process is this. Any other process means an application or any other os proccess. Which one are they talking about? why to measure IPC in case of MySQL? Generally, their test about IPC and signaling are completely meaningless, because i really dont understand what they try to measure and besides that fact that they try to confirm a theory about threads in osx that comes mainly from their imagination and misunderstood.

"
relatively high TCP Latency that we measured
the implementation of the threading system. Does the pthread to Mach threads mapping involve some overhead? Or is this the result of the traditional performance problem of the micro kernel, namely the high latency of such a kernel on system calls? While Mac Os X is not a micro-kernel, the problem might still exist as the Mach core is deep inside that kernel. Is there IPC overhead? Lmbench signaling benchmarks seem to suggest that there is.
the finer grained locking in the current version of Tiger that is not working for some reason and we still have the “two lock” system of Panther.
"

Everything that comes from theitr Lmbench seems not to give trustable results about performance on ox. A given benchmarking tool can give you very untrustable results, see the apache test too.

God damm!!!! there is no thread mapping overhead why should there be? Osx use a 1;1 model for every thread, user or kernel space maps directly to Mach without any overhead. Or do they try to find any reasons even it does not make sense..... There is not high latency on system calls in osx, they just try to convince themself about it to support their ridiculous theory that simply comes from bad testing. Darwin is not a micro-kernel, xnu is monolithic. BSD does not run as a servie on top of Mach as i could also read in this forum.

And PLEASE dont say that i am wrong or that you know better than me. I am a damm Darwin coder......

Since macos x was not intended to work as a multi-server. and a crash of the BSD server was equivalent to a system crash from a user perspective, the advantage of protecting Mach from BSD were negligible. Rather than simple collocation, message passing was short circuited by having BSD DIRECTLY call Mach functions. The abstractions are maintained within the kernel at the source level, but the kernel is in fact monolithic. Saying that the problem might still exist as the Mach core is deep inside the kernel is simply meaningless, what does mean this? Again they just try to find stupid argument that have no technical meaning and proof. Their Lmbench simply seems to give bad results on osx, or whatever reasons, but right now nothing can alllow them to say such things with a single test.

Moreover some people seems to confuse where threads are handled in osx. Threads has to run, right? They have to get ressource to run (cpu ressource), so they are time-sliced by the kenel. Some people seem to think that it is the bsd portion of xnu that manages threads, not at all. Everything comes to the Mach portion of xnu where the threading management code is. Any call to a Cocoa, or a Carbon multhreading API, or any call to the Posix threads API which belongs to the BSD code mapps directly to Mach. Osx offers diffrent way for the programmer to create a thread, and to deal with them, but at the end everything is managed by Mach.

The fine grained locking is working in Tiger. The test that they did do not show anything about whether its working or not. Nothing can allow them again to say such stupid things. The funnels in Tiger are gone, believe it or not thats not my problem, but please i cant support that they try to make believe people about such wrong statement.

You may say me now that i just talk about the bads point of the bench that they did, and i just forget the rather good results done by the G5 with flops test. Well the same comment can be done, they are unfair because you take a very old floating point performance bench tool that is more suitable for x86 chips than for G5. Look at the code of flops, there is a lot of to do in the code to optimize it like unrolling the loops for better parallelism. You may say that the code is not optimized for x86 either, yes but it runs better on those chips as it is now than on G5. And why a hell they use such poor testing for floating point performance, why not using Linpack much more suitable for such task. So their conclusion about floating point performance on G5 compared to x86 is simply not true. Any reasonnable testing of floating point performance can not be done with a such limited tool like flops, its ridiculous.... Each G5 is capable of a fused, multiple-add operation per cycle, so you get 2 flops per cycle. This means that 2GHz corresponds to 8 GFlops, so each dual 2.0 GHZ G5 can deliver a peak of 16 GFlops of double-precision performance. An Opteron gives you 4 GFlops at 2.0 ghz. This does not correspond very well to their "as good as x86" statement, does it?

Well, well a lot of things isn't? I mean their text is so full of mistakes of any kinds mainly due to their poor understanding about os design and computer principles in general, and they come up with such interpretations that are so wrong.....

to be continued.....
0 Replies Reply Score: 0

This article is wrong all along!!!
By Anonymous (IP: 133.87.1.---) on 2005-09-03 06:32:12 UTC
And why dont they use Xserves for servers benchmarking. I mean, just forget about the osx/linux comparison and focus on the hardware comparison in server applications. The powermac is a not a server and it not designed as a server. that means that it is not designed to run server applications effectively. A power mac has an ethernet controler, which is directly connected to the I/O controler K2. This K2 controler manages every other I/O operations (except the PCI-X slots) like disk out and input, etc.... What does it mean is that the networking flow of data has to share the bus with I/O disk data with is a major and very important bottleneck in aplications like data base as they perform a lot of network and disk operations.

Network operation has then to share a 1.6 GBps bus from the K2 to the PCI-X bridge with everything else. And yet data has to go until the northbridge before to be put in memory or to be computed the cpu. Well this design is good for any desktop worstation, because this kind of machine don't deal with server network performance bounded applications. Now look at the Xserve. The Xserve has first a dedicated Ethernet ASIC controller, the powermac not. This ASIC provides many network tasks optmizations, like hardware-generated TCP, IP, and UDP checksum to detect packet corruption and transmission errors, 802.1q VLAN (Virtual LAN) tags let you group systems on different physical LANs and provide discrete services to them — as if they were on separate, physical LANs and a 64KB buffer supports jumbo frames, or packets up to 9KB, to reduce system overhead and increase throughput of all network activities.

Quiet a lot of things, isn't? Moreover the advanced ASIC includes two independent 10/100/1000BASE-T Ethernet interfaces, each with its own interrupt, on a dedicated 64-bit, 133MHz PCI-X bus. The Ethernet controler is linked directly to the PCI-X bridge which communicates at 4.8 GBps to the controler system. This makes a huge diffrence in networking performance, because the ethernet interface can communicate very quickly with the rest of the system in order that data can be processed much faster than a powermac. Thats a server design. Apple dont sell the Xserve just for fun.... And the amazing thing is that they talk about "The Xserve Server Platform", but they dont test the Xserve at all, something is wrong here!!!! Now i guess that they were saying in their first article that it was more fair to use a powermac than a Xserve for comparison with x86 boxes because the powermac shipped with a G5 that have higher frequencies. They totally missed the point, the performance of a server platform depends fisrt on how it is optimized to handle network communication.

I am sure that they wont, but i asked them to remove this article because it has so many mistakes, misunderstandings, etc, .... that any reader will misunderstand their statement, and Os X. Thats really insane and maybe dangerous to publish such articles which their content relies on people that do not understand everything about what they are writing.

Its really funny to see some small boys with still some acne on their face who think that they can teach you computers and computing, how it works and so on.....because they got a bunch of computers in a classroom.
This is just crap........

Have a nice day......

Hakime.

[Criceto]

Originariamente inviato da zani83

non è solo questione di potenza....
il mac si è tuffato nel palladium!!!ma il palladium non è solo "software"...si lega parecchio all'hardware quindi per un sistema mac quale processore migliore se non l'intel PENTIUM...tra poco palladium-ready?!
mentre è noto a tutti che IBM è molto più propensa allo sviluppo e alla libera circolazione delle idee, del software e tutto il resto....quindi probabilmente IBM non voleva integrare il PALLADIUM nei propri chip...
o almeno questa può essere una delle concause del passaggio della apple...
cmq leggete:
http://jack.logicalsystems.it/homepa.../Palladium.asp

Palladium è un parola grossa...
Quel chip sui MacTel per sviluppatori si comporta nè più nè meno come un "dongle" di una protezione hardware. E infatti è stato bypassato senza particolari difficoltà come le altre protezioni hardware...

In effetti non capisco perchè fare la fatica di mettere una protezione hardware: concettualmente craccare una prot. hardware o una software è equivalente...

[Mauna Kea]

Originariamente inviato da Criceto

Palladium è un parola grossa...
Quel chip sui MacTel per sviluppatori si comporta nè più nè meno come un "dongle" di una protezione hardware. E infatti è stato bypassato senza particolari difficoltà come le altre protezioni hardware...

In effetti non capisco perchè fare la fatica di mettere una protezione hardware: concettualmente craccare una prot. hardware o una software è equivalente...

io più di tanto non mi preoccupo..
se in Matrix la resistenza ingannava il Programma,
figurati quanto ci mette un napoletano con la sua fantasia a ingannare palladium

Bye