You have the crack team of devs -- how hard was it to create a packet-cranking FPGA layout on a Xilinx board with an RJ45 connector? Are these FPGA boards simply not fast enough to dump the data (assuming you're creating data-link layer packets) needed to saturate your network?
I love internet hysteria. I suspect AMD will continue to supply good 64-bit workstation and server parts and survive in the home-build "value" niche while working to increase their whitebox and OEM sales.
Version 3 of the Completely Fair Queueing IO scheduler was put into the mainline Linux Kernel in 2.6.13 and has been the default IO scheduler since 2.6.18. Jens Axboe, who wrote and maintains it, says that CFQ "has also grown more advanced features such as IO priority support, allowing a user to define the IO priority of a process with ionice, similar to CPU scheduling." in an interview at KernelTrap (http://kerneltrap.org/node/7637).
I think that you're overlooking other architectural and production reasons for there being comparably less cache on the Athlon64 dies. My (single-core) Turion64 has 1024 KiB of L2 cache, and came out shorly before AMD shrunk their cache sizes and moved to DDR2 memory.
The issue has two potential causes: one is smaller silicon die space allows AMD to sell more chips to Dell, low-end whitebox builders and enthusiasts, which must also come with the admission that the K8 architecture was never going to hold on to the performance crown after the arrival of Core. The other is that the on-die memory interface with DDR2 memory causes so small a performance gain for having larger L2 cache that it's not even worth the branding pissing contest (and it's also possible that the Turion64 X2 has 256KiB for energy efficiency reasons). If you want to compare the Athlon 64 FX-53 Clawhammer and Athlon 63 3800+ Newcastle -- same generation, clock speed and memory frequency -- at http://www23.tomshardware.com/cpu.html, there is a benefit for having the 1 MiB L2 on the Clawhammer over the Newcastle, albeit a marginal one.
I'll contest that the Pentium D was a Pentium III, but was instead a dual-processor Prestcott Pentium 4 without the HyperThreading capabilities. I'll also contest that your AMD64 3000+ would be a huge amount better for the additional cache. On-die cache was a trick Intel pulled to try and improve the Pentium 4, Pentium 4 Xeon and Itanium perforance, and while it helps performance, I'm not convinced huge L2 cahces are essential.
After years of expansion, the world has the capacity for all the chips it can possibly use. I'd disagree: there's a booming Far East market, and developing nations like Brazil, China and India are going to be buying computing power soon enough. Then, also, as computing power becomes cheaper, we'll upgrade our phones so that, in a couple of years we'll have iPhone-comparable tech on pay-monthly contracts without upfront cost. People will innovate new places to put computing power.
Think of it like the Nintendo Wii: there's more money available from people who don't yet have computers than those that do.
Sir, I don't understand your comment "computers are one industry that isn't run by the jews". What little I can see in that statement is a differentiation between people based upon race, which may indicate prejudice. It isn't okay to write off your post as over-enthusiastically fanboy-ish, because irrational prejudice is a harmful thing. If you didn't post with prejudice against Jewish people, can you explain what you meant?
(And as for quad-core, I read somewhere of an AMD exec admitting they should have done an Athlon64 FX X4 in the same manner as the Core2 Quad: two pieces of dual-core silicon in one chip package. Further, I suspect that "Larger caches! Higher clocks! MORE!" won't do in the long run -- even Microsoft have abandoned their 16-bit legacy software support in Vista, showing that bolting on quick and easy improvements are a bad long-term plan: a smarter use of the architecture, better design, production and power efficiencies will provide genuinely better computing for AMD's clients.)
Why didn't you let the GP read their own interpretation to Mark Shuttleworth's exact words:
derStandard.at: So are we going to get pre-installed Ubuntu on Dell computers?
Mark Shuttleworth: Well - time will tell.
derStandard.at: Are there active talks on that?
Mark Shuttleworth: I would not comment on any conversations underway.
I can see that this isn't (i) a definite 'No' (and nor would it be); (ii) "We'd be delighted if the Dell team want to get in touch"; (iii) "I have their Cease & Desist and Restraining Orders on my office wall -- we'll get Dell to ship Ubuntu, just you see"; or (iv) "We're integrating Wine and Launchpad to track users via the default-installed Dell add-ons". However, I don't think that there's enough there to be sure that it is any hint of talks, as Canonical's and Ubuntu's status would rise if Mark Shuttleworth could give the impression that Dell were interested.
I don't quite get it. When you speak of "extended register range", you refer to the fact that the registers are 64 bits wide, right? No, love.
Let's start with this quote from Hannibal at Ars Technica (from http://arstechnica.com/articles/paedia/cpu/x86-64. ars): In the case of x86-64, it's the added registers and other changes that actually account for better performance on normal apps like games.
While I must admit I'm not an expert on the i386 or AMD64 architectures and am willing to be corrected, I know that i386 has eight named 32-bit registers -- actual places that the processor can store each datum it is working on -- while AMD64 has 16 named 64-bit general-purpose registers and eight named 128-bit vector registers for Single Instruction, Multiple Data stuff, which is more commonly known as SSE, SSE2 and SSE3 and is comparable to the PowerPC AltiVec stuff. The more convenient on-the-processor storage you have (like more pigeon-holes for data) the easier it is to keep the CPU doing useful work and keep track of that work.
I assume that doubling the size of the int or floatis an issue for cache exhaustion, but would assume that AMD's and Intel's engineers have the issue under control. Perhaps the reason that the dual processor AMD64 chips only have 512KiB of L2 cache is to do with chip yields and room on the silicon dies, or perhaps there isn't sufficient speed improvement to show a need for a larger cache -- I'm not sure.
AMD64 is a processor architecture like i386, mips, alpha and powerpc. 'i386' is Intel's 32-bit x86 architecture; AMD created the 64-bit x86 architecture in the Opteron and Athlon64, which has been adopted as an industry standard called AMD64, with Intel making compatible chips. They say that their AMD64-compatible chips have EM64T, which stands for Extended Memory 64-bit Technology. As a name, 'EM64T' overlooks the inclusion of extra programming registers in the CPU which rectify a lot of the legacy issues of i386. Your Core 2 Duo has EM64T capability.
I disagree with both of you. His MacBook will benefit from the extended register range in AMD64 (over x86) and his software should be a bit smoother for that.
Re:Didn't these people ever watch Star Wars?
on
AMD's New DRM
·
· Score: 2, Funny
They're in cahoots with George Lucas. In the next edition he releases, that line's edited to say "Better technical prevention measures will prevent Star Systems from slipping through our fingers".
You, sir, are a cad and a bounder. What do the ScienceMark and Primordia scores show on Page 11 of the article you linked (http://www.pcstats.com/articleview.cfm?articleid= 2097&page=11)? Did you not need to include this data so we can arrive at fair conclusions?
ScienceMark 2.0 has the Athlons run four times faster in 64-bit mode than 32; the Core2 Duo speeds up by a factor of three. Primordia has the AMD64 speed up by a factor near 8/7; Core2 by the smaller factor of 9/8. I'd say that it's swings and roundabouts, as ever with computer architectures.
See RFC 3290 for the IETF RFC spec of XMPP and XMPP.org for the home of the Extensible Messaging and Presence Protocol.
Your call for collaboration does not help the business models of AOL (AIM), Microsoft (Windows Live! Messenger) or Apple (iChat) because it cedes their control and might lose users from their platform. The big names aren't interested in it, but we-the-little-people can run our own network of OpenID enabled Jabber chatting.
I happened to chance upon a feller working on PS2 ports for the PSP. His experience was that places that people play PSP and PS2 makes PS2 games less than suitable for the PSP. He added that the PSP hardware is good but hamstrung by a slower clock speed than the PS2, insufficient memory bus bandwidth and less graphics processing power. Kudos to those who try...
Slashdot Mirror
I assume that he had trademarks too, or you were had!
You have the crack team of devs -- how hard was it to create a packet-cranking FPGA layout on a Xilinx board with an RJ45 connector? Are these FPGA boards simply not fast enough to dump the data (assuming you're creating data-link layer packets) needed to saturate your network?
I assume that's Cell broadband engine in Endian Big mode.
Next up is to get ATI to actually support any power saving features in fglrx
You don't have atitool -set-powerstate 1|2|3 in the fglrx driver? If you're running fglrx, try atitool -lsp to list the available powerstates.
I was assuming this was a patent troll biting the hand that moves the legislators, causing campaigning, lobbying and eventual patent reform.
I don't think a comeback is likely.
I love internet hysteria. I suspect AMD will continue to supply good 64-bit workstation and server parts and survive in the home-build "value" niche while working to increase their whitebox and OEM sales.
Version 3 of the Completely Fair Queueing IO scheduler was put into the mainline Linux Kernel in 2.6.13 and has been the default IO scheduler since 2.6.18. Jens Axboe, who wrote and maintains it, says that CFQ "has also grown more advanced features such as IO priority support, allowing a user to define the IO priority of a process with ionice, similar to CPU scheduling." in an interview at KernelTrap (http://kerneltrap.org/node/7637).
I think that you're overlooking other architectural and production reasons for there being comparably less cache on the Athlon64 dies. My (single-core) Turion64 has 1024 KiB of L2 cache, and came out shorly before AMD shrunk their cache sizes and moved to DDR2 memory.
The issue has two potential causes: one is smaller silicon die space allows AMD to sell more chips to Dell, low-end whitebox builders and enthusiasts, which must also come with the admission that the K8 architecture was never going to hold on to the performance crown after the arrival of Core. The other is that the on-die memory interface with DDR2 memory causes so small a performance gain for having larger L2 cache that it's not even worth the branding pissing contest (and it's also possible that the Turion64 X2 has 256KiB for energy efficiency reasons). If you want to compare the Athlon 64 FX-53 Clawhammer and Athlon 63 3800+ Newcastle -- same generation, clock speed and memory frequency -- at http://www23.tomshardware.com/cpu.html, there is a benefit for having the 1 MiB L2 on the Clawhammer over the Newcastle, albeit a marginal one.
I'll contest that the Pentium D was a Pentium III, but was instead a dual-processor Prestcott Pentium 4 without the HyperThreading capabilities. I'll also contest that your AMD64 3000+ would be a huge amount better for the additional cache. On-die cache was a trick Intel pulled to try and improve the Pentium 4, Pentium 4 Xeon and Itanium perforance, and while it helps performance, I'm not convinced huge L2 cahces are essential.
After years of expansion, the world has the capacity for all the chips it can possibly use.
I'd disagree: there's a booming Far East market, and developing nations like Brazil, China and India are going to be buying computing power soon enough. Then, also, as computing power becomes cheaper, we'll upgrade our phones so that, in a couple of years we'll have iPhone-comparable tech on pay-monthly contracts without upfront cost. People will innovate new places to put computing power.
Think of it like the Nintendo Wii: there's more money available from people who don't yet have computers than those that do.
Sir, I don't understand your comment "computers are one industry that isn't run by the jews". What little I can see in that statement is a differentiation between people based upon race, which may indicate prejudice. It isn't okay to write off your post as over-enthusiastically fanboy-ish, because irrational prejudice is a harmful thing. If you didn't post with prejudice against Jewish people, can you explain what you meant?
(And as for quad-core, I read somewhere of an AMD exec admitting they should have done an Athlon64 FX X4 in the same manner as the Core2 Quad: two pieces of dual-core silicon in one chip package. Further, I suspect that "Larger caches! Higher clocks! MORE!" won't do in the long run -- even Microsoft have abandoned their 16-bit legacy software support in Vista, showing that bolting on quick and easy improvements are a bad long-term plan: a smarter use of the architecture, better design, production and power efficiencies will provide genuinely better computing for AMD's clients.)
And so we start the meme: "They're a multi-billion dollar company, so won't miss two dollars, seventy-five."
Particularly when I'm not using their software!
I can see that this isn't (i) a definite 'No' (and nor would it be); (ii) "We'd be delighted if the Dell team want to get in touch"; (iii) "I have their Cease & Desist and Restraining Orders on my office wall -- we'll get Dell to ship Ubuntu, just you see"; or (iv) "We're integrating Wine and Launchpad to track users via the default-installed Dell add-ons". However, I don't think that there's enough there to be sure that it is any hint of talks, as Canonical's and Ubuntu's status would rise if Mark Shuttleworth could give the impression that Dell were interested.
My pointers are only 16-bit, you insensitive clod!
I'll raise you my two penn'orth: Would sir like a (48-bit, I think) flat memory model in the AMD64 architecture?
I don't quite get it. When you speak of "extended register range", you refer to the fact that the registers are 64 bits wide, right?
. ars):
No, love.
Let's start with this quote from Hannibal at Ars Technica (from http://arstechnica.com/articles/paedia/cpu/x86-64
In the case of x86-64, it's the added registers and other changes that actually account for better performance on normal apps like games.
While I must admit I'm not an expert on the i386 or AMD64 architectures and am willing to be corrected, I know that i386 has eight named 32-bit registers -- actual places that the processor can store each datum it is working on -- while AMD64 has 16 named 64-bit general-purpose registers and eight named 128-bit vector registers for Single Instruction, Multiple Data stuff, which is more commonly known as SSE, SSE2 and SSE3 and is comparable to the PowerPC AltiVec stuff. The more convenient on-the-processor storage you have (like more pigeon-holes for data) the easier it is to keep the CPU doing useful work and keep track of that work.
I assume that doubling the size of the int or float is an issue for cache exhaustion, but would assume that AMD's and Intel's engineers have the issue under control. Perhaps the reason that the dual processor AMD64 chips only have 512KiB of L2 cache is to do with chip yields and room on the silicon dies, or perhaps there isn't sufficient speed improvement to show a need for a larger cache -- I'm not sure.
AMD64 is a processor architecture like i386, mips, alpha and powerpc. 'i386' is Intel's 32-bit x86 architecture; AMD created the 64-bit x86 architecture in the Opteron and Athlon64, which has been adopted as an industry standard called AMD64, with Intel making compatible chips. They say that their AMD64-compatible chips have EM64T, which stands for Extended Memory 64-bit Technology. As a name, 'EM64T' overlooks the inclusion of extra programming registers in the CPU which rectify a lot of the legacy issues of i386. Your Core 2 Duo has EM64T capability.
I disagree with both of you. His MacBook will benefit from the extended register range in AMD64 (over x86) and his software should be a bit smoother for that.
They're in cahoots with George Lucas. In the next edition he releases, that line's edited to say "Better technical prevention measures will prevent Star Systems from slipping through our fingers".
No price drop on the Turions. Sorry.
You, sir, are a cad and a bounder. What do the ScienceMark and Primordia scores show on Page 11 of the article you linked (http://www.pcstats.com/articleview.cfm?articleid= 2097&page=11)? Did you not need to include this data so we can arrive at fair conclusions?
ScienceMark 2.0 has the Athlons run four times faster in 64-bit mode than 32; the Core2 Duo speeds up by a factor of three. Primordia has the AMD64 speed up by a factor near 8/7; Core2 by the smaller factor of 9/8. I'd say that it's swings and roundabouts, as ever with computer architectures.
Kind sir, I thank you for making this joke.
See RFC 3290 for the IETF RFC spec of XMPP and XMPP.org for the home of the Extensible Messaging and Presence Protocol.
Your call for collaboration does not help the business models of AOL (AIM), Microsoft (Windows Live! Messenger) or Apple (iChat) because it cedes their control and might lose users from their platform. The big names aren't interested in it, but we-the-little-people can run our own network of OpenID enabled Jabber chatting.
Instant Messaging Freedom Corporation
I happened to chance upon a feller working on PS2 ports for the PSP. His experience was that places that people play PSP and PS2 makes PS2 games less than suitable for the PSP. He added that the PSP hardware is good but hamstrung by a slower clock speed than the PS2, insufficient memory bus bandwidth and less graphics processing power. Kudos to those who try...
I'm sure you'll coop.