On my own personal e-mail address I've received a grand total of ZERO spams in the ~2 years I've used it. I'm VERY careful about where that address goes. Even fairly legit companies (ie my bank) get a secondary address, and the really sketchy companies get a spamgourmet.com address if they need an e-mail address.
However, I just decided to check my ISP e-mail account. I signed up for this cable modem service in October and had the account assigned to me then. I have never once used this account for ANY reason. I hadn't even opened the mail box before today. So what did I see? A mailbox that had hit it's limit at 1,000 messages, of which about 975 were spam (the other 25 were messages from the ISP warning me that my mailbox was full:> ). That works out to more than 10 spams per day, and I'm pretty certain that about half of the spam sent to me bounced because the mailbox was full. Not quite the 40/day, but not too far off.
Long story short, no matter how smart you are, you can still get a lot of spam. It's even worse for companies with a web site and contact e-mails. Any e-mail address posted to a website will be harvested by spammers in a matter of days and the mailbox will be bombarded.
I know that this was a joke and all, but... The amount of spam that comes out of AOL, Hotmail, Yahoo and all of the other major e-mail providers combined is so tiny as to be negligible. All the major providers do block outgoing spam (try sending 500 message all at once through one of them, it won't work) and besides which, the interface of these services would be just a HUGE PITA for any spammer.
What you WILL see though is a bunch of forged headers. The bulk of the spam I see uses not only forged "From" headers, but also forged "Message-ID" and "Received" headers and occasionally some others. To the unititated it might seem that these messages really do come from AOL or Hotmail, but if you compare the headers to a REAL AOL or Hotmail message it should become fairly clear that they are fake.
Spam is not illegal you say? Since when is sending pornography to children legal? When did it become legal to commit credit card fraud? Just how is it legal to pretend that you're some foreign government official with an "offer you can't refuse" so long as people send their bank info?
The vast majority of spam is very much illegal, always has been! It's not like breaking the law is any more or less illegal just because it's done by spam instead of some other medium.
The real problem here is enforcement. That's the problem in China, as you mentioned above, and it's also the problem in the United States, Canada, Europe and elsewhere. The problem with spam is that it's so big and so difficult to track individual spammers that most law enforcement agencies just don't see the value in it unless the spammer sends something really bad. If a spammer starts sending out lots of adds for child porn, chances are that the cops will bust them. But simply trying to commit credit card fraud seems to not be seen as a sufficiently "evil" act to warrant the sort of international investigation that would be required (and probably for good reason, the cost of such an investigation would be huge with only a limited chance of a conviction).
Unfortunately the sad fact of the matter is that we can't depend on laws and law enforcement agencies to solve the spam problem. Think about it, it's illegal to steal cars, but nearly everyone still locks their car door instead of just hoping that the cops will bust any car thief. When it comes to spam, we've got to use filters (preferably at the ISP level) and hope that the police can at least catch the worst offenders.
Chances are that the "tobacco juices" you were coming into contact with were actually pesticides that were sprayed on the plants. Tobacco has traditionally been one of the crops most heavily sprayed with pesticides, herbicides and the like. Some fairly heavy duty stuff that probably could kill off warts and cause cancer at the same time!
Of course it's not a good idea! Geez, did you look at the pictures? The voltage regulators were covered in ice after a half hour or so. PCs are NOT designed for these sorts of systems, it's unlikely that it would run for a day, let alone any significant amount of time.
Besides which the cost to buy all that equipment, get a customized motherboard, have someone mill the heatsink and attachments, etc. etc. would surely make this this a ridiculously expensive system.
However, when it comes right down to it, it sure does get the website a lot of hits, and that was the goal all along.
Re:How are we going to explaing something this sub
on
G5 vs Opteron, Finally
·
· Score: 1
If you haven't seen any documentation it's only because you haven't looked hard enough!
There have been a number of tests comparing Opteron and Athlon64 processors in 32-bit and 64-bit mode under Linux and even a few that use Windows (beta version of WinXP). Here are a few links:
First off, some SPEC CINT2000 numbers: 32-bit OS + 32-bit apps, 64-bit OS + 32-bit apps and 64-bit OS + 64-bit apps. Unfortunately there are no similar CFP2000 numbers since GCC Fortran isn't up to the task, so you end up with lots of different variables making it nearly impossible to compare.
Long story short, 64-bit support on the Opteron can and often does improve performance, even on apps that don't require lots of memory or use 64-bit integers. The extra registers help.
As for compilers, Microsoft plans on supporting AMD64 in their Visual.net 2003 compiler (beta versions are available now) and GCC supports the instruction set now. That makes up the compilers used for the vast majority of applications. As you mention, PGC is also doing a compiler, and it seems that Sun will support AMD64 with their compiler as well. Here is the AMD64 Developer Resource Kit page which lists all sorts of software with support for the AMD64 instruction set.
Interestingly enough though, they're all the same chip, or at least the same die.
Every single AMD64 chip that AMD is currently producing come from the same original die, just with different features enabled/disabled, different speed binning and even different packaging (940-pin socket vs. 754-pin socket). Even the new Athlon64 3000+ with only 512KB of cache is still the same die, just with half of it's cache disabled (thus allowing AMD to sell chips with some broken cache cells that otherwise would be thrown in the garbage).
The differences between all the chips are relatively minor, and most exist more for marketing reasons than any technical reasons.
I personally ALWAYS buy for ONLY my current options. Why? Because if a year down the road it turns out that I need an 1394b card, I'll buy it than for $25 instead of the $50 I would pay for it today (alternatively I'll have the option to use some new-fangled standard that is available than but not now). Not only am I saving money in total, I'm also spending the money later (tends to make the bean-counters happy) and I'm reducing the number of points of failure in my system by not including components that I'm not using.
Buying computer equipment now on the off chance that you MIGHT need it some time in the future is just plain dumb!
Neither chip was run with 64-bit code in this test because neither operating system supports it. OS X has a few little hacks that allow for some 64-bit integer operations, but that is of little use for the vast majority of applications. Real 64-bit systems have a 64-bit address space.
That being said, 64-bit code is generally SLOWER than 32-bit code. With 64-bit code your pointers are twice as large, so you use more memory bandwidth and more cache space. The performance hit isn't huge, but it does exist, probably about 5% slower on average.
The same is kind of true for the Opteron, except that the Opteron has a bit of an ace up it's sleave. In 64-bit mode the Opteron has twice as many registers as in 32-bit mode. Since a lack of registers is one of the major performance stumbling blocks of x86, doubling the registers boost performance by a fair bit. The end result is that 64-bit code on the Opteron is often FASTER than 32-bit code. Of course, this depends on the application. Apps that don't use many registers but lots of pointers will still be slower on the Opteron (perhaps up to 10% slower). Apps that use lots of registers can be significantly faster (30-50% faster in fairly extreme cases). Overall though it's usually about 0-5% faster on average.
Of course, as soon as you need more than ~2GB of memory per application, 64-bit code becomes rather critical. Apple will likely work on a split 32-bit/64-bit system for OS X. This way most apps can run in 32-bit mode for the higher performance, but apps that need lots of memory can run in 64-bit mode for the large address space. Linux for AMD64 already does this, though WinXP for AMD64 will be a pure 64-bit system making use of thunking to translate 32-bit system calls into 64-bit calls.
Err, to be fair to Microsoft, they already have a 64-bit version of Windows available, it's been out for a while now. However 64-bit Windows is for IA-64 (Itanium) at the moment and not the AMD64 (Opteron/Athlon64) instruction set.
My understanding is that the delay in releasing WinXP for AMD64 is mostly because Microsoft doesn't want to spend the time/money to support this distribution completely separately from their IA-32 code base. As such, it looks like they're waiting until SP2 is finished off so that they can release both versions at the same time. If they released WinXP for AMD64 now it would be sort of halfway between SP1 and SP2 and would be out of sync with the IA-32 codebase.
Not an entirely bad idea from a business standpoint (the market for AMD64 processors is quite small for the time being, and most current users really don't need/make use of the 64-bit memory addressing anyway). A bit of a pain in the ass for us consumers though.
The first Opteron servers that Sun announced are also OEMed. They showed off two servers a couple months back, one was a Newisys 2100 (1U, 2P) and the other a Newisys 4300 (3U, 4P). You can already buy the 2100 from a number of other companies (Racksaver, Appro, Angstrom, and probably a handful of others).
I haven't seen anyone selling the Newisys 4300 server yet (most companies selling 4P Opteron servers are using the Celestica model instead), but they may arrive by the time Sun starts shipping theirs.
Register renaming helps alieviate the problem, but it does not eliminate it in any way. You still end up loading, storing and decoding all the extra instructions used to shuffle the data to/from memory, even if in reality you are just hiding the data away in your renamed registers. This results in more bus contention, less available cache space and a higher load on your instruction decoders. The end result is that you're still taking a performance hit even if the data is just being hidden.
IA-32 is especially bad for registers. Not only does it have WAY fewer real registers than basically anything else out there these days, but it also has a bunch of restrictions on how those registers can be used. The end result is that you often only have 4 GPRs that you can actually use for data, resulting in a LOT of shuffling. With the AMD64 instruction set, AMD did a smart thing by not only doubling the number of GPRs, but they also removed essentially all of the restrictions of which register can be used for what. This gives you the full 16 registers to use all of the time.
This is why AMD64 code will often (usually?) be faster than IA-32 code on Opterons and Athlon64 processors even though it's 64-bit code. Despite common belief, 64-bit code is usually SLOWER than 32-bit code when all else is equal (ie with the G5) unless you're using more than ~2.0GB of memory or lots of 64-bit integers (the latter being quite rare).
Yup, the PPC 970 (G5) is quite fast at running Linpack, particularly in comparison to x86 chips. The main reason for this is that Linpack is basically just a bunch of floating point adds and multiplies, and the PPC 970 has this nifty instruction that does a floating point multiple and add all in one. On x86 this requires two separate instructions.
Some scientific computing does closely resemble Linpack's workload. Basically any time you're dealing with matricies you are almost always going to be doing lots of FP mult-adds. However, this is a VERY narrow benchmark of CPU performance.
A much better benchmark of raw CPU power is SPEC CPU2000 (though the compiler and memory subsystem play a major role here). Unfortunately Apple has chosen not to grace Spec with it's precense. So far it's only numbers released have been from the Veritest results which "proved" that the G5 was faster than a Pentium4. These results were rather unimpressive and SIGNIFICANTLY slower than the results for Opteron and P4 systems.
All benchmarks have their limitations, Linpack (used by Top500) just tends to be more limited than most. Rumor has it that a new set of high-performance computing benchmarks is in the works to replace plain old Linpack.
I don't know if the author of the article was just trying to make the mac look cheaper, or if they just weren't looking very hard (I suspect the latter), but they could have EASILY shaved $82 off the cost of the Opteron system and got 1394b support for free too boot!
For some reason they configured the Opteron with an add-in Serial ATA RAID controller, supposedly in order to better match the configuration of the Mac (which doesn't support RAID, but I digress). This added $117 to the price. However they completely ignored the motherboard upgrade option that added SATA support (no RAID) and 1394b support together for only $35.
They could also have shaved another $37 off the price by using a software modem instead of a hardware modem (though the HW modem might be a good idea for Linux users that need dial-up) or $72 off the price by not including a modem at all for those of us with broadband connections.
In the end though, the Mac is still a bit cheaper. Macs are not expensive for what you get, the problem is that you don't have much choice but to get top-end. To price out a dual-processor Opteron with similar specs to a dual-processor Mac, you'll be easily over $3000 and possibly up closer to the $3938 of the Xi computer system. However, if you don't need all those features you can easily configure yourself an Athlon64 system for SIGNIFICANTLY less.
I have absolutely no need for a modem (got an old external kicking around in case of emergancies) and have never owned any 1394b devices. Therefore, if I were configuring a PC for myself I would never bother adding either of those two options. I might also configure a cheaper video card and I probably wouldn't bother with a DVD-RW drive, though I would prefer to have two optical drives (one CD-RW and one DVD). These are all easy options on most PC configurations, but often they aren't on Mac configurations. Simply put, you have more choices on PC configurations than on Macs. If you desired setup matches that of a Mac closely, then they often offer good value for your money. If not, then they can be quite expensive for what you want.
No you haven't because OS X doesn't support 64-bit in any meaningful manner. Apple like's to claim that it's a 64-bit system because they can handle 64-bit integers through their math libraries, but that does not make it a 64-bit operating system (or 64-bit applications).
OS X provides you and your applications with a 32-bit address space. Until that is changed, it will never be a 64-bit operating system. Right now it's more like running WinNT/2K/XP in PAE mode on a 32-bit x86 processor.
The "thermal problems" with the AMD Athlons is a PERFECT example of why you should NOT read Tom's Hardware Guide! At the very least do not take the articles read at face value without verifying the facts first!
1.) Their P4 was shown to run at a constant 29C. Thermal throttling on the P4 doesn't even start until ~65 or 70C. If the chips were running at 29C, they wouldn't be throttling at all.
2.) The P4 can throttle down to an absolute minimum of 1/8th of it's clock speed, though it's set to 30-50% by default (factory setting) according to Intel's thermal design guidelines. At 30% of it's clock speed, a P4 will still consume easily 20-30W of power, which is WAY more than you can disapate with no heatsink. Yanking the heatsink off a P4 WILL cause it to crash in a very short period of time.
3.) The comment that was made that AMD's thermal sensor could only react to 1C/sec temperature changes was absolutely ridiculous and CLEARLY showed that the author was completely clueless! Such terrible performance couldn't be accomplished by incompetance along, you would really have to TRY and make it that bad!
The whole deal about the instabililties of the PIII 1.13GHz wasn't so much technically incorrect for the simple reason that there was next to no technical info provided, it was almost all just self-congradulation.
I DO judge the articles by themselves, and the articles on Tom's site generally leave a LOT to be desired. The article linked from this story seems to be mostly fluff with a few benchmarks requiring the standard (ie very large) grain of salt.
I don't know about this chip specifically, but for chips in general there would be more than just two blocks. In fact, it would probably be along the lines of 36 cells of 32K a piece. If any of these cells fail validation, you can disable them.
So long as the number of busted cells is 4 or less (just using my example numbers here), you can sell the processor with 1024KB of cache enabled. Obviously, if there are no cells that are bad you still disable 4 of them to keep the parts consistant (OEMs don't want one chip with 1024KB of cache, the next with 1056KB of cache and the next with only 992KB). If more than 4 cells are bad, you disable all but 16 of them and you've got a chip with 512KB of cache.
Intel and AMD both do this (as do others), and at various times both have had chips sold at different performance and price points depending on how much cache (or some other feature, ie hypertransport links, hyperthreading, floating point units, etc.) is enabled.
512K cache Athlon64's exist now, "Newcastle" Athlon64's are scheduled for Q1 of '04. Two different chips here, despite the fact that they'll have the same basic specs. All current Athlon64, Athlon64 FX and Opteron chips use the same die with different features enabled/disabled. The "Newcastle" is a new version of the Athlon64 die with the "extra" features removed rather than simply being disabled.
You are correct that the US does have a low personal income tax rate (not the lowest, the article you quote specifically states that Hong Kong has lower taxes), but that's only part of the story. The US corporate tax rate is actually quite high. This may seem a bit odd since one of the real selling points of business in the US used to be it's low corporate tax rate, but that is no more. Even many of the countries that are often called "socialist" or even "communist" countries by many Americans, ie Canada, Sweden and Norway, have lower corporate taxes than the US.
Here are some numbers for 2002. As you can see, only Italy, Belgium and Japan have higher corporate tax rates than the US. The main thrust of the problem is that the US corporate tax system hasn't really been updated in ages while most other countries have reduced their tax rate singificantly since the mid-90's. The above article also briefly makes mention of corporate tax avoidance, something that seems to happen in the US more than most other countries. It suggests that the somewhat dated corporate tax laws almost tend to encourage the "creative accounting" practices, with Enron being put forth as the obvious example.
Cost of living isn't the answer that you're looking for, it's the lower cost of doing buisness that is pushing companies to countries like India and China. Certainly the wages of the workers has a lot to do with it, but that's far from the only thing. If low worker wages were the only requirement for these things then everyone would move their business to Africa where wages tend to be the lowest. On the flip side, we also aren't seeing the rates of job loss in places like Hong Kong where the cost of living and workers wages are very high.
It's more likely that Hotmail has just been upgraded to Brightmail 5.5, which was just release a week ago (or possibly they just upgraded to the older 5.0 release from what they were running before). Each new release tends to increase the amount of spam that is blocked by hotmail.
Interesting point of note, if you think that the 200 spams per day is a lot, it was only a fraction of the spam that actually SENT to your account. Microsoft blocks a ridiculous quantity of spam on their hotmail servers. The problem is that they get targeted by spammers FAR more than any other service out there (with the possible exception of AOL, who also blocks a ridiculous quantity of spam). Since baysian-style blocking is impossible on a large multi-user system (unless you want VERY high false positive rates), and heuristic-style blocking is extremely difficult (people actually opt-in to things that look incredibly spammy), it's really tough to filter everything. Combine that with a single system where you can get a very consistant and measured response. Then add in the fact that there have been on-going dictionary attacks (testing every possible combination of e-mail addresses to find the valid ones) against Hotmail for a year or more, and you have the reason why you get so much spam.
A weak federal law that is never enforced is no better or worse than a strong state law that is never enforced, or no law at all for that matter.
The problem with spam is NOT the lack of laws! If we got rid of the spam that was blatently illegal without even worrying about any anti-spam laws, the flood of spam would be slowed to a trickle. It's not like sending bestiality porn to minors was legal before this law came into effect. Selling prescription drugs without prescriptions has never been legal. Trying to defraud someone by pretneding to be some Nigerian diplomat has been and still is fraud, regardless of whether it's spam.
Unless the law is enforced it won't make one lick of difference.
To me, this says that the Opteron is performing about 1.5 times better, clock cycle for clock cycle
Whoop-dee-shit! Who the hell cares what clock speed the chip runs at. The only thing that is important is either the maximum performance where cost is no object or the maximum performance for a given price point (and also sometimes the maximum performance for a given power consumption level). How the chip manages to achieve that performance is of basically no relevance at all.
The P4/Xeon's NetBurst core was simply designed to clock high. On a 180nm fab process Intel managed to clock their P4 up to 2.0GHz with little trouble at all. On the same 180nm fab process, Intel was only able to get their PIII up to 1.13GHz, and that took quite a bit of work (the first 1.13GHz PIIIs actually had to be recalled). AMD's Athlon was designed to clock higher than the PIII, but not as high as the P4, so it managed to get up to 1.73GHz if my memory serves me correctly.
We're seeing the same thing now with current 130nm manufacturering processes. The P4 and Xeon are able to clokc to 3.2GHz, while AMD has only managed to clock the AthlonXP up to 2.33GHz (and that only in small quantities, only available through one specific HP machine). The Opteron/Athlon64 core might end up clocking a bit higher (especailly since they're using a very advanced 130nm SOI process as compared to the bulk CMOS process that was used for the AthlonXP and all of Intel's processors), but for the time being it's limited to 2.2GHz. It's likely that AMD will be able to hit 2.4GHz and maybe even 2.6GHz, but that's about it. The chip just wasn't designed to clock as high as the P4/Xeon.
Design decisions were made by both AMD and Intel. Intel chose a sort of "narrow and fast" design, and took a "wide but slow" design so to speak.
OS X has only VERY half-assed 64-bit support. It's support is barely better than Intel's PAE mode which has been supported in Windows for years (since NT4.0). The Macs have the minor advantage of being able to handle 64-bit integers through math libraries, but while that's nice, it's really a very distant secondary benefit of 64-bit processors.
To have proper 64-bit support you need to be able to give the application a flat 64-bit virtual address space to work with. OS X does not do this in any way, shape or form.
Don't get me wrong, OS X is a good operating system, Apple really seems to have taking the right approach to it's design IMO. But it's definitely not a 64-bit OS.
In the near future? Not unless you use a very broad definition of "near future". The main reason for this is quite simply that 128-bit CPUs would be SLOW as compared to 64-bit chips and add absolutely no meaningful features.
Every time you increase your bitness of the machine, you increase the size of your pointers, and bigger pointers take up more memory, take longer to load from memory (or store to memory) and they fill up your cache faster. All else being equal, 64-bit code is usually about 5% slower than 32-bit code, and 128-bit code would probably be 10% slower than 64-bit code. Of course, all is rarely equal with 32 vs. 64-bit code (ie the AMD64 instruction set doubles the number of registers when running in 64-bit mode, and that usually more than makes up for the 5% performance hit of running 64-bit code and actually makes things faster since x86 is so register-starved). With Apple's G5 though we might see this 64-bit performance hit. The IBM PowerPC 970 and the PPC arechitecture in general is exactly the same in 64-bit mode as in 32-bit mode (warning: before anyone jumps on me for this, I'm kind of oversimplifying here:> ).
There are, of course, exceptions to this rule. Any time you need to access more than about 2GB of memory, then 64-bit is the only way to go. While 32-bit chips can, at least theoretically, support up to 4GB of memory, things start getting really messy by around 2GB and typically you can't actually use more than 3GB. Quite a while down the line (40+ years?), 64-bit processors might run into a similar memory problem and then 128-bit chips will be worthwhile. However, since 64-bit chips can natively address 10^19 bytes of memory, this is still quite a ways off even if we continue the trend of doubling memory requirements every 2 years or so.
There is also the issue of large integers. If you need integers with a range of more than 4 billion (maximum that 32-bit allows), then using 64-bit integers is faster. You CAN deal with 64-bit integers on a 32-bit chip, it just takes at least 3 times as long. If you only need to deal with one 64-bit integer every ten thousand instructions, than this advantage is negligible, but if you deal with very large integers regularly it will help performance. The advantage of using 64-bit integers is very rare though (remember that most complicated calculations use floating point numbers instead of integers). Going from 64-bit to 128-bit integers helps even less. It's got to be extrodinarily rare that an integer range of greater than 10^19 is required.
In short, the need for 64-bit CPUs in here now for some and will be very beneficial for many people in the next 2-5 years. The need for 128-bit chips is pretty much non-existant now and likely won't exist in any meaningful quantity for 30+ years. Beyond that, who knows.
Ohh, and before anyone makes some clueless comment about how game consoles are already 128-bit, they aren't. They are measuring a totally different bitness related to video processing. The CPUs of the three major consoles out there today are all 32-bit. The Nintendo64 used a 64-bit CPU, mainly for marketing purposes, but it was rather useless from a technical point of view.
Err, says who? IEEE 754 standard floating point defines a single precision floating point number as 32-bits and a double percision floating point number as 64-bits. In fact, x86 is about the only architecture I can think of off the top of my head that even allows 80-bit floating point numbers, but they are pretty much never used.
Yes, 80-bit and perhaps even 96-bit floating point numbers DO exist, but they are very rare in the real world.
Slashdot Mirror
On my own personal e-mail address I've received a grand total of ZERO spams in the ~2 years I've used it. I'm VERY careful about where that address goes. Even fairly legit companies (ie my bank) get a secondary address, and the really sketchy companies get a spamgourmet.com address if they need an e-mail address.
:> ). That works out to more than 10 spams per day, and I'm pretty certain that about half of the spam sent to me bounced because the mailbox was full. Not quite the 40/day, but not too far off.
However, I just decided to check my ISP e-mail account. I signed up for this cable modem service in October and had the account assigned to me then. I have never once used this account for ANY reason. I hadn't even opened the mail box before today. So what did I see? A mailbox that had hit it's limit at 1,000 messages, of which about 975 were spam (the other 25 were messages from the ISP warning me that my mailbox was full
Long story short, no matter how smart you are, you can still get a lot of spam. It's even worse for companies with a web site and contact e-mails. Any e-mail address posted to a website will be harvested by spammers in a matter of days and the mailbox will be bombarded.
I know that this was a joke and all, but... The amount of spam that comes out of AOL, Hotmail, Yahoo and all of the other major e-mail providers combined is so tiny as to be negligible. All the major providers do block outgoing spam (try sending 500 message all at once through one of them, it won't work) and besides which, the interface of these services would be just a HUGE PITA for any spammer.
What you WILL see though is a bunch of forged headers. The bulk of the spam I see uses not only forged "From" headers, but also forged "Message-ID" and "Received" headers and occasionally some others. To the unititated it might seem that these messages really do come from AOL or Hotmail, but if you compare the headers to a REAL AOL or Hotmail message it should become fairly clear that they are fake.
Spam is not illegal you say? Since when is sending pornography to children legal? When did it become legal to commit credit card fraud? Just how is it legal to pretend that you're some foreign government official with an "offer you can't refuse" so long as people send their bank info?
The vast majority of spam is very much illegal, always has been! It's not like breaking the law is any more or less illegal just because it's done by spam instead of some other medium.
The real problem here is enforcement. That's the problem in China, as you mentioned above, and it's also the problem in the United States, Canada, Europe and elsewhere. The problem with spam is that it's so big and so difficult to track individual spammers that most law enforcement agencies just don't see the value in it unless the spammer sends something really bad. If a spammer starts sending out lots of adds for child porn, chances are that the cops will bust them. But simply trying to commit credit card fraud seems to not be seen as a sufficiently "evil" act to warrant the sort of international investigation that would be required (and probably for good reason, the cost of such an investigation would be huge with only a limited chance of a conviction).
Unfortunately the sad fact of the matter is that we can't depend on laws and law enforcement agencies to solve the spam problem. Think about it, it's illegal to steal cars, but nearly everyone still locks their car door instead of just hoping that the cops will bust any car thief. When it comes to spam, we've got to use filters (preferably at the ISP level) and hope that the police can at least catch the worst offenders.
Chances are that the "tobacco juices" you were coming into contact with were actually pesticides that were sprayed on the plants. Tobacco has traditionally been one of the crops most heavily sprayed with pesticides, herbicides and the like. Some fairly heavy duty stuff that probably could kill off warts and cause cancer at the same time!
Of course it's not a good idea! Geez, did you look at the pictures? The voltage regulators were covered in ice after a half hour or so. PCs are NOT designed for these sorts of systems, it's unlikely that it would run for a day, let alone any significant amount of time.
Besides which the cost to buy all that equipment, get a customized motherboard, have someone mill the heatsink and attachments, etc. etc. would surely make this this a ridiculously expensive system.
However, when it comes right down to it, it sure does get the website a lot of hits, and that was the goal all along.
If you haven't seen any documentation it's only because you haven't looked hard enough!
There have been a number of tests comparing Opteron and Athlon64 processors in 32-bit and 64-bit mode under Linux and even a few that use Windows (beta version of WinXP). Here are a few links:
First off, some SPEC CINT2000 numbers: 32-bit OS + 32-bit apps, 64-bit OS + 32-bit apps and 64-bit OS + 64-bit apps. Unfortunately there are no similar CFP2000 numbers since GCC Fortran isn't up to the task, so you end up with lots of different variables making it nearly impossible to compare.
There is also this areticle at Ace's Hardware, and this little bit on Anandtech. Other tests exist.
Long story short, 64-bit support on the Opteron can and often does improve performance, even on apps that don't require lots of memory or use 64-bit integers. The extra registers help.
As for compilers, Microsoft plans on supporting AMD64 in their Visual.net 2003 compiler (beta versions are available now) and GCC supports the instruction set now. That makes up the compilers used for the vast majority of applications. As you mention, PGC is also doing a compiler, and it seems that Sun will support AMD64 with their compiler as well. Here is the AMD64 Developer Resource Kit page which lists all sorts of software with support for the AMD64 instruction set.
Interestingly enough though, they're all the same chip, or at least the same die.
Every single AMD64 chip that AMD is currently producing come from the same original die, just with different features enabled/disabled, different speed binning and even different packaging (940-pin socket vs. 754-pin socket). Even the new Athlon64 3000+ with only 512KB of cache is still the same die, just with half of it's cache disabled (thus allowing AMD to sell chips with some broken cache cells that otherwise would be thrown in the garbage).
The differences between all the chips are relatively minor, and most exist more for marketing reasons than any technical reasons.
I personally ALWAYS buy for ONLY my current options. Why? Because if a year down the road it turns out that I need an 1394b card, I'll buy it than for $25 instead of the $50 I would pay for it today (alternatively I'll have the option to use some new-fangled standard that is available than but not now). Not only am I saving money in total, I'm also spending the money later (tends to make the bean-counters happy) and I'm reducing the number of points of failure in my system by not including components that I'm not using.
Buying computer equipment now on the off chance that you MIGHT need it some time in the future is just plain dumb!
Neither chip was run with 64-bit code in this test because neither operating system supports it. OS X has a few little hacks that allow for some 64-bit integer operations, but that is of little use for the vast majority of applications. Real 64-bit systems have a 64-bit address space.
That being said, 64-bit code is generally SLOWER than 32-bit code. With 64-bit code your pointers are twice as large, so you use more memory bandwidth and more cache space. The performance hit isn't huge, but it does exist, probably about 5% slower on average.
The same is kind of true for the Opteron, except that the Opteron has a bit of an ace up it's sleave. In 64-bit mode the Opteron has twice as many registers as in 32-bit mode. Since a lack of registers is one of the major performance stumbling blocks of x86, doubling the registers boost performance by a fair bit. The end result is that 64-bit code on the Opteron is often FASTER than 32-bit code. Of course, this depends on the application. Apps that don't use many registers but lots of pointers will still be slower on the Opteron (perhaps up to 10% slower). Apps that use lots of registers can be significantly faster (30-50% faster in fairly extreme cases). Overall though it's usually about 0-5% faster on average.
Of course, as soon as you need more than ~2GB of memory per application, 64-bit code becomes rather critical. Apple will likely work on a split 32-bit/64-bit system for OS X. This way most apps can run in 32-bit mode for the higher performance, but apps that need lots of memory can run in 64-bit mode for the large address space. Linux for AMD64 already does this, though WinXP for AMD64 will be a pure 64-bit system making use of thunking to translate 32-bit system calls into 64-bit calls.
Err, to be fair to Microsoft, they already have a 64-bit version of Windows available, it's been out for a while now. However 64-bit Windows is for IA-64 (Itanium) at the moment and not the AMD64 (Opteron/Athlon64) instruction set.
My understanding is that the delay in releasing WinXP for AMD64 is mostly because Microsoft doesn't want to spend the time/money to support this distribution completely separately from their IA-32 code base. As such, it looks like they're waiting until SP2 is finished off so that they can release both versions at the same time. If they released WinXP for AMD64 now it would be sort of halfway between SP1 and SP2 and would be out of sync with the IA-32 codebase.
Not an entirely bad idea from a business standpoint (the market for AMD64 processors is quite small for the time being, and most current users really don't need/make use of the 64-bit memory addressing anyway). A bit of a pain in the ass for us consumers though.
The first Opteron servers that Sun announced are also OEMed. They showed off two servers a couple months back, one was a Newisys 2100 (1U, 2P) and the other a Newisys 4300 (3U, 4P). You can already buy the 2100 from a number of other companies (Racksaver, Appro, Angstrom, and probably a handful of others).
I haven't seen anyone selling the Newisys 4300 server yet (most companies selling 4P Opteron servers are using the Celestica model instead), but they may arrive by the time Sun starts shipping theirs.
Register renaming helps alieviate the problem, but it does not eliminate it in any way. You still end up loading, storing and decoding all the extra instructions used to shuffle the data to/from memory, even if in reality you are just hiding the data away in your renamed registers. This results in more bus contention, less available cache space and a higher load on your instruction decoders. The end result is that you're still taking a performance hit even if the data is just being hidden.
IA-32 is especially bad for registers. Not only does it have WAY fewer real registers than basically anything else out there these days, but it also has a bunch of restrictions on how those registers can be used. The end result is that you often only have 4 GPRs that you can actually use for data, resulting in a LOT of shuffling. With the AMD64 instruction set, AMD did a smart thing by not only doubling the number of GPRs, but they also removed essentially all of the restrictions of which register can be used for what. This gives you the full 16 registers to use all of the time.
This is why AMD64 code will often (usually?) be faster than IA-32 code on Opterons and Athlon64 processors even though it's 64-bit code. Despite common belief, 64-bit code is usually SLOWER than 32-bit code when all else is equal (ie with the G5) unless you're using more than ~2.0GB of memory or lots of 64-bit integers (the latter being quite rare).
Yup, the PPC 970 (G5) is quite fast at running Linpack, particularly in comparison to x86 chips. The main reason for this is that Linpack is basically just a bunch of floating point adds and multiplies, and the PPC 970 has this nifty instruction that does a floating point multiple and add all in one. On x86 this requires two separate instructions.
Some scientific computing does closely resemble Linpack's workload. Basically any time you're dealing with matricies you are almost always going to be doing lots of FP mult-adds. However, this is a VERY narrow benchmark of CPU performance.
A much better benchmark of raw CPU power is SPEC CPU2000 (though the compiler and memory subsystem play a major role here). Unfortunately Apple has chosen not to grace Spec with it's precense. So far it's only numbers released have been from the Veritest results which "proved" that the G5 was faster than a Pentium4. These results were rather unimpressive and SIGNIFICANTLY slower than the results for Opteron and P4 systems.
All benchmarks have their limitations, Linpack (used by Top500) just tends to be more limited than most. Rumor has it that a new set of high-performance computing benchmarks is in the works to replace plain old Linpack.
I don't know if the author of the article was just trying to make the mac look cheaper, or if they just weren't looking very hard (I suspect the latter), but they could have EASILY shaved $82 off the cost of the Opteron system and got 1394b support for free too boot!
For some reason they configured the Opteron with an add-in Serial ATA RAID controller, supposedly in order to better match the configuration of the Mac (which doesn't support RAID, but I digress). This added $117 to the price. However they completely ignored the motherboard upgrade option that added SATA support (no RAID) and 1394b support together for only $35.
They could also have shaved another $37 off the price by using a software modem instead of a hardware modem (though the HW modem might be a good idea for Linux users that need dial-up) or $72 off the price by not including a modem at all for those of us with broadband connections.
In the end though, the Mac is still a bit cheaper. Macs are not expensive for what you get, the problem is that you don't have much choice but to get top-end. To price out a dual-processor Opteron with similar specs to a dual-processor Mac, you'll be easily over $3000 and possibly up closer to the $3938 of the Xi computer system. However, if you don't need all those features you can easily configure yourself an Athlon64 system for SIGNIFICANTLY less.
I have absolutely no need for a modem (got an old external kicking around in case of emergancies) and have never owned any 1394b devices. Therefore, if I were configuring a PC for myself I would never bother adding either of those two options. I might also configure a cheaper video card and I probably wouldn't bother with a DVD-RW drive, though I would prefer to have two optical drives (one CD-RW and one DVD). These are all easy options on most PC configurations, but often they aren't on Mac configurations. Simply put, you have more choices on PC configurations than on Macs. If you desired setup matches that of a Mac closely, then they often offer good value for your money. If not, then they can be quite expensive for what you want.
No you haven't because OS X doesn't support 64-bit in any meaningful manner. Apple like's to claim that it's a 64-bit system because they can handle 64-bit integers through their math libraries, but that does not make it a 64-bit operating system (or 64-bit applications).
OS X provides you and your applications with a 32-bit address space. Until that is changed, it will never be a 64-bit operating system. Right now it's more like running WinNT/2K/XP in PAE mode on a 32-bit x86 processor.
The "thermal problems" with the AMD Athlons is a PERFECT example of why you should NOT read Tom's Hardware Guide! At the very least do not take the articles read at face value without verifying the facts first!
1.) Their P4 was shown to run at a constant 29C. Thermal throttling on the P4 doesn't even start until ~65 or 70C. If the chips were running at 29C, they wouldn't be throttling at all.
2.) The P4 can throttle down to an absolute minimum of 1/8th of it's clock speed, though it's set to 30-50% by default (factory setting) according to Intel's thermal design guidelines. At 30% of it's clock speed, a P4 will still consume easily 20-30W of power, which is WAY more than you can disapate with no heatsink. Yanking the heatsink off a P4 WILL cause it to crash in a very short period of time.
3.) The comment that was made that AMD's thermal sensor could only react to 1C/sec temperature changes was absolutely ridiculous and CLEARLY showed that the author was completely clueless! Such terrible performance couldn't be accomplished by incompetance along, you would really have to TRY and make it that bad!
The whole deal about the instabililties of the PIII 1.13GHz wasn't so much technically incorrect for the simple reason that there was next to no technical info provided, it was almost all just self-congradulation.
I DO judge the articles by themselves, and the articles on Tom's site generally leave a LOT to be desired. The article linked from this story seems to be mostly fluff with a few benchmarks requiring the standard (ie very large) grain of salt.
I don't know about this chip specifically, but for chips in general there would be more than just two blocks. In fact, it would probably be along the lines of 36 cells of 32K a piece. If any of these cells fail validation, you can disable them.
So long as the number of busted cells is 4 or less (just using my example numbers here), you can sell the processor with 1024KB of cache enabled. Obviously, if there are no cells that are bad you still disable 4 of them to keep the parts consistant (OEMs don't want one chip with 1024KB of cache, the next with 1056KB of cache and the next with only 992KB). If more than 4 cells are bad, you disable all but 16 of them and you've got a chip with 512KB of cache.
Intel and AMD both do this (as do others), and at various times both have had chips sold at different performance and price points depending on how much cache (or some other feature, ie hypertransport links, hyperthreading, floating point units, etc.) is enabled.
512K cache Athlon64's exist now, "Newcastle" Athlon64's are scheduled for Q1 of '04. Two different chips here, despite the fact that they'll have the same basic specs. All current Athlon64, Athlon64 FX and Opteron chips use the same die with different features enabled/disabled. The "Newcastle" is a new version of the Athlon64 die with the "extra" features removed rather than simply being disabled.
You are correct that the US does have a low personal income tax rate (not the lowest, the article you quote specifically states that Hong Kong has lower taxes), but that's only part of the story. The US corporate tax rate is actually quite high. This may seem a bit odd since one of the real selling points of business in the US used to be it's low corporate tax rate, but that is no more. Even many of the countries that are often called "socialist" or even "communist" countries by many Americans, ie Canada, Sweden and Norway, have lower corporate taxes than the US.
Here are some numbers for 2002. As you can see, only Italy, Belgium and Japan have higher corporate tax rates than the US. The main thrust of the problem is that the US corporate tax system hasn't really been updated in ages while most other countries have reduced their tax rate singificantly since the mid-90's. The above article also briefly makes mention of corporate tax avoidance, something that seems to happen in the US more than most other countries. It suggests that the somewhat dated corporate tax laws almost tend to encourage the "creative accounting" practices, with Enron being put forth as the obvious example.
Cost of living isn't the answer that you're looking for, it's the lower cost of doing buisness that is pushing companies to countries like India and China. Certainly the wages of the workers has a lot to do with it, but that's far from the only thing. If low worker wages were the only requirement for these things then everyone would move their business to Africa where wages tend to be the lowest. On the flip side, we also aren't seeing the rates of job loss in places like Hong Kong where the cost of living and workers wages are very high.
It's more likely that Hotmail has just been upgraded to Brightmail 5.5, which was just release a week ago (or possibly they just upgraded to the older 5.0 release from what they were running before). Each new release tends to increase the amount of spam that is blocked by hotmail.
Interesting point of note, if you think that the 200 spams per day is a lot, it was only a fraction of the spam that actually SENT to your account. Microsoft blocks a ridiculous quantity of spam on their hotmail servers. The problem is that they get targeted by spammers FAR more than any other service out there (with the possible exception of AOL, who also blocks a ridiculous quantity of spam). Since baysian-style blocking is impossible on a large multi-user system (unless you want VERY high false positive rates), and heuristic-style blocking is extremely difficult (people actually opt-in to things that look incredibly spammy), it's really tough to filter everything. Combine that with a single system where you can get a very consistant and measured response. Then add in the fact that there have been on-going dictionary attacks (testing every possible combination of e-mail addresses to find the valid ones) against Hotmail for a year or more, and you have the reason why you get so much spam.
A weak federal law that is never enforced is no better or worse than a strong state law that is never enforced, or no law at all for that matter.
The problem with spam is NOT the lack of laws! If we got rid of the spam that was blatently illegal without even worrying about any anti-spam laws, the flood of spam would be slowed to a trickle. It's not like sending bestiality porn to minors was legal before this law came into effect. Selling prescription drugs without prescriptions has never been legal. Trying to defraud someone by pretneding to be some Nigerian diplomat has been and still is fraud, regardless of whether it's spam.
Unless the law is enforced it won't make one lick of difference.
To me, this says that the Opteron is performing about 1.5 times better, clock cycle for clock cycle
Whoop-dee-shit! Who the hell cares what clock speed the chip runs at. The only thing that is important is either the maximum performance where cost is no object or the maximum performance for a given price point (and also sometimes the maximum performance for a given power consumption level). How the chip manages to achieve that performance is of basically no relevance at all.
The P4/Xeon's NetBurst core was simply designed to clock high. On a 180nm fab process Intel managed to clock their P4 up to 2.0GHz with little trouble at all. On the same 180nm fab process, Intel was only able to get their PIII up to 1.13GHz, and that took quite a bit of work (the first 1.13GHz PIIIs actually had to be recalled). AMD's Athlon was designed to clock higher than the PIII, but not as high as the P4, so it managed to get up to 1.73GHz if my memory serves me correctly.
We're seeing the same thing now with current 130nm manufacturering processes. The P4 and Xeon are able to clokc to 3.2GHz, while AMD has only managed to clock the AthlonXP up to 2.33GHz (and that only in small quantities, only available through one specific HP machine). The Opteron/Athlon64 core might end up clocking a bit higher (especailly since they're using a very advanced 130nm SOI process as compared to the bulk CMOS process that was used for the AthlonXP and all of Intel's processors), but for the time being it's limited to 2.2GHz. It's likely that AMD will be able to hit 2.4GHz and maybe even 2.6GHz, but that's about it. The chip just wasn't designed to clock as high as the P4/Xeon.
Design decisions were made by both AMD and Intel. Intel chose a sort of "narrow and fast" design, and took a "wide but slow" design so to speak.
OS X has only VERY half-assed 64-bit support. It's support is barely better than Intel's PAE mode which has been supported in Windows for years (since NT4.0). The Macs have the minor advantage of being able to handle 64-bit integers through math libraries, but while that's nice, it's really a very distant secondary benefit of 64-bit processors.
To have proper 64-bit support you need to be able to give the application a flat 64-bit virtual address space to work with. OS X does not do this in any way, shape or form.
Don't get me wrong, OS X is a good operating system, Apple really seems to have taking the right approach to it's design IMO. But it's definitely not a 64-bit OS.
In the near future? Not unless you use a very broad definition of "near future". The main reason for this is quite simply that 128-bit CPUs would be SLOW as compared to 64-bit chips and add absolutely no meaningful features.
:> ).
Every time you increase your bitness of the machine, you increase the size of your pointers, and bigger pointers take up more memory, take longer to load from memory (or store to memory) and they fill up your cache faster. All else being equal, 64-bit code is usually about 5% slower than 32-bit code, and 128-bit code would probably be 10% slower than 64-bit code. Of course, all is rarely equal with 32 vs. 64-bit code (ie the AMD64 instruction set doubles the number of registers when running in 64-bit mode, and that usually more than makes up for the 5% performance hit of running 64-bit code and actually makes things faster since x86 is so register-starved). With Apple's G5 though we might see this 64-bit performance hit. The IBM PowerPC 970 and the PPC arechitecture in general is exactly the same in 64-bit mode as in 32-bit mode (warning: before anyone jumps on me for this, I'm kind of oversimplifying here
There are, of course, exceptions to this rule. Any time you need to access more than about 2GB of memory, then 64-bit is the only way to go. While 32-bit chips can, at least theoretically, support up to 4GB of memory, things start getting really messy by around 2GB and typically you can't actually use more than 3GB. Quite a while down the line (40+ years?), 64-bit processors might run into a similar memory problem and then 128-bit chips will be worthwhile. However, since 64-bit chips can natively address 10^19 bytes of memory, this is still quite a ways off even if we continue the trend of doubling memory requirements every 2 years or so.
There is also the issue of large integers. If you need integers with a range of more than 4 billion (maximum that 32-bit allows), then using 64-bit integers is faster. You CAN deal with 64-bit integers on a 32-bit chip, it just takes at least 3 times as long. If you only need to deal with one 64-bit integer every ten thousand instructions, than this advantage is negligible, but if you deal with very large integers regularly it will help performance. The advantage of using 64-bit integers is very rare though (remember that most complicated calculations use floating point numbers instead of integers). Going from 64-bit to 128-bit integers helps even less. It's got to be extrodinarily rare that an integer range of greater than 10^19 is required.
In short, the need for 64-bit CPUs in here now for some and will be very beneficial for many people in the next 2-5 years. The need for 128-bit chips is pretty much non-existant now and likely won't exist in any meaningful quantity for 30+ years. Beyond that, who knows.
Ohh, and before anyone makes some clueless comment about how game consoles are already 128-bit, they aren't. They are measuring a totally different bitness related to video processing. The CPUs of the three major consoles out there today are all 32-bit. The Nintendo64 used a 64-bit CPU, mainly for marketing purposes, but it was rather useless from a technical point of view.
Err, says who? IEEE 754 standard floating point defines a single precision floating point number as 32-bits and a double percision floating point number as 64-bits. In fact, x86 is about the only architecture I can think of off the top of my head that even allows 80-bit floating point numbers, but they are pretty much never used.
Yes, 80-bit and perhaps even 96-bit floating point numbers DO exist, but they are very rare in the real world.