Watermarks are not audible. Once converted to analog the watermark in the digital audio stream is gone for ever.
You should become more informed before you make such claims. Just because the watermark isn't audible to humans doesn't mean that it cannot be detected from an analog signal. The SDMI doc's make it very clear that recording devices will attempt to detect watermarks in analog streams before they record them. The playback devices will also refuse to playback audio with a watermark that isn't in an encrypted form with the appropriate playback keys.
First you assume the music is decrypted in the PC, what happens if it is decrypted in the DSP? Now what happens if every DSP you buy checks for unencrypted / watermarked music before it plays it or records it. Sure you could build your own sound cards, maybe even start a company to sell them. How many people are going to buy your sound cards if they are unable to play all of the 'normal' SDMI music? How long will it take before you get sued for making a device to circumvent a content control system? How many people are you going to be able to maintain contact with who will supply you with pirated music when technologies like napster are monitored for abuse?
Anyway, the point is that you will be working in a controlled environment. A pirate might be able to get around the controls but it will have served its purpose which is to stop 99.9% of the massive piracy that the RIA is scared about because joe average user isn't going to setup a hacked music player. Of all the playstations sold how many of them have been modified to play CDR's?
Apparently, you haven't read the SDMI doc's. It is possible to watermark audio such that any recording device (your computer included) simply will not sample audio it detects the watermark in. You can plug that nice analog audio stream into you 'fancy new ultra cool feature loaded' sound card and it will refuse to record the audio because the DSP has a watermark decoder in the ROM that causes it to detect copyrighted music. Do you accually plan on keeping your current PC for the next 40 years just to record and play audio?
Officially, IBM is 'business casual'. OTOH. I worked at IBM Austin in the recent past. The development organization I was in pretty much didn't care about dress, my manager was a regular shorts wearer and tee shirts were common. The hours were extremely flexible as well. One guy I worked with got to work at 5:00AM and worked till 3 or so another got there at 11:00 AM and worked late.
There also were some good things about IBM you won't find at a smaller company. For instance IBM is VERY concerned with ergonomics and you can get all kinds of good stuff (chairs, keyboards, etc..) from the ergonomics guys.
The real problem with on die SMP is that it wastes 'resources'. Most of the next generation of 'RISC' processors will be SMT (symmetric multithreaded) instead which allows them to better utilize of the available transistor count. Expect to see the competitors with 4x or 8x SMT CPU's.
The other advantage of SMT is that it allows your cpu to tolerate higher memory latencies because it isn't such a big deal to stall a thread (waiting for memory) because the other threads will continue to utilize any functional units they need.
What I would like to know is, where is the boot message bringing the second CPU online? It looks like they are probably just running one CPU in this log.
I understand, that to properly optimize the run time, a good profile of the code will be required.
My real point was that if the guy didn't even know that calloc() 'c'lears the memory then it sort of indicates a general misunderstanding of the language. A good C/C++ programmer will have a firm grasp of the language and what kind of code his compiler is generating. This allows him to structure his code in a way that is just as readable (maybe more so since there won't be any extraneous fluf) and performs far better.
Of course a good grasp of the algorithm helps too. Life is a program that should never have its main loop coded in more than 5 lines of code.
I could at least double the speed of his code in about 15 minutes. I didn't look at his java code but I suspect there aren't nearly as many dumb things in it.
I might have just blown the whole thing off if it weren't for the fact that he claims MSVC with full optimization is slower than GCC in 'braindead' mode for a couple of tests. I've seen code GCC generates with -O, it makes me laugh.
"When was the last time YOU read the Constitution?" A better question might be when was the last time the _REPRESENTATIVES_ read the constitution!
Take for instance "Amendment X: The powers not delegated to the United States by the Constitution, nor prohibited by it to the states, are reserved to the states respectively, or to the people." and the recent crap about rape victims bringing cases in federal courts!
The point was they are making a big deal about facilities that already exist on other OS's being the default. Instead of getting load time failures you now need to make specific checks the first time you use any external libraries. Sure there are cases where you need some form of runtime loading. My point was these already exist and are a special case used somewhat rarely and they need programmer interaction if they should fail.
I may have misunderstood, but I think your example of NT/9X is somewhat bogus. If the application is designed 'correctly' you should have a 'translation' library which is where the decisions are made. Depending on the install you should decide which 'translation' library to use. Your application can then load the appropriate library at load time (maybe what you meant by run-time). Your application will fail to load in this case if it cannot find either dll. With this lazy linking scheme the application will load then the programmer will need to explicitly make checks to see if the library exists before making use of the library calls. BTW the/DELAYLOAD linker option in VC should always be complemented in code by one of the failure methods that are documented.
I see this as the same kind of stupid thinking that left C programmers with the need to check return codes everywhere. How many application programmers out there are going to make a check before the first use of a library (that is always suppost to be there) to see if it exists? If there is some kind of exception handling mechanism defined how many applications are going to be able to gracefully fail (and allow the user to resume what they were doing) when one of an application's critical libraries is missing?
Again I make the claim that it is better to fail before the user has done any work then it is to start up, let the user get some work done, and then fail because the application cannot handle a library load failure. In other words what advantage do they get by inverting the default(static/dyanamic load time binding optional dynamic runtime binding) behavior every other OS uses?
I don't understand what advantage this offers over the normal method of resolving all the symbols at load time, and then demand paging the actual library code into shared memory. The only significant difference I can see is this allows your application to startup and run for 5 minutes and then crash when it discovers that it cannot resolve a symbol because the library is missing. Under normal circumstances the application won't even start, if it can't find all of its libraries, which solves the problem before the user manages to get any work done that can potentially be lost.
On the other hand in the rare case that its a good idea to resolve a library at runtime most OS's provide the ability to 'dynamically' load libraries as needed with coder interaction. This allows the code path to deal with cases where the library fails to load. Look at the LoadLibrary/Ex call in the WIN32 SDK.
"Being able to fake SMPs is the greatest thing since sliced bread. You can't build true SMPs that big and message passing code is a bitch to write. "
So, effectively you end up with 'dumb' software (cause its 'easier' to write) which runs at about a tenth of the speed the hardware should be able to manage. Then of course there are a bunch of 'NUMA' implementation specific optimizations you can make to get your code up to speed.... Except, by the time your done with that, you might have written a distributed application with a proper message passing protocol that would have scaled better.
"So, while the UltraSparc will likely lag behind an equivalently rated Intel cpu, which would you rather use to make a cross country household move: A Kenworth or a few dozen pick-up trucks?"
Great analogy and it makes sense if you actually need a Kenworth but why pay 10x as much when all you need is a uhaul (small xeon or dual PIII)? Sure there are tasks that are better done with a big server but that group of tasks is quickly diminishing to the onslaught of extremely powerful far cheaper hardware and the price / performance / dynamic fail over / advantages of clusters.
Intel/AMD and any other player selling their HW to the unwashed masses have a huge advantage when it comes to recouping the engineering costs of a processor. If Intel can get within a decent margin (which I think they have) of the performance of the 'big RISC boys' then they _WILL_ win because its not financially a good idea to spend 100x for 10% more performance which only gives you a 2 month lead time on faster hardware. Its cheaper to build a small cluster and pay someone to swap dead nodes in a dynamic fail over system (and upgrade them as they die) then it is to buy big iron configure it and let it run for 4 years then replace it with more big iron.
The code size thing is just an obfuscation for the real issue which is optimal cache size -vs- associatively -vs- latency is a function of the application being used. An application like quake or word which can hold the vast majority of the active working set of its data structures and primary code paths in less than 256k doesn't need more than that so any speed improvements you get in the cache access times pay off big. Note on the other hand that intel went from a 512k two way set associative to a 256k 4 way set associative vs maybe a 1 meg direct mapped. In theory all three should provide roughly the same hit rate. A workstation or server on the other hand has an entirely different cache footprint. Intel engineers are smart, intel marking is not.. Remember the PPRO vs PII issue? The PPRO supported large memory sizes, fast caches, and >2 way SMP the original PII did not. So until the xeon came out there was a small group of high end server/workstation customers that were pissed off because they couldn't get newer processors from intel to replace their servers.
Motorola caches are a funny thing. They don't offer on die (that i've seen) instead they offer on die tagging. The L2 tagging is 2way set associative and supports 512k,1m and 2m external caches. This actually sounds more like a case of motorola trying to squeeze all the performance out of an old cpu core while still making them cheap with the idea that all the performance numbers will be listed with 2megs external L2 (to make up for the fact that the latency is going to suck being an external cache) while everyone will sell cheap little 512k versions.
Actually what 'nester' is saying is true.. most modern 'RISC' machines have 'complex' operations as well. It doesn't usually take more 'instructions' to perform the same operation. The x86 on the other hand has single byte complex instructions such as MOVSD which does a memory to memory copy (there isn't a mov mem,mem) with the 1010010w opcode. For example the PPC also has string move instructions although I don't have my PPC reference handy to list the opcode but they take up 32bits instead of 8. Actually the MOVSD takes up 2 bytes because you almost always want the REPNZ prefix. This is one of the problems with decoding the stream. The instructions are 'variable' length as well as different sizes. On the other hand the complex instructions in most 'RISC' architectures are going to cause those architectures to need translation layers to more simplified micro RISC OOO engines for a large number of their complex instructions as their clock speeds scale.
There isn't any excuse for these drive size issues. Pre LBA bios were limited to the 512Meg AT interface. That was back pre pentium though. Any motherboard that supports >512megs should go all the way to 134gigs (LBA max if I remember right). I know there were some issues but those were mostly 'bugs' rather than limitations. As proof of concept I have an old 486 (MR BIOS) that supports 134G drives. In fact I have a 16.7G drive hooked up to it and I plan on putting a pair of large drives in it next time it crashes. Damn linux though just won't crash its been running for >1 year.
On the other hand there will be issues when the 134G limit is reached. I was looking in the linux kernel a couple months ago and there were issues there as well. I guess we will just have to convert to SCSI then..
It has been said before (in different context) clock rate isn't everything. There are other factors. Like the fact that the AMD has 128k of L1. Clock rate on L2's doesn't mean shit if it has extra latency associated with it.
10 minutes running W2k and your 10 favorite games on equivalent Athlon -vs- PIII will tell you the Athlon blows the doors off the PIII for nearly everything except a few rare cases.
These people who pound the one or two cases where the PIII is faster have obviously forgotten the noise surrounding the 286->386 and the P5(pentium)->P6(PPro) upgrades because there were a number of cases where the newer processor didn't keep up with the old.
The bottom line is the K7 will be the death of the existing P6 core. Intel knows this and is just attempting to keep their head above water while they work out the kinks in their next core. This time next year the Athlon core will still be around and fighting the fight while the PIII will be a memory just like the P5 is today.
There may be an cost factor here. It may be significantly cheaper to use a less efficient rocket design if you don't plan on reuse. The cost of building multiple engines maybe prohibitive verses the cost of using more fuel. Not only that but there may be an issue with decreasing reliability as they complicate their somewhat simplified rocket design.
Oh, look at their job's page! They are looking for a Vx/Works software guy with Linux experience.
3. Or VIA which now has Centar, IDT and Cyrix. I would also like to point out that it was Cyrix which initially forced the sub $1000/$500 market not AMD. I would also like to point out that Cyrix was the company which released a processor which competed with significantly faster clocked Pentiums on what was the standard benchmark of the day (winbench). They were also the ones to start the >66mhz bus increases (initially the PR200? @75x2=150) with VIA not AMD.
Besides it constantly amazes me how short peoples memory is in the PC industry.. AMD 286-20's anyone?
Another somewhat annoying 'feature' is the way they are restricting 'SDMI protected content for local use', or in other words your own content.
The spec reads "This input will be restricted to mono-voice grade and band limited (-3db at 100Hz and -60dB at 8kHz)". In other words it looks like its going to be a pain in the ass to create your own content at a decent quality.
Plus it appears that they will be trying to detect watermarks on local content so they can disable playback on a stream recorded in analog from a SDMI source.
Bottom line? Run out and buy MP3 devices for two reasons. 1: Encourage the growth of an unprotected format. 2: In case the protected format catches on you will have a device that will play redigitized SDMI content.
I could look up the reference but the *star series (northstar, etc) of processors used in the AS/400 and RS6K boxes are not SMT. Its more vertical multithreading, as the comp.arch guys like to call it. The deal is that the processor executes instructions from one stream until it takes a cache miss at which point it takes a small context switch overhead time (something like 6 cycles) and starts executing another thread until that thread takes a cache miss. IBM's implementation is more of a method of hiding memory latency than a way to increase IPC. Of course decreasing memory latency causes the average system global IPC to go up but it also slows down the thread specific IPC. There are also issues with the TLB, cache etc being shared between both threads which can cause TLB thrashing which is a nasty performance problem. The result is that the performance improvement isn't nearly what the theoretical says it can be but it is a nice cheap way to gain a small but quite significant performance improvement.
Do you think that someone who has the ability to sniff traffic on 'backbone' hops from luser to unsecured site is going to sniff the traffic to a site that collects email/user name/dob information instead of an unsecured 'e-commerce' site? Come on! If they want email/user name information they would get a lot more by randomly sniffing mail traffic and then running the usernames through popular phone #/address databases.
The knowledge / intelligence of the./ is going down!
What you say is true, but in a lot of cases the goverment manages to jump start private industry. They/We dump all this money into the R&D and the private sector figures out how to make a profit from the result.
All the crap that comes on some of those linux distros is _NOT_ the OS. That's why its not called the 'Red Hat OS' or the 'SuSE OS'. Its the linux OS with Red Hat's additions.
A free OS with free applications is a completely different animal than a commercial OS with applications, that compete with other companies offerings, being bundled with the OS. They could ship windows with every piece of software they currently make. What would happen to the market if every M$ OS came with M$ Office/Backoffice etc? Someone has to pay for all that 'free' stuff. Who pays the salary of the programmer who wrote wordpad/Wang imaging/Paint etc? You do, everytime you buy a copy of windows. The 'free' stuff being distributed with your favorite linux distro is really free because it doesn't usually cost the distro any money to include. It still may hurt a potential application company but the distributor is not gaining anything from it.
Slashdot Mirror
Watermarks are not audible. Once converted to analog the watermark in the digital audio stream is gone for ever.
You should become more informed before you make such claims. Just because the watermark isn't audible to humans doesn't mean that it cannot be detected from an analog signal. The SDMI doc's make it very clear that recording devices will attempt to detect watermarks in analog streams before they record them. The playback devices will also refuse to playback audio with a watermark that isn't in an encrypted form with the appropriate playback keys.
How about the performace problems in 2.4?
Riel x ClassZone (late) results
First you assume the music is decrypted in the PC, what happens if it is decrypted in the DSP? Now what happens if every DSP you buy checks for unencrypted / watermarked music before it plays it or records it. Sure you could build your own sound cards, maybe even start a company to sell them. How many people are going to buy your sound cards if they are unable to play all of the 'normal' SDMI music? How long will it take before you get sued for making a device to circumvent a content control system? How many people are you going to be able to maintain contact with who will supply you with pirated music when technologies like napster are monitored for abuse?
Anyway, the point is that you will be working in a controlled environment. A pirate might be able to get around the controls but it will have served its purpose which
is to stop 99.9% of the massive piracy that the RIA is scared about because joe average user isn't going to setup a hacked music player. Of all the playstations
sold how many of them have been modified to play CDR's?
Apparently, you haven't read the SDMI doc's. It is possible to watermark audio such that any recording device (your computer included) simply will not sample audio it detects the watermark in. You can plug that nice analog audio stream into you 'fancy new ultra cool feature loaded' sound card and it will refuse to record the audio because the DSP has a watermark decoder in the ROM that causes it to detect copyrighted music. Do you accually plan on keeping your current PC for the next 40 years just to record and play audio?
Officially, IBM is 'business casual'. OTOH. I worked at IBM Austin in the recent past. The development organization I was in pretty much didn't care about dress, my manager was a regular shorts wearer and tee shirts were common. The hours were extremely flexible as well. One guy I worked with got to work at 5:00AM and worked till 3 or so another got there at 11:00 AM and worked late.
There also were some good things about IBM you won't find at a smaller company. For instance IBM is VERY concerned with ergonomics and you can get all kinds of good stuff (chairs, keyboards, etc..) from the ergonomics guys.
The real problem with on die SMP is that it wastes 'resources'. Most of the next generation of 'RISC' processors will be SMT (symmetric multithreaded) instead which allows them to better utilize of the available transistor count. Expect to see the competitors with 4x or 8x SMT CPU's.
The other advantage of SMT is that it allows your cpu to tolerate higher memory latencies because it isn't such a big deal to stall a thread (waiting for memory) because the other threads will continue to utilize any functional units they need.
What I would like to know is, where is the boot message bringing the second CPU online? It looks like they are probably just running one CPU in this log.
I understand, that to properly optimize the run time, a good profile of the code will be required.
My real point was that if the guy didn't even know that calloc() 'c'lears the memory then it sort of indicates a general misunderstanding of the language. A good
C/C++ programmer will have a firm grasp of the language and what kind of code his compiler is generating. This allows him to structure his code in a way that is
just as readable (maybe more so since there won't be any extraneous fluf) and performs far better.
Of course a good grasp of the algorithm helps too. Life is a program that should never have its main loop coded in more than 5 lines of code.
Has anyone looked at the code? I looked at some of his C code. Its in the directory with the makefile life.c, fib.c and fft.c
Take a look at life.c and draw your own conclusions.. For example
init0 = (int*)calloc(max_x,sizeof(int));
init1 = (int*)calloc(max_x,sizeof(int));
init2 = (int*)calloc(max_x,sizeof(int));
for (x=0; x< max_x; x++) {
init2[x] = 0;
init1[x] = 0;
init0[x] = 0;
}
I could at least double the speed of his code in about 15 minutes. I didn't look at his java code but I suspect there aren't nearly as many dumb things in it.
I might have just blown the whole thing off if it weren't for the fact that he claims MSVC with full optimization is slower than GCC in 'braindead' mode for a couple of tests. I've seen code GCC generates with -O, it makes me laugh.
"When was the last time YOU read the Constitution?" A better question might be when was the last time the _REPRESENTATIVES_ read the constitution!
Take for instance "Amendment X: The powers not delegated to the United States by the Constitution, nor prohibited by it to the states, are reserved to the states respectively, or to the people." and the recent crap about rape victims bringing cases in federal courts!
The point was they are making a big deal about facilities that already exist on other OS's being the default. Instead of getting load time failures you now need to make specific checks the first time you use any external libraries. Sure there are cases where you need some form of runtime loading. My point was these already exist and are a special case used somewhat rarely and they need programmer interaction if they should fail.
/DELAYLOAD linker option in VC should always be complemented in code by one of the failure methods that are documented.
I may have misunderstood, but I think your example of NT/9X is somewhat bogus. If the application is designed 'correctly' you should have a 'translation' library which is where the decisions are made. Depending on the install you should decide which 'translation' library to use. Your application can then load the appropriate library at load time (maybe what you meant by run-time). Your application will fail to load in this case if it cannot find either dll. With this lazy linking scheme the application will load then the programmer will need to explicitly make checks to see if the library exists before making use of the library calls. BTW the
I see this as the same kind of stupid thinking that left C programmers with the need to check return codes everywhere. How many application programmers out there are going to make a check before the first use of a library (that is always suppost to be there) to see if it exists? If there is some kind of exception handling mechanism defined how many applications are going to be able to gracefully fail (and allow the user to resume what they were doing) when one of an application's critical libraries is missing?
Again I make the claim that it is better to fail before the user has done any work then it is to start up, let the user get some work done, and then fail because the application cannot handle a library load failure. In other words what advantage do they get by inverting the default(static/dyanamic load time binding optional dynamic runtime binding) behavior every other OS uses?
I don't understand what advantage this offers over the normal method of resolving all the symbols at load time, and then demand paging the actual library code into shared memory. The only significant difference I can see is this allows your application to startup and run for 5 minutes and then crash when it discovers that it cannot resolve a symbol because the library is missing. Under normal circumstances the application won't even start, if it can't find all of its libraries, which solves the problem before the user manages to get any work done that can potentially be lost.
On the other hand in the rare case that its a good idea to resolve a library at runtime most OS's provide the ability to 'dynamically' load libraries as needed with coder interaction. This allows the code path to deal with cases where the library fails to load. Look at the LoadLibrary/Ex call in the WIN32 SDK.
"Being able to fake SMPs is the greatest thing since sliced bread. You can't build true SMPs that big and message passing code is a bitch to write. "
So, effectively you end up with 'dumb' software (cause its 'easier' to write) which runs at about a tenth of the speed the hardware should be able to manage. Then of course there are a bunch of 'NUMA' implementation specific optimizations you can make to get your code up to speed.... Except, by the time your done with that, you might have written a distributed application with a proper message passing protocol that would have scaled better.
"So, while the UltraSparc will likely lag behind an equivalently rated Intel cpu, which would you rather use to make a cross country household move: A Kenworth or a few dozen pick-up trucks?"
Great analogy and it makes sense if you actually need a Kenworth but why pay 10x as much when all you need is a uhaul (small xeon or dual PIII)? Sure there are tasks that are better done with a big server but that group of tasks is quickly diminishing to the onslaught of extremely powerful far cheaper hardware and the price / performance / dynamic fail over / advantages of clusters.
Intel/AMD and any other player selling their HW to the unwashed masses have a huge advantage when it comes to recouping the engineering costs of a processor. If Intel can get within a decent margin (which I think they have) of the performance of the 'big RISC boys' then they _WILL_ win because its not financially a good idea to spend 100x for 10% more performance which only gives you a 2 month lead time on faster hardware. Its cheaper to build a small cluster and pay someone to swap dead nodes in a dynamic fail over system (and upgrade them as they die) then it is to buy big iron configure it and let it run for 4 years then replace it with more big iron.
The code size thing is just an obfuscation for the real issue which is optimal cache size -vs- associatively -vs- latency is a function of the application being used. An application like quake or word which can hold the vast majority of the active working set of its data structures and primary code paths in less than 256k doesn't
need more than that so any speed improvements you get in the cache access times pay off big. Note on the other hand that intel went from a 512k two way set associative to a 256k 4 way set associative vs maybe a 1 meg direct mapped. In theory all three should provide roughly the same hit rate. A workstation or server on the other hand has an entirely different cache footprint. Intel engineers are smart, intel marking is not.. Remember the PPRO vs PII issue? The PPRO supported large memory sizes, fast caches, and >2 way SMP the original PII did not. So until the xeon came out there was a small group of high end server/workstation customers that were pissed off because they couldn't get newer processors from intel to replace their servers.
Motorola caches are a funny thing. They don't offer on die (that i've seen) instead they offer on die tagging. The L2 tagging is 2way set associative and supports 512k,1m and 2m external caches. This actually sounds more like a case of motorola trying to squeeze all the performance out of an old cpu core while still making them cheap with the idea that all the performance numbers will be listed with 2megs external L2 (to make up for the fact that the latency is going to suck being an external cache) while everyone will sell cheap little 512k versions.
Actually what 'nester' is saying is true.. most modern 'RISC' machines have 'complex' operations as well. It doesn't usually take more 'instructions' to perform the same operation. The x86 on the other hand has single byte complex instructions such as MOVSD which does a memory to memory copy (there isn't a mov
mem,mem) with the 1010010w opcode. For example the PPC also has string move instructions although I don't have my PPC reference handy to list the opcode but they take up 32bits instead of 8. Actually the MOVSD takes up 2 bytes because you almost always want the REPNZ prefix. This is one of the problems with decoding the stream. The instructions are 'variable' length as well as different sizes. On the other hand the complex instructions in most 'RISC' architectures are going to cause those architectures to need translation layers to more simplified micro RISC OOO engines for a large number of their complex instructions as their clock speeds scale.
There isn't any excuse for these drive size issues. Pre LBA bios were limited to the 512Meg AT interface. That was back
pre pentium though. Any motherboard that supports >512megs should go all the way to 134gigs (LBA max if I remember
right). I know there were some issues but those were mostly 'bugs' rather than limitations. As proof of concept I have an
old 486 (MR BIOS) that supports 134G drives. In fact I have a 16.7G drive hooked up to it and I plan on putting a pair
of large drives in it next time it crashes. Damn linux though just won't crash its been running for >1 year.
On the other hand there will be issues when the 134G limit is reached. I was looking in the linux kernel a couple months
ago and there were issues there as well. I guess we will just have to convert to SCSI then..
It has been said before (in different context) clock rate isn't everything. There are other factors. Like the fact that the AMD has 128k of L1. Clock rate on L2's
doesn't mean shit if it has extra latency associated with it.
10 minutes running W2k and your 10 favorite games on equivalent Athlon -vs- PIII will tell you the Athlon blows the doors off the PIII for nearly everything except a few rare cases.
These people who pound the one or two cases where the PIII is faster have obviously forgotten the noise surrounding the 286->386 and the P5(pentium)->P6(PPro) upgrades because there were a number of cases where the newer processor didn't keep up with the old.
The bottom line is the K7 will be the death of the existing P6 core. Intel knows this and is just attempting to keep their head above water while they work out the kinks in their next core. This time next year the Athlon core will still be around and fighting the fight while the PIII will be a memory just like the P5 is today.
There may be an cost factor here. It may be significantly cheaper to use a less efficient rocket design if you don't plan on reuse. The cost of building multiple engines maybe prohibitive verses the cost of using more fuel. Not only that but there may be an issue with decreasing reliability as they complicate their somewhat simplified rocket design.
Oh, look at their job's page! They are looking for a Vx/Works software guy with Linux experience.
3. Or VIA which now has Centar, IDT and Cyrix. I would also like to point out that it was Cyrix which initially forced the sub $1000/$500 market not AMD. I would also like to point out that Cyrix was the company which released a processor which competed with significantly faster clocked Pentiums on what was the standard benchmark of the day (winbench). They were also the ones to start the >66mhz bus increases (initially the PR200? @75x2=150) with VIA not AMD.
Besides it constantly amazes me how short peoples memory is in the PC industry.. AMD 286-20's anyone?
Another somewhat annoying 'feature' is the way they are restricting 'SDMI protected content for local use', or in other words
your own content.
The spec reads "This input will be restricted to mono-voice grade and band limited (-3db at 100Hz and -60dB at 8kHz)". In
other words it looks like its going to be a pain in the ass to create your own content at a decent quality.
Plus it appears that they will be trying to detect watermarks on local content so they can disable playback on a stream recorded
in analog from a SDMI source.
Bottom line? Run out and buy MP3 devices for two reasons. 1: Encourage the growth of an unprotected format. 2: In case the
protected format catches on you will have a device that will play redigitized SDMI content.
I could look up the reference but the *star series (northstar, etc) of processors used in the AS/400 and RS6K boxes are not SMT. Its more vertical multithreading, as the comp.arch guys like to call it.
The deal is that the processor executes instructions from one stream until it takes a cache miss at which point it takes a small context switch overhead time (something like 6 cycles) and starts executing another thread until that thread takes a cache miss. IBM's implementation is more of a method of hiding memory latency than a way to increase IPC. Of course decreasing memory latency causes the average system global IPC to go up but it also slows down the thread specific IPC. There are also issues with the TLB, cache etc being shared between both threads which can cause TLB thrashing which is a nasty performance problem. The result is that the performance improvement isn't nearly what the theoretical says it can be but it is a nice cheap way to gain a small but quite significant performance improvement.
Do you think that someone who has the ability to sniff traffic on 'backbone' hops from luser to unsecured site is going to sniff the traffic to a site that collects email/user name/dob information instead of an unsecured 'e-commerce' site? Come on! If they want email/user name information they would get a lot more by randomly sniffing mail traffic and then running the usernames through popular phone #/address databases.
./ is going down!
The knowledge / intelligence of the
What you say is true, but in a lot of cases the goverment manages to jump start private industry. They/We dump all this money into the R&D and the private sector figures out how to make a profit from the result.
Citrix WinFrame
All the crap that comes on some of those linux distros is _NOT_ the OS. That's why its not called the 'Red Hat OS' or the 'SuSE OS'. Its the linux OS with Red Hat's additions.
A free OS with free applications is a completely different animal than a commercial OS with applications, that compete with other companies offerings, being bundled with the OS. They could ship windows with every piece of software they currently make. What would happen to the market if every M$ OS came with M$ Office/Backoffice etc? Someone has to pay for all that 'free' stuff. Who pays the salary of the programmer who wrote wordpad/Wang imaging/Paint etc? You do, everytime you buy a copy of windows. The 'free' stuff being distributed with your favorite linux distro is really free because it doesn't usually cost the distro any money to include. It still may hurt a potential application company but the distributor is not gaining anything from it.