Intel has long had a group Israel, in fact, the two major design teams are in Oregon and Israel, and they alternate new core micro-archiectures every generation (which is a two-year tick/tock cycle, so each design time works on a new core design on a four-year cycle).
"Frequently, the green lights next to our iSight webcams will turn on. The school district claims that this is just a glitch. We are all doubting this now."
"[The student] was at home using a school issued laptop that was neither reported lost nor stolen when his image was captured by Defendants without his or his parents' permission and while he was at home."
We do need something to make multiple-CPU programming easier though. Threaded programming in C/C++ or similar can turn into a nightmare real quick, it's error prone and complicated.
If you want to use C++, I suggest Thread Building Blocks, which is an open-source C++ library. It is a set of reasonable primitives, including a task scheduler and some simple parallel iterators that create tasks. The task scheduling makes it mostly independent of the specific number of cores in the system, which is key. It think it is part of most Linux distributions these days. For simple data parallel computations, you can avoid thinking about threads and locks entirely, but yet it also allows provides the low-level primitives to write sophisticated highly optimized code, too.
P.S. I totally agree that Erlang is just *not* the right solution for multicore. Erlang's message passing is great for the application for which it was designed (telecommunications equipment with multiple independent line cards and such) or any such highly concurrent applications with high availability needs. It just isn't well suited for multicore programming (which just has an entirely different set of challenges such as data locality).
No, the above post really overstates what goes on inside today's x86 chips.
It is true that Intel and AMD internally break up x86 into simpler "micro-ops" to simplify the internals of the chip. However, the specific micro-ops uses are tailored explicitly for x86 instructions, and many match up with x86 instructions one-to-one. The mapping really isn't that programmable, either. Most of the mapping is hard-coded and highly optimized. It would not be trivial to support another ISA such as PowerPC, even for just user-mode instructions. If you then consider all the privileged instructions, virtual memory, and virtualization stuff, you have a real mess. It would likely be easier to start from scratch rather than try to retrofit a current x86 to be anything other than an x86. Sure, you could reuse some of the arithmetic units and memory controllers perhaps, but the core would have to change pretty dramatically.
That said, Transmeta (RIP) did have technology that would likely make it easier to run non-x86 code on its processor, and the translation was done in software. But even its internal instructions were likely closely match to specifics of the x86 ISA.
Even as recently as 2002 you could buy a 44mpg highway Civic. No, not a hybrid - it was the "HX" model with lean-burn engine.
The EPA recently changed the way they measure fuel efficiency (MPG). With the new standard: "the city mpg estimates for the manufacturers of most vehicles will drop by about 12 percent on average, and by as much as 30 percent for some vehicles. The highway mpg estimates will drop on average by about 8 percent, and by as much as 25 percent for some vehicles", according to the EPA web site. This follows an early revision (also downward) in the 1980s.
In addition, Hybrids have the most benefit on stop-and-go city miles, but less impact on highway miles. Hybrids typically have other features that help, such as continuously variable transmissions and smaller and efficient engines.
This isn't some sort of conspiracy. Car manufactures are making the cars people want to buy. For those looking for fuel efficiency, something like the Prius really does reflect state-of-the-art fuel efficiency.
I agree that PrinceXML is pretty expensive. However, as it is based primarily around web standards (or at least proposed web standards with clearly-marked propriety extensions), I would hope that eventually one of the current HTML rendering engines could be retargeted to PDF in much the same way.
In fact, I suspect that one day all web browsers will support such extensions for generating "printer friendly" version of documents.
PrinceXML give a glimpse at a future where XHMTL+CSS is the future of publishing, and I like that future a lot more than the either than staying with LaTeX or moving to the crufty XSL-FO that was mentioned earlier.
Think of LaTeX as a 1980's HTML design for typesetting technical papers and especially typesetting mathematics. Like HTML, the markup is mostly semantic, in that you specify section headings, subsections, subsubsections, etc.
You can apply different formats to the same document, but not in a CSS-like way. Basically, all of the markup are like macros that can be redefined to apply different formatting. Yet, even small changes to these predefine templates requires mucking with some pretty ugly stuff.
The other thing that gives LaTeX its staying power is a solid bibliographic system (BibTeX). Something like using Endnote with Word can come close to it these days, but for a long time BibTeX was/is the only reasonable way of dealing with the dozens or hundreds of citations in technical writing.
Learning LaTeX after knowing XHTML+CSS would be like learning Algol after knowing Java and Python (or whatever your favorite language du jour), it would just seem painfully ancient.
Check out PrinceXML. It actually adds footnotes, page number, and all that stuff to standard XHTML+CSS. It has already been used to typeset a book, and it looks quite nice. The authors of the one book have talked about their experiences with it Their tool renders into PDF, but the same based XHTML will work in a web browser, giving the option of having the same document look good on paper and on the web.
If you look at the actual instructions generated by modern compilers for x86-64, it is much more RISC-like than ever. It uses a flat (non-segmented) 64-bit memory space and the sane set of x86 instructions in practice. Sure, the chips have to support all the seldom-used instructions, but that is done mostly via microcode. In addition, x86-64 has 16 registers (rather than 8), reducing the frequency of memory operations. The new function call ABI for x86-64 also allows passing values in registers (and not on the stack in memory), further reducing needless memory instructions. Finally, x86's variable length instructions actually reduces the size of the program, improving instruction cache performance over a RISC ISA with fixed-size instructions (like PowerPC). It turns out that when you have a billion transistors to play with, the exact ISA just doesn't matter as much as the quality of the specific design. In summary, x86 is ugly, but doesn't really impact the performance and power as much as one expect.
As long as they remove the pass-key before they junk the machine, this is probably fine. I think the biggest issue they are worried about is avoiding the recent stories in which US government data found on used hard drives purchased from eBay... Using whole-disk encryption makes "erasing" the hard drive as easy as destroying a single key.
Can we really trust someone who says: "Well, I am a technologist"? Engineer, maybe. But, technologist? From his bio, it is clear that this guy was once a hands-on engineer, but he seems more like a pointer-haired manager to me now.
Steve Scott serves as Chief Technology Officer responsible for designing the integrated infrastructure that will drive Cray's next generation of supercomputer. Dr. Scott, who joined Cray in 1992, was formerly the chief architect of the Cray X1 scalable vector supercomputer and was instrumental in the design of the Cray/Sandia Red Storm supercomputer system. Dr. Scott holds fourteen US patents in the areas of interconnection networks, cache coherence, synchronization mechanisms, and scalable parallel architectures. He received his Ph.D. in computer architecture from the University of Wisconsin, Madison in 1992, where he was a Wisconsin Alumni Research Foundation and Hertz Foundation Fellow. Dr. Scott has served on numerous program committees and as an associate editor for the IEEE Transactions on Parallel and Distributed Systems. He is a noted expert in high performance computer architecture and interconnection networks, and was the recipient of the 2005 ACM Maurice Wilkes Award.
Burton Smith and Steve Scott were considered the two most important technical leaders at Cray, and now both of them are gone. Seems like Cray might be a sinking ship...
Re:Dear submitter.... READ THE ARTICLE
on
Who Needs Harvard?
·
· Score: 1
Based upon the erroneous conclusions of the submitter and the author of the original article, I would say that both probably attended a public college.:-)
Actually, the author of the article has degrees from two of the eight Ivy League schools. From the author's bio:
...a graduate of Cornell University, he holds an A.M. in American history from Harvard University...
For a RISC cpu, each word contains an instruction. The address is embeded inside that instruction. With 64bits, this leaves you with a 22bit command and a 42 bit address. The maximum memory addressed is then 2^42 bytes - or four terabytes... You don't belive me - check the literature on the G5...
Wrong! The PowerPC G5 (like all other 64-bit RISC chips) use 32-bit instructions. These instructions don't directly encode addresses (addresses are mostly held in registers).
True, some implementations of 64-bit chips only support 42-bits or so of physical address space, but they still support the full 64-bits of virtual address space. Since the user-level software isn't affected by the physical address space (user-level code only deals with virtual addresses), the same software can run on future systems with larger physical address space without any changes.
You can do 64 bit stuff but you need a prefix byte on the instruction. This is also needed for fancy addressing modes and extra regs (8..15).
Yes, that is true. In my original comment, I forgot that AMD's extension of x86 to 64-bit addressing does increase code size for some instructions. In contrast, PowerPC, SPARC, and MIPS instructions did not increase in size when moving to 64-bit.
Fortunatly, AMD took the opportunity to make some other enhancements (such as the larger number of registers which you mentioned), the code increase should be offset by the other enhancements for most programs.
More bits per instruction means... more thrash-in-your-cache... more RAM bandwidth used just sucking down instructions
Wrong! When someone says "a 64-bit chip" they mean the number of bits used to specify a memory location (ie., the size of a pointer). They are not talking about the size of the instructions!
The main benefit is not wider arithmetic operations or higher performance. The main benefit is more addressable memory. Since the amount of memory in a machine has been doubling every year or two, we need an extra "bit" of addressability every couple of years. We already need 64-bit chips for servers, and it is only a matter of time until we need 64-bits on the desktop.
In fact, I HATE bicycle helmets. Their sole purpose is to show all the people driving around that the person on the bike is middle class, has a car at home, can afford a $100 helmet, and is seriously concerned about saving the environment to the point of actually going out into the public on a bicycle.
Dude, ever been hit by a car while on a bike? I have. My helmet saved me a trip to the hospital and prevented what would have been a nasty head injury. The car turned right into me, I went flying, flipped over the hood of the car, and landed on my head. My helmet was collapsed/crushed (like they are designed to do when they take a blow). The paramedics came and found me laying on the street barley conscience. I the end, I walked away with scratches, bruises, and was really sore the next day. If I wasn't wearing a helmet, it would have been grim.
In my experiences (on a university campus), most students don't wear helmets for fashion and image reasons. You know, "I'm too cool for a helmet, besides I'm 19 years old and I'm invincible" or "it messes up my hair". Idiots.
P.S. I just used froogle to find a reasonable bike helmet for $30.
The 'web' is not strictly defined, but it is unlikely to be interpreted as just HTTP/HTML... Strictly speaking, any URL-able resource is part of the web.
This comment makes me wonder how the term "World Wide Web" would be interpreted. Would it be interpreted based on what the web was when the patent was written? As the web becomes subsumes more and more traditional protocols, doe the scope of the patent broaden? If I make a resource URL-able does that make it part of the web now, and thus covered by this patent?
This patent specifically covers using the World Wide Web to update a computer; it does not cover all possible ways to update software via the Internet (the web is just the subset of the internet that uses HTTP and HTML). Thus, if you perform automatic updates without using HTTP or HTML (say, XML and SCP), this patent does not affect you. In essence, this patent is easy to work around, so it should have much of a long-term effect on the world as we know it.
I suspect the only reason this patent was issued was due to this specific nature of the claims; however, in the short-run this pattent still might cause some big headaches if the lawyers get really over eager (which always seems to happen...)
Oh, but wait; pine has been vulnerable in the past due to various buffer overflows and mime errors. For example, see CERT Vulnerability Note VU#780737. Granted, most users don't run Pine as root (thus limiting the damage), but it could still cause some real problems; that is, it could if everyone used unpatched versions of pine.
The problem with Microsoft products is due to monoculture as much as bad software engineering.
I have heard it said that the DES standard was adjusted to be fewer bits so only the large NSA computers could crack it. The government is nervous about any technology that prevents them the ability to spy on information or individuals.
The government did ask IBM to change part of the DES specification without explanation. However, years later some academic researchers discovered a new cryptanalysis technique and was shocked to find that the government's changes made DES more secure in light of this attack. The NSA scientists seemed to imply that they knew about this attack years before the academic cryptography community (just like they invented public-key cryptography before RSA did).
Yes, you're right the Power4 does have a large level3 cache, and this will also certianly help Power4+'s performance as compared to the 970/G5. This is especially true for some of the SPECfp benchmarks that can fit their entire datasets in a 32MB cache.
Good call.
FYI: The actual size of the third-level cache depends on the number of processors (ranging from 32MB for up to 8 processors to 128MB with 32 processors).
Interestingly, these caches use don't use standard SRAM, but instead use IBM's "embedded DRAM" process. Thus, while these caches are faster than main memory, they are not as much faster as one might imagine.
Apples claims seem quite reasonable to me. Why? Look at the other
reported SPEC scores for Power4+ (the G5/970 is based directly on
IBM's Power4+ processor core). Right now the Power4 ranks well on
both SPECint2000 and SPECfp2000. See the
SPECfp2000 and
SPECint2000 benchmark report summaries.
SPECfp: The Power4+ at 1.7 Ghz has the highest SPECfp score (1699 @ 1.7Ghz);
higher than Itanium (1431 @ 1Ghz), the most recent Alpha (1482 @
1.15Ghz), and the Pentium 4 (1229 @ 3.0Ghz).
SPECint: As far as SPECint, the Power4 is not in the lead (1113 @ 1.7Ghz), but
is still respectable when compared to Pentium4's (1200 @ 3.0Ghz).
The G5/970 should do similarly or better than the G5/970 (since the G5/970 is running at 2.0Ghz vs Power4+ 1.7Ghz).
One caveat is that the G5/970 has a smaller on-chip second-level
cache (512kB vs 1.5MB), which will hurt its performance on some codes.
Certainly Apple's test uses a drastically different compiler than the reported SPEC results. This results in absolute numbers that are lower, but Apple's relative comparison is still reasonable, IMHO. I think it is safe
to claim that Apple has really closed the gap in processor speed and
now has processors with comparable performance to the fastest chips
money can buy. About damn time.:)
Slashdot Mirror
Intel has long had a group Israel, in fact, the two major design teams are in Oregon and Israel, and they alternate new core micro-archiectures every generation (which is a two-year tick/tock cycle, so each design time works on a new core design on a four-year cycle).
Isn't the iPhone environment the closest to this that we have in a mainstream computing environment?
A student has been quoted as saying:
"Frequently, the green lights next to our iSight webcams will turn on. The school district claims that this is just a glitch. We are all doubting this now."
http://thelede.blogs.nytimes.com/2010/02/19/school-accused-of-using-webcam-to-photograph-student-at-home/
The lawsuit filed in court states:
"[The student] was at home using a school issued laptop that was neither reported lost nor stolen when his image was captured by Defendants without his or his parents' permission and while he was at home."
http://www.computerworld.com/s/article/print/9159778/Irate_parents_in_Pa._say_schools_use_peeping_tom_technology_
If this is true, sounds pretty damning to me.
We do need something to make multiple-CPU programming easier though. Threaded programming in C/C++ or similar can turn into a nightmare real quick, it's error prone and complicated.
If you want to use C++, I suggest Thread Building Blocks, which is an open-source C++ library. It is a set of reasonable primitives, including a task scheduler and some simple parallel iterators that create tasks. The task scheduling makes it mostly independent of the specific number of cores in the system, which is key. It think it is part of most Linux distributions these days. For simple data parallel computations, you can avoid thinking about threads and locks entirely, but yet it also allows provides the low-level primitives to write sophisticated highly optimized code, too.
P.S. I totally agree that Erlang is just *not* the right solution for multicore. Erlang's message passing is great for the application for which it was designed (telecommunications equipment with multiple independent line cards and such) or any such highly concurrent applications with high availability needs. It just isn't well suited for multicore programming (which just has an entirely different set of challenges such as data locality).
No, the above post really overstates what goes on inside today's x86 chips.
It is true that Intel and AMD internally break up x86 into simpler "micro-ops" to simplify the internals of the chip. However, the specific micro-ops uses are tailored explicitly for x86 instructions, and many match up with x86 instructions one-to-one. The mapping really isn't that programmable, either. Most of the mapping is hard-coded and highly optimized. It would not be trivial to support another ISA such as PowerPC, even for just user-mode instructions. If you then consider all the privileged instructions, virtual memory, and virtualization stuff, you have a real mess. It would likely be easier to start from scratch rather than try to retrofit a current x86 to be anything other than an x86. Sure, you could reuse some of the arithmetic units and memory controllers perhaps, but the core would have to change pretty dramatically.
That said, Transmeta (RIP) did have technology that would likely make it easier to run non-x86 code on its processor, and the translation was done in software. But even its internal instructions were likely closely match to specifics of the x86 ISA.
The EPA recently changed the way they measure fuel efficiency (MPG). With the new standard: "the city mpg estimates for the manufacturers of most vehicles will drop by about 12 percent on average, and by as much as 30 percent for some vehicles. The highway mpg estimates will drop on average by about 8 percent, and by as much as 25 percent for some vehicles", according to the EPA web site. This follows an early revision (also downward) in the 1980s.
In addition, Hybrids have the most benefit on stop-and-go city miles, but less impact on highway miles. Hybrids typically have other features that help, such as continuously variable transmissions and smaller and efficient engines.
This isn't some sort of conspiracy. Car manufactures are making the cars people want to buy. For those looking for fuel efficiency, something like the Prius really does reflect state-of-the-art fuel efficiency.
I agree that PrinceXML is pretty expensive. However, as it is based primarily around web standards (or at least proposed web standards with clearly-marked propriety extensions), I would hope that eventually one of the current HTML rendering engines could be retargeted to PDF in much the same way.
In fact, I suspect that one day all web browsers will support such extensions for generating "printer friendly" version of documents.
PrinceXML give a glimpse at a future where XHMTL+CSS is the future of publishing, and I like that future a lot more than the either than staying with LaTeX or moving to the crufty XSL-FO that was mentioned earlier.
Think of LaTeX as a 1980's HTML design for typesetting technical papers and especially typesetting mathematics. Like HTML, the markup is mostly semantic, in that you specify section headings, subsections, subsubsections, etc.
You can apply different formats to the same document, but not in a CSS-like way. Basically, all of the markup are like macros that can be redefined to apply different formatting. Yet, even small changes to these predefine templates requires mucking with some pretty ugly stuff.
The other thing that gives LaTeX its staying power is a solid bibliographic system (BibTeX). Something like using Endnote with Word can come close to it these days, but for a long time BibTeX was/is the only reasonable way of dealing with the dozens or hundreds of citations in technical writing.
Learning LaTeX after knowing XHTML+CSS would be like learning Algol after knowing Java and Python (or whatever your favorite language du jour), it would just seem painfully ancient.
Check out PrinceXML. It actually adds footnotes, page number, and all that stuff to standard XHTML+CSS. It has already been used to typeset a book, and it looks quite nice. The authors of the one book have talked about their experiences with it
Their tool renders into PDF, but the same based XHTML will work in a web browser, giving the option of having the same document look good on paper and on the web.
There is also a Google Tech Talk on PrinceXML
If you look at the actual instructions generated by modern compilers for x86-64, it is much more RISC-like than ever. It uses a flat (non-segmented) 64-bit memory space and the sane set of x86 instructions in practice. Sure, the chips have to support all the seldom-used instructions, but that is done mostly via microcode. In addition, x86-64 has 16 registers (rather than 8), reducing the frequency of memory operations. The new function call ABI for x86-64 also allows passing values in registers (and not on the stack in memory), further reducing needless memory instructions. Finally, x86's variable length instructions actually reduces the size of the program, improving instruction cache performance over a RISC ISA with fixed-size instructions (like PowerPC). It turns out that when you have a billion transistors to play with, the exact ISA just doesn't matter as much as the quality of the specific design. In summary, x86 is ugly, but doesn't really impact the performance and power as much as one expect.
As long as they remove the pass-key before they junk the machine, this is probably fine. I think the biggest issue they are worried about is avoiding the recent stories in which US government data found on used hard drives purchased from eBay... Using whole-disk encryption makes "erasing" the hard drive as easy as destroying a single key.
Can we really trust someone who says: "Well, I am a technologist"? Engineer, maybe. But, technologist? From his bio, it is clear that this guy was once a hands-on engineer, but he seems more like a pointer-haired manager to me now.
Burton Smith and Steve Scott were considered the two most important technical leaders at Cray, and now both of them are gone. Seems like Cray might be a sinking ship...
For a RISC cpu, each word contains an instruction. The address is embeded inside that instruction. With 64bits, this leaves you with a 22bit command and a 42 bit address. The maximum memory addressed is then 2^42 bytes - or four terabytes... You don't belive me - check the literature on the G5...
Wrong! The PowerPC G5 (like all other 64-bit RISC chips) use 32-bit instructions. These instructions don't directly encode addresses (addresses are mostly held in registers).
True, some implementations of 64-bit chips only support 42-bits or so of physical address space, but they still support the full 64-bits of virtual address space. Since the user-level software isn't affected by the physical address space (user-level code only deals with virtual addresses), the same software can run on future systems with larger physical address space without any changes.
You can do 64 bit stuff but you need a prefix byte on the instruction. This is also needed for fancy addressing modes and extra regs (8..15).
Yes, that is true. In my original comment, I forgot that AMD's extension of x86 to 64-bit addressing does increase code size for some instructions. In contrast, PowerPC, SPARC, and MIPS instructions did not increase in size when moving to 64-bit.
Fortunatly, AMD took the opportunity to make some other enhancements (such as the larger number of registers which you mentioned), the code increase should be offset by the other enhancements for most programs.
More bits per instruction means... more thrash-in-your-cache... more RAM bandwidth used just sucking down instructions
Wrong! When someone says "a 64-bit chip" they mean the number of bits used to specify a memory location (ie., the size of a pointer). They are not talking about the size of the instructions!
The main benefit is not wider arithmetic operations or higher performance. The main benefit is more addressable memory. Since the amount of memory in a machine has been doubling every year or two, we need an extra "bit" of addressability every couple of years. We already need 64-bit chips for servers, and it is only a matter of time until we need 64-bits on the desktop.
In fact, I HATE bicycle helmets. Their sole purpose is to show all the people driving around that the person on the bike is middle class, has a car at home, can afford a $100 helmet, and is seriously concerned about saving the environment to the point of actually going out into the public on a bicycle.
Dude, ever been hit by a car while on a bike? I have. My helmet saved me a trip to the hospital and prevented what would have been a nasty head injury. The car turned right into me, I went flying, flipped over the hood of the car, and landed on my head. My helmet was collapsed/crushed (like they are designed to do when they take a blow). The paramedics came and found me laying on the street barley conscience. I the end, I walked away with scratches, bruises, and was really sore the next day. If I wasn't wearing a helmet, it would have been grim.
In my experiences (on a university campus), most students don't wear helmets for fashion and image reasons. You know, "I'm too cool for a helmet, besides I'm 19 years old and I'm invincible" or "it messes up my hair". Idiots.
P.S. I just used froogle to find a reasonable bike helmet for $30.
The 'web' is not strictly defined, but it is unlikely to be interpreted as just HTTP/HTML... Strictly speaking, any URL-able resource is part of the web.
This comment makes me wonder how the term "World Wide Web" would be interpreted. Would it be interpreted based on what the web was when the patent was written? As the web becomes subsumes more and more traditional protocols, doe the scope of the patent broaden? If I make a resource URL-able does that make it part of the web now, and thus covered by this patent?
This patent specifically covers using the World Wide Web to update a computer; it does not cover all possible ways to update software via the Internet (the web is just the subset of the internet that uses HTTP and HTML). Thus, if you perform automatic updates without using HTTP or HTML (say, XML and SCP), this patent does not affect you. In essence, this patent is easy to work around, so it should have much of a long-term effect on the world as we know it.
I suspect the only reason this patent was issued was due to this specific nature of the claims; however, in the short-run this pattent still might cause some big headaches if the lawyers get really over eager (which always seems to happen...)
The new "top 500" list will be announced right before SC2003 and discussed in detail at a session of SC2003 on November 18.
Look for another (less speculative) story on Slashdot around then.
.../been using pine since 1996...
Oh, but wait; pine has been vulnerable in the past due to various buffer overflows and mime errors. For example, see
CERT Vulnerability Note VU#780737. Granted, most users don't run Pine as root (thus limiting the damage), but it could still cause some real problems; that is, it could if everyone used unpatched versions of pine.
The problem with Microsoft products is due to monoculture as much as bad software engineering.
I have heard it said that the DES standard was adjusted to be fewer bits so only the large NSA computers could crack it. The government is nervous about any technology that prevents them the ability to spy on information or individuals.
The government did ask IBM to change part of the DES specification without explanation. However, years later some academic researchers discovered a new cryptanalysis technique and was shocked to find that the government's changes made DES more secure in light of this attack. The NSA scientists seemed to imply that they knew about this attack years before the academic cryptography community (just like they invented public-key cryptography before RSA did).
FYI: The actual size of the third-level cache depends on the number of processors (ranging from 32MB for up to 8 processors to 128MB with 32 processors).
Interestingly, these caches use don't use standard SRAM, but instead use IBM's "embedded DRAM" process. Thus, while these caches are faster than main memory, they are not as much faster as one might imagine.
SPECfp: The Power4+ at 1.7 Ghz has the highest SPECfp score (1699 @ 1.7Ghz); higher than Itanium (1431 @ 1Ghz), the most recent Alpha (1482 @ 1.15Ghz), and the Pentium 4 (1229 @ 3.0Ghz).
SPECint: As far as SPECint, the Power4 is not in the lead (1113 @ 1.7Ghz), but is still respectable when compared to Pentium4's (1200 @ 3.0Ghz).
The G5/970 should do similarly or better than the G5/970 (since the G5/970 is running at 2.0Ghz vs Power4+ 1.7Ghz). One caveat is that the G5/970 has a smaller on-chip second-level cache (512kB vs 1.5MB), which will hurt its performance on some codes.
Certainly Apple's test uses a drastically different compiler than the reported SPEC results. This results in absolute numbers that are lower, but Apple's relative comparison is still reasonable, IMHO. I think it is safe to claim that Apple has really closed the gap in processor speed and now has processors with comparable performance to the fastest chips money can buy. About damn time. :)