That's the thermal design power. As far as I know the single core Athlon 64s only consume 40+W.
They _never_ guzzle 90W when running within specs.
While people were confused or puzzled about the 83W/90WTDP spec _across_the_board for all CPUs no matter what clock speed. AMD was looking ahead when they announced their 64 bit CPUs.
I believe they wanted to ensure that manufacturers won't skimp and make designs that only cope with 50W. They wanted everyone to make designs which allow users to upgrade by just dropping in a _dual_core_ CPU.
They're written in the notorious "buffer overflow" languages, so most people will have these problems for the near future.
Meanwhile what you can do is to run each program as a different more restricted user.
On windows XP, run IE with using a shortcut with a runas with savecred (you should modify those in the start menu and quick launch too), and set it so it runs using a very restricted account. The restricted account should either have access to your bookmarks, history and temporary files, or you should run it so it changes to the restricted user's home directory and you allow your main account access to the restricted user's home directory.
Look up the runas command for the options. It'll be more convenient on WinXP since there's the savecred feature.
On UNIX, I think you can use sudo or something similar. Sudo to a restricted account and then run the browser.
This way, if your program gets exploited it can only ruin what the restricted user has access to, it can't easily touch the rest of the system.
Exploits can still theoretically touch the rest of the system since there's stuff like shatter attacks (for windows, not sure about KDE/GNOME), and I'm sure display drivers have bugs of their own and they run in ring 0 (on windows).
But if you do this it raises the bar significantly.
There are other options if you're really paranoid and don't mind the extra effort.
I'm saying even if the unit tests work perfectly, you can't use them if the program you want to test is badly broken for that particular area.
It'll just tell you something you know already.
It may be broken by a change in the behaviour of an external system. There's a small hope that the comments might actually help - e.g. the programmer comments: "WARNING!! Change to +1 and remove this comment if XYZ fix bug #1234".
"If what's written in your comment needs to be translated manually into something else, then you should write code to translate it automatically"
But the comment isn't code. And you're missing my point completely.
Don't tell me you'd want a program to automatically _ensure_ (not _verify_) that your CRCs/checksums are always correct.
As for having multiple representations of the same fact, that's called redundancy. And it's not always a bad thing - go ask people who buy RAID systems or intentionally have 3 different computers running _different_ software from different vendors that's supposed to do the same thing.
We are living in an imperfect world and dealing with many different imperfect people and systems. You're going to have to say the "same" thing many times in different ways so that you are more certain of getting the point across eventually.
There will be differences and inconsistencies but the more times you intentionally say something that is consistent, then the more important you regard it. The other stuff which is said only a few times and is inconsistent should be not so important/critical.
That goes for the spec, the documentation, the comments, the unit tests etc.
The myth that the most informed companies spend the most on buying info from analyst firms was debunked resoundingly.
It was found that the most informed companies spent _less_ than the average and that the lowest spending companies were the most informed.
I sure can come up with the bullshit too eh?:)
Re:Increase Automation = Increast $ of mistakes
on
Vehicles of Tomorrow?
·
· Score: 1
I work in the field of IT security and I disagree. Automation isn't the culprit here.
The culprit is people who pick/make systems that do not _fail_ well.
The naive will pick the system that works best. (Or the cheapest;) ). That is not always the best choice.
For critical systems, often a suboptimal system that fails well is a better choice. Better than one that works _beautifully_ when everything goes according to the marketing brochure (or everything is near the specs), but fails catastrophically when something goes wrong.
Think of a suspension of a car, which is better? A suspension that makes noise and sags as it gets worn, or one that is perfect till the day it snaps?
You can have automated systems that fail gracefully. They may cost more though. That's like sticking a few monitors to the brittle-failing suspension to make sure you change it before it fails catastrophically at the very moment you need it to be around (coz of the higher stresses). Heck you might even have it artificially sag and squeak, if the driver is stupid enough not to understand the warnings etc.
Most kids minds "set"/harden by the time they are 12. So if you want to get anything into their minds _fast_ you have to start early.
If your kids aren't learning the fundamentals at age 3-5 they're have difficulty fitting the rest in before the usual growing processes kick in and their brains "harden" - apparently there's actually a significant brain cell die-off at that point.
I'd suggest teaching the kids what YOU think matters. Coz otherwise MTV and friends are going to try to teach the kids what MTV et all think matters anyway.
But hey you are free to teach your kids mostly nothing. Others will gladly step right up to fill in the gaps in your "syllabus". Good luck.
What's the status of the various drivers esp server related? Network, mass storage (SCSI, SATA, ATAPI, ATA)?
Well my competitive edge is learning things fast. So I'll go learn it when I need to;).
Plus I find it more fun to learn about tons of new features rather than learn about tons of bugs which would be fixed in the "real release". Grrr.
I can then summarize: "Are you using at least release X? No? This release is not suitable for production use- upgrade!".
Coz if I started using the bleeding edge stuff I'd probably get too annoyed. I hard crashed an iMac during the launch of the first models, dunno how - just moved the mouse pointer around and clicked the browser here and there, and within a minute or two - locked up. I did something similar to an Atari ST too (and it wasn't bleeding edge by that time).
So if you don't mind, I'll wait for you all to find most of the "dumb" bugs first;).
Unit tests might sometimes not work (or give useful results) when the program isn't working - e.g. badly broken. Whereas the comments could still be useful in those cases (maybe even more so;) ).
And if you are looking at the code, means you are going to be spending time with the code anyway, so the comments are a nice and handy reference.
I don't think you'd need comments everywhere - at least for most code - since most code is just run of the mill. Comments would be useful if you are doing something exceptional, or something important. e.g. "This weird stuff is to work-around bug #1467 in version x.y.z of software ABC".
Sure you should write documentation for that and refer to the documentation. But it is handier to have the comments around as well.
Yeah, but nowhere did I suggest duplicating the code. I said it should be like a CRC (CRCs don't duplicate the data), and you know something is wrong if the "CRC" isn't consistent.
He said that was a bad idea, and talked about saying the same thing twice.
So I was curious to see whether he couldn't read/think properly or if he actually had something interesting to say. Or both.
I watched the stanford video presentation by the AMD guy and they claimed that going 16 registers (additional 8) got most of the benefits for most apps, whereas going 32 (additional 24) only gave a bit more benefit.
An explicit 32 register x86 would cost signficantly more for the reasons you mention. So AMD were lucky that 16 was good enough (according to them at least).
I recently bought a barton 2500+ and it's often < 50+ degrees. The mboard is 36-38 degrees C - I'm in the tropics.
I've got an older Barton 2500+ (the one that came with an unlocked multiplier) in another machine that runs 24/7 and that's at 58.5 degrees - mboard is 38 degrees C. I haven't cleaned the CPU fan for a while tho.
Thing is, often for programs where performance really matters, the relevant routines are optimized to use all the available FP+int units for the target architecture. At least this is true for many games.
I don't see how HT will help much in these cases and it might even be counterproductive.
Of course there are always cases where performance matters but they haven't got around to optimizing (e.g. OpenSSL).
As for programs where performance doesn't matter -it doesn't matter right?:).
They should have done a make -j 4 test or something, with HT and without HT.
Quad opterons scale a LOT better. They make most present quad xeons look pretty bad. There are few reasons to buy a quad xeon server - often it is better to buy two dual xeons. But quad opterons appear to be a different matter.
You were using really old and out of date stuff. No surprise you noticed the slowdowns.
While 64 bit for RISC stuff often makes things slower, we're talking x86 here- this is a different thing.
The AMD64 64 bit mode also adds 8 more registers, this is what helps the compilers make things faster than normal 32 bit stuff. As for why only 8 more, the AMD people did their homework. 8 more would give more bang for buck compared to 24 more.
I'd encourage people like him to use the 64 bit stuff now, coz I might want to use it next year... Without the bleeding edge people finding the common/"D'oh" bugs, people like me will have a harder time.
Plus if more people buy it, it becomes cheaper;). Buying one year old tech is often a good idea - but I'm definitely not going to buy a Prescott next year (Intel is flailing around at the moment, Intel's 2004 stuff is not very good), but Athlon64? Who knows...
The funny thing is the Crackers and their target audience are the ones who won't have problems with this.
Whereas as we can see, the legitimate users are the ones having problems.
It is common for some legitimate users to resort to using cracked versions because they just _work_better_ for them. Say you're a sysadmin for a small/midsized company with 100-200 pcs, and you have the legit licenses for software for all the PCs. Often using Cracks (and a few corporate keys) and a custom compilation "installer cd/DVD" is a lot more convenient than carrying around 10 CDs and 200 different keys. You have _paid_ for all the licenses, so ethically I don't see why not.
Sure in some countries they have laws which allow/encourage companies to legally limit you to using the software only if you uninstall Nero and Clone CD, bow down and worship the Manufacturers, sacrifice your first born etc etc. But I think those laws are ridiculous.
I bet more than one legit user has given up and said "F*ck this, why pay them for this?".
I know some "Unauthorized Distributors" provide a far far better level of support for the money they get per game.
In contrast: look at the support on the official Sims2 forums:
"And murronrose, since you returned your game, that means that you are no longer a product-registered owner of the game. Which means you shouldn't even be using this BBS... I'm most likely going to have to remove your posting priveledges if you don't cancel your account yourself.
Just because there's more to read doesn't make things more readable.
In fact often it makes it harder at least for some people anyway - people who prefer to stare at one page and figure it out, rather jump from page to page.
Think of it as something like CRC. If the code isn't consistent with the comments then you know you're supposed to fix something. Either the comment is broken or the code is.
Sure it may not be easy to figure out which is broken but that's better than figuring whether the 10 lines of Java are correct or not (and which 10 lines to focus on) (if they're wrong you don't have a quick "checksum").
Actually there are antiviral drugs. e.g. Acyclovir. While that doesn't exactly kill off a virus, it's actually hard to say when a virus is "alive" anyway.
And if you think viruses and bacteria are tough, some multicellular parasites are scary too.
Slashdot Mirror
That's the thermal design power. As far as I know the single core Athlon 64s only consume 40+W.
They _never_ guzzle 90W when running within specs.
While people were confused or puzzled about the 83W/90WTDP spec _across_the_board for all CPUs no matter what clock speed. AMD was looking ahead when they announced their 64 bit CPUs.
I believe they wanted to ensure that manufacturers won't skimp and make designs that only cope with 50W. They wanted everyone to make designs which allow users to upgrade by just dropping in a _dual_core_ CPU.
If you do 40+W x 2, the 90W TDP makes sense.
"Yeah, you should tell the terrorists to stop trying to kill us because we want to explore outer space."
Insightful? The pipeline that was blown up is in Iraq.
Smoke something else, whatever you're doing is bad for your brain.
"How much money could be saved if the trip to Mars was just one-way?"
:)
Send Dubya Bush! He's so keen on the trip to Mars, why not send him?
There'll be a lot of money (and maybe even lives) saved!
They're written in the notorious "buffer overflow" languages, so most people will have these problems for the near future.
Meanwhile what you can do is to run each program as a different more restricted user.
On windows XP, run IE with using a shortcut with a runas with savecred (you should modify those in the start menu and quick launch too), and set it so it runs using a very restricted account. The restricted account should either have access to your bookmarks, history and temporary files, or you should run it so it changes to the restricted user's home directory and you allow your main account access to the restricted user's home directory.
Look up the runas command for the options. It'll be more convenient on WinXP since there's the savecred feature.
On UNIX, I think you can use sudo or something similar. Sudo to a restricted account and then run the browser.
This way, if your program gets exploited it can only ruin what the restricted user has access to, it can't easily touch the rest of the system.
Exploits can still theoretically touch the rest of the system since there's stuff like shatter attacks (for windows, not sure about KDE/GNOME), and I'm sure display drivers have bugs of their own and they run in ring 0 (on windows).
But if you do this it raises the bar significantly.
There are other options if you're really paranoid and don't mind the extra effort.
I bet you're right too. I'm sure there are many large corps who won't move from W2K to XP.
I'm saying even if the unit tests work perfectly, you can't use them if the program you want to test is badly broken for that particular area.
It'll just tell you something you know already.
It may be broken by a change in the behaviour of an external system. There's a small hope that the comments might actually help - e.g. the programmer comments: "WARNING!! Change to +1 and remove this comment if XYZ fix bug #1234".
"If what's written in your comment needs to be translated manually into something else, then you should write code to translate it automatically"
But the comment isn't code. And you're missing my point completely.
Don't tell me you'd want a program to automatically _ensure_ (not _verify_) that your CRCs/checksums are always correct.
As for having multiple representations of the same fact, that's called redundancy. And it's not always a bad thing - go ask people who buy RAID systems or intentionally have 3 different computers running _different_ software from different vendors that's supposed to do the same thing.
We are living in an imperfect world and dealing with many different imperfect people and systems. You're going to have to say the "same" thing many times in different ways so that you are more certain of getting the point across eventually.
There will be differences and inconsistencies but the more times you intentionally say something that is consistent, then the more important you regard it. The other stuff which is said only a few times and is inconsistent should be not so important/critical.
That goes for the spec, the documentation, the comments, the unit tests etc.
It's not "Hello Perfect World".
It's "Hello #@$^%7.4d NO CARRIER
The myth that the most informed companies spend the most on buying info from analyst firms was debunked resoundingly.
:)
It was found that the most informed companies spent _less_ than the average and that the lowest spending companies were the most informed.
I sure can come up with the bullshit too eh?
I work in the field of IT security and I disagree. Automation isn't the culprit here.
;) ). That is not always the best choice.
The culprit is people who pick/make systems that do not _fail_ well.
The naive will pick the system that works best. (Or the cheapest
For critical systems, often a suboptimal system that fails well is a better choice. Better than one that works _beautifully_ when everything goes according to the marketing brochure (or everything is near the specs), but fails catastrophically when something goes wrong.
Think of a suspension of a car, which is better? A suspension that makes noise and sags as it gets worn, or one that is perfect till the day it snaps?
You can have automated systems that fail gracefully. They may cost more though. That's like sticking a few monitors to the brittle-failing suspension to make sure you change it before it fails catastrophically at the very moment you need it to be around (coz of the higher stresses). Heck you might even have it artificially sag and squeak, if the driver is stupid enough not to understand the warnings etc.
Most kids minds "set"/harden by the time they are 12. So if you want to get anything into their minds _fast_ you have to start early.
If your kids aren't learning the fundamentals at age 3-5 they're have difficulty fitting the rest in before the usual growing processes kick in and their brains "harden" - apparently there's actually a significant brain cell die-off at that point.
I'd suggest teaching the kids what YOU think matters. Coz otherwise MTV and friends are going to try to teach the kids what MTV et all think matters anyway.
But hey you are free to teach your kids mostly nothing. Others will gladly step right up to fill in the gaps in your "syllabus". Good luck.
What's the status of the various drivers esp server related? Network, mass storage (SCSI, SATA, ATAPI, ATA)?
;).
;).
Well my competitive edge is learning things fast. So I'll go learn it when I need to
Plus I find it more fun to learn about tons of new features rather than learn about tons of bugs which would be fixed in the "real release". Grrr.
I can then summarize: "Are you using at least release X? No? This release is not suitable for production use- upgrade!".
Coz if I started using the bleeding edge stuff I'd probably get too annoyed. I hard crashed an iMac during the launch of the first models, dunno how - just moved the mouse pointer around and clicked the browser here and there, and within a minute or two - locked up. I did something similar to an Atari ST too (and it wasn't bleeding edge by that time).
So if you don't mind, I'll wait for you all to find most of the "dumb" bugs first
I see comments as complementary.
;) ).
Unit tests might sometimes not work (or give useful results) when the program isn't working - e.g. badly broken. Whereas the comments could still be useful in those cases (maybe even more so
And if you are looking at the code, means you are going to be spending time with the code anyway, so the comments are a nice and handy reference.
I don't think you'd need comments everywhere - at least for most code - since most code is just run of the mill. Comments would be useful if you are doing something exceptional, or something important. e.g. "This weird stuff is to work-around bug #1467 in version x.y.z of software ABC".
Sure you should write documentation for that and refer to the documentation. But it is handier to have the comments around as well.
Yeah, but nowhere did I suggest duplicating the code. I said it should be like a CRC (CRCs don't duplicate the data), and you know something is wrong if the "CRC" isn't consistent.
He said that was a bad idea, and talked about saying the same thing twice.
So I was curious to see whether he couldn't read/think properly or if he actually had something interesting to say. Or both.
Can you back up/explain your statement?
Sure sounds like he got a dud Athlon 64 system that was flipped back to them by someone else - probably for not working properly.
Corrupt filesystems? Doh.
I watched the stanford video presentation by the AMD guy and they claimed that going 16 registers (additional 8) got most of the benefits for most apps, whereas going 32 (additional 24) only gave a bit more benefit.
An explicit 32 register x86 would cost signficantly more for the reasons you mention. So AMD were lucky that 16 was good enough (according to them at least).
The 2400+ could be an older chip?
I recently bought a barton 2500+ and it's often < 50+ degrees. The mboard is 36-38 degrees C - I'm in the tropics.
I've got an older Barton 2500+ (the one that came with an unlocked multiplier) in another machine that runs 24/7 and that's at 58.5 degrees - mboard is 38 degrees C. I haven't cleaned the CPU fan for a while tho.
Thing is, often for programs where performance really matters, the relevant routines are optimized to use all the available FP+int units for the target architecture. At least this is true for many games.
:).
I don't see how HT will help much in these cases and it might even be counterproductive.
Of course there are always cases where performance matters but they haven't got around to optimizing (e.g. OpenSSL).
As for programs where performance doesn't matter -it doesn't matter right?
They should have done a make -j 4 test or something, with HT and without HT.
Quad opterons scale a LOT better. They make most present quad xeons look pretty bad. There are few reasons to buy a quad xeon server - often it is better to buy two dual xeons. But quad opterons appear to be a different matter.
;).
Check out: SPEC int rate
Sure they don't do as well as IBM POWER5, but most other stuff don't either
You were using really old and out of date stuff. No surprise you noticed the slowdowns.
;). Buying one year old tech is often a good idea - but I'm definitely not going to buy a Prescott next year (Intel is flailing around at the moment, Intel's 2004 stuff is not very good), but Athlon64? Who knows...
While 64 bit for RISC stuff often makes things slower, we're talking x86 here- this is a different thing.
The AMD64 64 bit mode also adds 8 more registers, this is what helps the compilers make things faster than normal 32 bit stuff. As for why only 8 more, the AMD people did their homework. 8 more would give more bang for buck compared to 24 more.
I'd encourage people like him to use the 64 bit stuff now, coz I might want to use it next year... Without the bleeding edge people finding the common/"D'oh" bugs, people like me will have a harder time.
Plus if more people buy it, it becomes cheaper
The funny thing is the Crackers and their target audience are the ones who won't have problems with this.
Whereas as we can see, the legitimate users are the ones having problems.
It is common for some legitimate users to resort to using cracked versions because they just _work_better_ for them. Say you're a sysadmin for a small/midsized company with 100-200 pcs, and you have the legit licenses for software for all the PCs. Often using Cracks (and a few corporate keys) and a custom compilation "installer cd/DVD" is a lot more convenient than carrying around 10 CDs and 200 different keys. You have _paid_ for all the licenses, so ethically I don't see why not.
Sure in some countries they have laws which allow/encourage companies to legally limit you to using the software only if you uninstall Nero and Clone CD, bow down and worship the Manufacturers, sacrifice your first born etc etc. But I think those laws are ridiculous.
I bet more than one legit user has given up and said "F*ck this, why pay them for this?".
I know some "Unauthorized Distributors" provide a far far better level of support for the money they get per game.
In contrast: look at the support on the official Sims2 forums:
"And murronrose, since you returned your game, that means that you are no longer a product-registered owner of the game. Which means you shouldn't even be using this BBS... I'm most likely going to have to remove your posting priveledges if you don't cancel your account yourself.
-MaxoidLucky"
Just because there's more to read doesn't make things more readable.
In fact often it makes it harder at least for some people anyway - people who prefer to stare at one page and figure it out, rather jump from page to page.
Think of it as something like CRC. If the code isn't consistent with the comments then you know you're supposed to fix something. Either the comment is broken or the code is.
Sure it may not be easy to figure out which is broken but that's better than figuring whether the 10 lines of Java are correct or not (and which 10 lines to focus on) (if they're wrong you don't have a quick "checksum").
Actually there are antiviral drugs. e.g. Acyclovir. While that doesn't exactly kill off a virus, it's actually hard to say when a virus is "alive" anyway.
And if you think viruses and bacteria are tough, some multicellular parasites are scary too.
Ah but it is carousel time for you.