Can you better state things? I am not sure I follow you.
HD access? What do you mean by CPU? (core, dual core package, etc.)
For example in the case of the dual core Opteron the two cores share the same memory controller and buses to main memory. The amount of memory attachable to those buses is determined by the capabilities of the memory subsystem outside of the CPU package and the single onboard memory controller. In other words it being dual core hasn't affected, in a positive, fashion the amount of memory supported or memory bandwidth.
What it likely does help with is cache synchronization since that can take place on die via the crossbar switch (at least ideally).
In the case of the Power5 (another dual core CPU) it also shares a single memory controller but it has an integrated cache hierarchy on die (not to mention a huge amount of L3 and L2 cache) that sits in front of the system interconnect. This allows the cores to share a much larger pool of cache, avoiding aspects of cache synchronization (at least at some levels).
Dual core (multi-core) dies are often larger then their single core siblings (not always depending on how the do single core version) and this gives you a larger surface area to thermally bond with as well as spreads out heat production. This can make it easier to cool even if it puts out more heat.
Well I am not an expert on the latest AMD stuff (of course they had the two core design in mind from the beginning of the Opteron) but from what I have seen the two dies in the Opteron interface with a common crossbar switch (the each have an independent L2 cache so no real unification at that level).
So they are not interconnected via HT on die but by some cross bar interconnect that presumably allows some level of concurrent point-to-point (core to core , core to HT link, core to memory, etc.) transfers and at high clock/data rates.
Look at the Power5 which is a combination of dual core dies integrated in a multichip package. It provides for L3 to L3 sharing as well as ring style interconnect I believe.
Not exactly what you are talking about but close... of course the cell processor is closer to what you would likely get on a single die at this time given feature sizes and heat issues.
One example... dual core (true dual core) CPU have the ability to exchange data between the cores at faster rates and more importantly with less latency then when having to exchange data between CPUs on a dual CPU system. This can improve SMP flow.
Another example... good dual core implementations will utilize some form of cache unification to allow better bulk sharing of data between cores while still allow high-levels of independent cache activity (the IBM's Power5 is a good example of this).
The Tiger FAQ found at the Apple online store answers this question, among others.
From a link on the FAQ...
Tiger ships on a DVD, but if your Mac doesn't have a built-in DVD-ROM player, you'll need CD media. When you buy Mac OS X Tiger, you qualify to purchase Tiger CDs for only $9.95. and you fill out this form (PDF).
(personally a little surprise Apple isn't eating the cost for pacakging and shipping the CD version to those that request it, basically what the 9.95 mostly represents)
64 bit address is NOT the only benefit to the G5... you get 64 bit general logic and integer math which software since Mac OS X 10.2.8 had the ability to utilize (Mac OS X 10.3 say several OS provided libraries and framwork recompiled/optimized to use 64 bit math as it made sense, speeding up several classes of applications).
Also as of Mac OS X 10.2.8 the system could fully leverage greater then 4 GB of physical RAM for use in the virtual memory pool (and of course UBC).
Tiger adds the ability to use 64 bit addressing for software linked against libSystem, which is just about any POSIX only sofware (command line).
I don't have a single problem running 64bit KDE on my AMD64 laptop. No silly restrictions and message passing required, plus your 64bit apps get a decent speed boost over their 32bit counterparts.
Your 64 bit KDE does the same "silly... message passing..." and that silly stuff allows developers to actually get software out to you in a timely fashion (abstractions, API, OOP, etc.).
In the case of AMD64 and Intels clone the architecture gains new capabilities beyond just 64 bit integer math and addressing support. For example it gains additional registers that programmers can use. This results in the ability of 64 bit applications on AMD64 to actually run faster then a 32 bit equvalent (focus on just 64 bit pointers).
In the case of PPC the architecture was designed from the start to support 64 bit and it always has had 4x the usable registers as x86 architecture and I believe close 2x what AMD64 supports.
So the side benefit that you see with AMD64 doesn't take place with PPC since PPC already had it. The means that switching an application to 64 bit on PPC can actually degrade its performance since you have no side benefits coming into play to offset the loss do to having to pass around pointers twice as large (focusing on 64 bit pointers here because as of the G5/PPC970 Mac OS X application have been able to use 64 general and integer math, the later aspect of the G5 can greatly increase performance of some classes of application).
Seeing people getting all excited at the thought of buying yet another yearly remake of the same OS is, well, a bit strange.
1) I wouldn't call it a remake... you get new features and capabilities (for both users and developers) more often then the 4-5+ year cycle seen on the Windows side and in a single package. I personally like this.
2) It isn't yearly by any means and in fact Apple has said now that Mac OS X has matured (said around the time of 10.3 release) that major revisions will come less frequently then before (hinted to 18+ month cycle), Tiger is an example of that.
10.0 (Cheetah) released March 24th 2001 10.1 (Puma) released September 29th 2001 (free upgrade) 10.2 (Jaguar) released August 13th 2002 10.3 (Panther) released October 24th 2003 10.4 (Tiger) not released as of March 30th 2005 (possibly in April but all but assured before end of July)
(see Unix History for dates, including the free minor releases to Mac OS X)
Unless the new version is absolutely needed to run some application, most of us couldn't care less about it.
Which is likely true for many Mac OS X users as well...
So, pray tell, just for my curiosity: _what_ applications didn't work with the old release?
What do you mean? If the application existed on Mac OS X before Tiger then it must have worked on some release of Mac OS X and if so the existence of Tiger won't make it magically break.
Is there some much needed functionality comes in this release and was sorely missing in Panther? I'm just, you know, curious.
Need depends on the user/developer so no one can answer that for you... review Apple's Mac OS X user page (click across the "tour" items) and developer page to understand some of what is new in Tiger.
It looks like Apple has pulled the 4.1.0 disk image from the FTP site. I believe it has been up on site for a couple of days (the file modification date is the 8th).
I downloaded version 4.1.0 earlier today, around 10:00 AM PST before it was pulled.
So it looks like Apple is attempting to correct this (of course I have seen a few reports about 4.1.0 causing problems so they may have pulled it for that).
You have to do a click-through NDA just to get the -current- version ( 4.0.1 ) of the CHUD tools, I don't want to think about where this guy got his clearly pre-release copy of CHUD 4.1.0
Um no CHUD tools are not under NDA... it is a freely and publicly available tool from Apple's developer site.
Slashdot Mirror
Also interesting is how Hyatt says "Safari", not "Webkit", not even "Webcore", and no "KHTML" either.
p / render_block.cpph tml/rendering/render_table.cppc pp
If you click the patch links he provides you find the following files have been modified and provided to the public...
The following are packaged in Apple's framework called WebCore.
khtml/html/html_headimpl.cpp
khtml/html/dtd.cp
khtml/rendering/render_box.cpp
khtml/rendering
khtml/html/htmltokenizer.cpp
k
khtml/khtml_part.
The following is part of KWQ which is used to bridge from KHTML to Cocoa and this is part of WebCore (Apple specific item but still public).
kwq/KWQPainter.mm
Mr. Binks in every episode, sweet!
Opens and views fine in Safari (v1.3).
The drive head is only flying a few hundred molecules above the drive surface.
;-)
Are we talking water or beta-galactosidase molecules here?
They likely could careless about the "grunt" (some political PR concerns) but cared much more about the capsule falling into US hands.
Can you better state things? I am not sure I follow you.
HD access? What do you mean by CPU? (core, dual core package, etc.)
For example in the case of the dual core Opteron the two cores share the same memory controller and buses to main memory. The amount of memory attachable to those buses is determined by the capabilities of the memory subsystem outside of the CPU package and the single onboard memory controller. In other words it being dual core hasn't affected, in a positive, fashion the amount of memory supported or memory bandwidth.
What it likely does help with is cache synchronization since that can take place on die via the crossbar switch (at least ideally).
In the case of the Power5 (another dual core CPU) it also shares a single memory controller but it has an integrated cache hierarchy on die (not to mention a huge amount of L3 and L2 cache) that sits in front of the system interconnect. This allows the cores to share a much larger pool of cache, avoiding aspects of cache synchronization (at least at some levels).
Yes and no... it depends basically.
Dual core (multi-core) dies are often larger then their single core siblings (not always depending on how the do single core version) and this gives you a larger surface area to thermally bond with as well as spreads out heat production. This can make it easier to cool even if it puts out more heat.
Well I am not an expert on the latest AMD stuff (of course they had the two core design in mind from the beginning of the Opteron) but from what I have seen the two dies in the Opteron interface with a common crossbar switch (the each have an independent L2 cache so no real unification at that level).
... or in a nice pdf
So they are not interconnected via HT on die but by some cross bar interconnect that presumably allows some level of concurrent point-to-point (core to core , core to HT link, core to memory, etc.) transfers and at high clock/data rates.
see this diagram
Look at the Power5 which is a combination of dual core dies integrated in a multichip package. It provides for L3 to L3 sharing as well as ring style interconnect I believe.
Amazingly the following is the best info I could find that isn't private...
IBM's POWER5 Chip with 8 cores and 144MB cache showcased
Not exactly what you are talking about but close... of course the cell processor is closer to what you would likely get on a single die at this time given feature sizes and heat issues.
Yes.
One example... dual core (true dual core) CPU have the ability to exchange data between the cores at faster rates and more importantly with less latency then when having to exchange data between CPUs on a dual CPU system. This can improve SMP flow.
Another example... good dual core implementations will utilize some form of cache unification to allow better bulk sharing of data between cores while still allow high-levels of independent cache activity (the IBM's Power5 is a good example of this).
You will likely be better served if you just use a solid state disk for this.
This existed in Panther and functioned decently well, it is getting refinement for Tiger of course.
The Tiger FAQ found at the Apple online store answers this question, among others.
From a link on the FAQ...
Tiger ships on a DVD, but if your Mac doesn't have a built-in DVD-ROM player, you'll need CD media. When you buy Mac OS X Tiger, you qualify to purchase Tiger CDs for only $9.95. and you fill out this form (PDF).
(personally a little surprise Apple isn't eating the cost for pacakging and shipping the CD version to those that request it, basically what the 9.95 mostly represents)
To be fair you have at least three levels here with two that could be considered "accelerated" depending on defintion/context...
1) Standard integer/floating point using CPU.
2) SIMD integer/floating point(AltiVec) using CPU.
3) GPU pixel shaders, etc.
Wow I must have made it "big-time" and didn't even know it.
for instance, Java programs can share packages/code with each other
Apple did this long ago, it existed in Mac OS X 10.2 in not earlier.
Consider looking up the definition of sarcasim :-)
64 bit address is NOT the only benefit to the G5 ... you get 64 bit general logic and integer math which software since Mac OS X 10.2.8 had the ability to utilize (Mac OS X 10.3 say several OS provided libraries and framwork recompiled/optimized to use 64 bit math as it made sense, speeding up several classes of applications).
Also as of Mac OS X 10.2.8 the system could fully leverage greater then 4 GB of physical RAM for use in the virtual memory pool (and of course UBC).
Tiger adds the ability to use 64 bit addressing for software linked against libSystem, which is just about any POSIX only sofware (command line).
I don't have a single problem running 64bit KDE on my AMD64 laptop. No silly restrictions and message passing required, plus your 64bit apps get a decent speed boost over their 32bit counterparts.
... message passing..." and that silly stuff allows developers to actually get software out to you in a timely fashion (abstractions, API, OOP, etc.).
Your 64 bit KDE does the same "silly
In the case of AMD64 and Intels clone the architecture gains new capabilities beyond just 64 bit integer math and addressing support. For example it gains additional registers that programmers can use. This results in the ability of 64 bit applications on AMD64 to actually run faster then a 32 bit equvalent (focus on just 64 bit pointers).
In the case of PPC the architecture was designed from the start to support 64 bit and it always has had 4x the usable registers as x86 architecture and I believe close 2x what AMD64 supports.
So the side benefit that you see with AMD64 doesn't take place with PPC since PPC already had it. The means that switching an application to 64 bit on PPC can actually degrade its performance since you have no side benefits coming into play to offset the loss do to having to pass around pointers twice as large (focusing on 64 bit pointers here because as of the G5/PPC970 Mac OS X application have been able to use 64 general and integer math, the later aspect of the G5 can greatly increase performance of some classes of application).
You may want to learn more about the concept not only personal but professional ethics... which are not legal based.
iPod socks
Seeing people getting all excited at the thought of buying yet another yearly remake of the same OS is, well, a bit strange.
1) I wouldn't call it a remake... you get new features and capabilities (for both users and developers) more often then the 4-5+ year cycle seen on the Windows side and in a single package. I personally like this.
2) It isn't yearly by any means and in fact Apple has said now that Mac OS X has matured (said around the time of 10.3 release) that major revisions will come less frequently then before (hinted to 18+ month cycle), Tiger is an example of that.
10.0 (Cheetah) released March 24th 2001
10.1 (Puma) released September 29th 2001 (free upgrade)
10.2 (Jaguar) released August 13th 2002
10.3 (Panther) released October 24th 2003
10.4 (Tiger) not released as of March 30th 2005 (possibly in April but all but assured before end of July)
(see Unix History for dates, including the free minor releases to Mac OS X)
Unless the new version is absolutely needed to run some application, most of us couldn't care less about it.
Which is likely true for many Mac OS X users as well...
So, pray tell, just for my curiosity: _what_ applications didn't work with the old release?
What do you mean? If the application existed on Mac OS X before Tiger then it must have worked on some release of Mac OS X and if so the existence of Tiger won't make it magically break.
Is there some much needed functionality comes in this release and was sorely missing in Panther? I'm just, you know, curious.
Need depends on the user/developer so no one can answer that for you... review Apple's Mac OS X user page (click across the "tour" items) and developer page to understand some of what is new in Tiger.
It looks like Apple has pulled the 4.1.0 disk image from the FTP site. I believe it has been up on site for a couple of days (the file modification date is the 8th).
I downloaded version 4.1.0 earlier today, around 10:00 AM PST before it was pulled.
So it looks like Apple is attempting to correct this (of course I have seen a few reports about 4.1.0 causing problems so they may have pulled it for that).
s/freely/free/;
You have to do a click-through NDA just to get the -current- version ( 4.0.1 ) of the CHUD tools, I don't want to think about where this guy got his clearly pre-release copy of CHUD 4.1.0
Um no CHUD tools are not under NDA... it is a freely and publicly available tool from Apple's developer site.
See Apple's Performance Tool Page for the link.
Or just download it from the FTP site.
Nothing presents any NDA when installing it either, in fact my already installed version of CHUD prompted me to download the update.