|
the article you copy/pasted and are trying to claim as your own is several years out of date. 
--
If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
|
|
|
|
|
I've always preferred Intel. In the Pentium II and III days Intel typically had a clear lead, but were usually more expensive. AMD started to pick up a performance lead towards the end of this era. However, I tended to observe that the computers using VIA and SIS chipsets were less reliable than Intel chipsets. When all the processors used Socket 7 (Pentium and AMD K5/K6) you could match an AMD processor to an Intel chipset; once Intel moved to Slot 1 for the Pentium II and the AMD clock rates started climbing, the old Intel chipsets couldn't cope any more leaving VIA and SIS as the only (flaky) choices.
It could be that the behaviour of some of the owners of the computers was actually the cause of the flakiness - generally they'd swap components over regularly and install and uninstall a lot of (often slightly dodgy) software. Still, people with Intel systems did the same and they were generally more reliable.
Pentium 4 - NetBurst architecture - was an attempt by Intel to massively ramp the clockspeed and it was designed to make best use of fast clocks, by having a long pipeline in which a little progress was made in each stage. If you're not familiar with electronics, it takes a certain amount of time for the signal at the output of a series of logic gates to stabilise at the correct result, or in the case of latch circuits, to latch at the correct result. If the result is sampled too soon (with a faster clock), the incorrect result can be latched and you get incorrect answers.
To get the most benefit from this, though, the pipeline needed to be kept filled, and instruction dependencies, memory latency, and branch mispredictions tended to mean that it couldn't be kept full, meaning cycles were wasted. In the case of a dependency error or branch misprediction the whole pipeline has to be thrown away and restarted to recompute the correct operations.
The trouble is, the design was intended to ramp to 10GHz and as we know, we never got there - 'NetBurst' Xeons topped out at 3.8GHz or so. The problem was simply heat - too much current was leaking, causing the circuit to consume more power and emit it as heat rather than do useful work. AMD, on the other hand, kept a shorter pipeline consistent with its older models, with larger amounts of work done per cycle. In the end the Athlons were able to clock high enough to surpass the P4s at much lower clock rates.
At this point the choice of chipsets for an AMD system appeared to be VIA, nVidia or ATI. nVidia and ATI can't get a video board right (I use whichever the computer manufacturer chooses because they're equally bad) so I hold out no hope they can get a chipset right, even if the memory controller is now part of the processor package.
Meanwhile Intel were effectively still developing the Pentium III for laptops - as the Pentium M - as the NetBurst architecture was utterly wrong: the power characteristics would only be suitable for 'desktop replacement' laptops that were only moved from place to place, as the P4 would flatten virtually any battery in minutes. Towards the end of the P4's life it was clear that the Pentium M was actually faster, not just clock-for-clock but overall, and you saw a few desktop boards. Result, a massive about-face, and the new desktop processors eventually christened 'Core 2' were a derivative of the Pentium M (Virtual PC 2007 still identifies my Core 2 Duo T7200 laptop as an 'Intel Pentium III class'). It's reasonably clear that Intel have taken back the performance lead.
There's a bit of back-and-forth over different Single-Instruction-Multiple-Data instruction sets (MMX, 3DNow!, SSE, SSE2, SSE3, SSE4 I think is in the works) but on the whole, and despite much encouragement from Intel, I think most code still uses the antique x87 FPU instructions for floating-point operations. The NX (No eXecute) bit added by AMD in the Athlon 64/Opteron has been adopted by Intel (as eXecute Disable, XD); both are now offering incompatible virtualization support, but Virtual Server 2005 R2 SP1 supports both types and I think VMWare supports both as well. AMD invented 64-bit extensions to x86 and after a bit of arguing, Intel adopted them as well (with a few minor omissions and differences, but there's enough common ground to write an OS to).
Intel's own attempt at a next-generation 64-bit architecture is much more elegant (you don't get much less elegant than bodging 64-bit extensions onto a 32-bit architecture that was itself already a bodge of a bodged 16-bit architecture - 8086 was crap from day one) but bizarrely has been stuck at low clock speeds - while it might be much more efficient clock-for-clock than x86, Core 2 (Xeon 51xx, 53xx) and Opteron are faster overall because they have faster clocks. They're also a heck of a lot cheaper. It's no wonder Itanium didn't take off (it didn't help that the built-in x86 emulation was woefully slow).
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
I am thinking of purchasing a Toshiba Notebook (A215-S4757). However, I am not so sure about AMD. I will be using the laptop for Software Development. I was wondering if would face any trouble with this processor or should I simply go with Intel Centrino??
|
|
|
|
|
There shouldn't be any major problems, but Intel's led AMD in the performance/watt metric for mobile chips for years. Not a problem if you're working plugged in, but it'll drain your battery faster while working mobilely.
--
If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
|
|
|
|
|
Do you think that AMD would be able to sell CPU's if there was ANY hint of incompatibility with Intel CPUs?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
I used WMI's win32_physicalmemory to get it, but it's empty.
Would anyone give me help?
Thanks! 
|
|
|
|
|
That's because the manufacturer of various components, like motherboards, has to supply a WMI Provider that exposes all this information to WMI. Normally, you get this from the manufacturer and install it. Since you don't have a provider, or the manufacturer hasnt written one (there is nothing that says they have to!), you can't get the specific information. Also, even if the manufacturer provides a WMI Provider, there is nothing that says they have to provide ALL the information WMI can handle. Most of the time, they just provide a smalle subset of the total information in the WIM classes.
|
|
|
|
|
I knew there is a guy from Russia that he wrote a small program, the program can read/write SPD information of the memory, since the manufacturer of the memory was saved in SPD of the memory. anyone can search the program on Google.
I thought that can read/write I/O directly to fetch SPD information of the memory, a solution is using GiveIO.sys (Google it!) do it. But I don't know which port is corresponding to the SPD reading/writing, On other hand, if that got the SPD info. we still need to translate the SPD info, maybe a mapping table for this.
As above mentioned, I may want to disassemble that SPD program written by Russain guy..  
|
|
|
|
|
starschen wrote: As above mentioned, I may want to disassemble that SPD program written by Russain guy..
Yeah, have fun with that!
|
|
|
|
|
Maybe your machine doesn't have any memory.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
or the memory is not very good at remembering its manufacturer.
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
Hi All,
I am writing an application which checks LPT signal for doing something. My code looks like:
void LPTThread()
{
while (1)
{
if (ReadLPT(pinX) = signal level Y) {do something;}
}
//pin is one of pins of LPT port
//signal level of each pin is 0 or 1 at a time
}
This loop cause the CPU usage always 100%, is there any way to prevent it? Can we catch this change by any event handler, it mean when a change occurs at LPT or, this event handler will be called?
Thank you for your help.
(I have already put this message in the C++ forum first but then I find this should be put in this forum)
|
|
|
|
|
Hi,
I don't know about any LPT event; I would suggest you put a delay in your while loop
to reduce the CPU load it generates.
Sleep(1000); would reduce your checking to no more than once a millisecond
(probably once every 16 to 20 msec, see my timers article), and reduce the CPU load drastically.
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
Thanks for your reply.
My problem is the application must be sure that when LPT signal change, the application will handle it immediately, so that I cannot let my thread sleeps.
|
|
|
|
|
FYI:
I have no experience with LPT (my PC does not even have one), but since 2.0 .NET
supports the serial port through SerialPort class; it has a PinChanged event catching
changes in CD, CTS, DSR, and RING.
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
I cannot help you with the LPT port but I couldn't help but notice that you want to get the PC to repond very quickly to an external event - I am concerned this may be a problem for you.
The operating system on the PC means that if it is busy doing something else your thread may not get any processor time for several ms. I have written an application that tried to take samples every 100ms and it was very tricky. I could get it to be accurate most of the time, but not ALL the time. You will need to give your thread the highest priority.
If you cannot even wait 1ms for the PC to respond you may have a problem - you may want to reconsider your system design / external hardware since the PC operating system is not really suitable for real time applications.
Best of Luck,
Ali
|
|
|
|
|
Hi folks
I am not a very technical person.
Hope you can help me solve this problem.
I have an electronic thermometer that gives an analog output. I want to display the temperature on my computer in ANALOG form ( a circular dial type display ).
How do I do this. Do I need any special input card and software. And where can I source for this.
I am using Windows XP o/s.
Thank you so much.
John
Pluto7
Pluto7
|
|
|
|
|
Pluto7 wrote: I am not a very technical person.
You're in trouble with this project then...
Pluto7 wrote: I have an electronic thermometer that gives an analog output. I want to display the temperature on my computer in ANALOG form ( a circular dial type display ).
How do I do this. Do I need any special input card and software.
Yes, you need specialized hardware to interface with this device. You may NOT be able to use it though. If you're not a "technical person", you may not even have the minimum knowledge to ask the right questions of a supplier.
This is not going to be cheap. It's probably going to cost you a couple of hunder dollars. You can start looking here[^]. Their stuff is pretty good and you can get the USB interface required, plus a temperature sensor to connect to it, plus, and this if the VERY important part, a software development kit and drivers so you can write code to talk to it.
As for the analog gauge, you can either write your own or use a third party package that draws gagues for you, like Dundas Gauge[^].
|
|
|
|
|
Thanks Dave for your links.
I am familiar with the hardware parts like Transducers and sensors shown there.
But the software part looks intimidating.
You mentioned that the stuff may cost couple of hundred dollars.
What can I anticipate for this.?
John
Pluto7
|
|
|
|
|
From that site, the library comes with a bunch of samples. The object model in their library is pretty simple. Their support is pretty good too.
|
|
|
|
|
- Hello there. I recently aquired a HP Pavillion 522c desktop computor to program on. It works great, but one problem, I have to defrag 2-4 times a day with heavy fragmentation . This not counting the original defrags after installing about 10 Gigs of software and updates.
- Why does it fragment so easily?
- Can it be fixed?
Hard disk
-Western Digital
-60 GB
~Thanks in advandce
"Shorter of breath,
and one day closer to death." ~Pink Floyd
|
|
|
|
|
Thisita wrote: Why does it fragment so easily?
Fragmentation is caused by writing and deleting lots of files to disk, not by the disk itself.
Thisita wrote: Can it be fixed?
No, not really. But it depends on what your system is doing. Reading/writing lots of files will increase the rate at which fragmentation occurs.
But, fragmentation is a part of everyday life under NTFS. Your probably also worried about something that's very normal. What does the fragmentation report come up with as far as fragmentation %?
|
|
|
|
|
Thisita wrote:
- Why does it fragment so easily?
- Can it be fixed?
It can be possibly be improved. It depends on the hard disk manufacturer and their implementation of S.M.A.R.T.
http://en.wikipedia.org/wiki/S.M.A.R.T.[^]
Most manufacturers these days have added intelligent disk writing to increase chances of writing to contiguous disk sectors. You should go into the BIOS and check if SMART has been disabled. It is possible that HP has hidden this BIOS setting or removed it completely.
As the other Dave has stated, there is no way to completely prevent fragmented disk writes, there are no guarantees.
-Randor (David Delaune)
|
|
|
|
|
Thanks
- Well, it seems SMART capabilities(if any) are hidden, which I always thought were used for warning you about eminent hard disk failure
-Fragmentation is said to be 19%, but the bars that MS gives us are 90% red
"Shorter of breath,
and one day closer to death." ~Pink Floyd
|
|
|
|
|
Look at the report, not the graphics. The graphic bar you see can only show you a very small percentage of the disk space. 19% isn't bad at all.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
