Slashdot Mirror

The P4's x87 FPU and x86 ALU are just plain slow compared to P3s and Athlons. Though I am surprised your code is running 82x slower. I'd expect more like 2-8x slower for compute bound code. You can get a somewhat sensationalistic overview of why it's so slow at this link.
If you want more in-depth numbers you can compare appendix C of the Intel Pentium 4 Optimaztion Manual with chapter 29 of Agner Fog's Pentium/II/III Optimization Manual. You can see the Athlon numbers in Appendix F of AMD's Athlon Optimization Manual.
If you want to do number crunching with Pentium 4s your best bet is to use the SSE2 instructions/registers. You should be able to get a noticable speedup by using the Intel C++ compiler and telling it to use SSE2 instructions. If you want to eek out max performance you'll have to use assembly language. Though you can probably get most of the way there using the Intel C++ Compiler's SSE2 intrinsics.
I'm curious as to why your code is so much slower on a P4 than on an Athlon. The best way to find out would be to look at the assembly code that gcc is producing. You can do that by using gcc's -S option. If you'd like send me the C code and the output from -S and I'll see if I see anything obvious.
I'm somewhat paranoid about posting my email address. My paranoia seems to work, as I've received no more than the occasional spam in the last few years. My email address is my slashdot user name at woh.rr.com.

The P4's x87 FPU and x86 ALU are just plain slow compared to P3s and Athlons. Though I am surprised your code is running 82x slower. I'd expect more like 2-8x slower for compute bound code. You can get a somewhat sensationalistic overview of why it's so slow at this link.
If you want more in-depth numbers you can compare appendix C of the Intel Pentium 4 Optimaztion Manual with chapter 29 of Agner Fog's Pentium/II/III Optimization Manual. You can see the Athlon numbers in Appendix F of AMD's Athlon Optimization Manual.
If you want to do number crunching with Pentium 4s your best bet is to use the SSE2 instructions/registers. You should be able to get a noticable speedup by using the Intel C++ compiler and telling it to use SSE2 instructions. If you want to eek out max performance you'll have to use assembly language. Though you can probably get most of the way there using the Intel C++ Compiler's SSE2 intrinsics.
I'm curious as to why your code is so much slower on a P4 than on an Athlon. The best way to find out would be to look at the assembly code that gcc is producing. You can do that by using gcc's -S option. If you'd like send me the C code and the output from -S and I'll see if I see anything obvious.
I'm somewhat paranoid about posting my email address. My paranoia seems to work, as I've received no more than the occasional spam in the last few years. My email address is my slashdot user name at woh.rr.com.

This is the link, actually.

The link to the Trusted Computing Platform Alliance on the left is ominous. When Intel speaks of "building block" do they have Palladium in mind?

The link to the Trusted Computing Platform Alliance on the left is ominous. When Intel speaks of "building block" do they have Palladium in mind?

The TEM picture is not too clear, but try this site at Intel for a picture. Search down for the term "finFET" near the bottom.

The SEM picture shows the "fins" being in the source and drain region. I always though the "fin" was the gate as shown in the TEM cross-sectional picture. In this picture, what I thought was the "fin" is kinda hard to see. It's above the thing labelled "si island" in figure 26. Perhaps I'm mistaken. Or perhaps the authors of the document at Intel are mistaken.

Since its optimization you are concerned with I have a few choices you will be interested in:

1. The Zen of Code Optimization by Michael Abrash.
2. Agner Fog's Assembly Resources
3. The Athlon Optimization Guide
4. Intel's IA32 Optimization Guide
5. The Aggregate Magic Algorithms

These sources will give you everything you need to know about code optimization for x86.

Shh! It's a secret, but Intel offers 4 very nice books at a great price: free.

They aren't tutorials, so there isn't the same hand-holding that you would get in a book from Barnes & Noble, but they explain things well enough that a seasoned assembly programmer should be able to follow with no problem at all. I think they are exactly what you want.

The word Linux does appeare in the book. On page 6 there's a discussion on why learn assembly language.
One of Irvine's bullet points is about creating device drivers.
Here's a snippet... Printer manufacturers, for example, create a different MS-Windows device driver for each model they sell. The same is true for Mac OS, Linux, and other operating systems.
At Cleveland State this year we had to buy this book and another (can't remeber the name it's used the second half of the semester) for the Lanugage Processor class.
If you want IA-64 info go to Intel's site for the white papers. :)

i don't have any benchmarks, but i'd imagine that the FP version is still much faster than the integer version. there's a lot of small devices that can decode mp3's using a non-floating point decoder on cheap hardware, and it's the primary reason that many soft-upgradable devices haven't had vorbis support in the past. decoding mp3's and vorbis files without an FP unit requires doing a lot of manual conversions in the code, bloating the code out.

----------
the phatnoise music box (and now kenwood music keg) runs linux on non-fp hardware, and as such cannot handle vorbis - until now?

new pentium 4 mp3 decoder performs much better due to intel's new floating point conversion opcodes

Moore's Law describes an increase in transistor counts.

I hope you are referring to the idea that traditional microprocessor design would be obsolteted by 'optical computing' thus halting the advancement of traditional microelectronics, thus stopping the advancement of transistor counts as opposed to somehow having transistors being used in 'optical computing.'

I don't know anything about the 487, although I would imagine they built it because their customers asked for it (seems like something an OEM would love).

Hmmm. When I wrote my reply to you I was surprised how hard it was to dig up authoritative references about the 487 that were as critical as I remember at the time.

Intel has often had two versions of their processors. A more expensive one, for "power users", and one that was crippled in some way, but available at a lower price, to compete with their low end rivals.

I have heard some wags refer to the 8088 as the "8086sx". I know there was an 80188, to serve as the 80186sx. I have heard some wags say the "SX" versions are called that because they suck. I have heard some say the various versions of the Celeron were really the Pentium II SX, the Pentium III SX and the Pentium 4 SX.

At the time, it was widely believed that the 486sx was exactly the same chip as the 486dx and the 487. And if you check these three intel web-pages describing the 486sx , the 486dx and the 487 , you will see that they all extremely similar. They all have 1,200,000 transistors. The buzz was that as 486 chips were baked, they were tested at different speeds. Those capable of working reliably at 33MHz were destined to become 486dx chips. Less reliable chips had their FPU burned out by a laser, and were packaged as 486sx chips.

Some 486 chips were packaged in a different pinout, and marketed as the 487, the floating point co-processor for the 486sx. Plugging a 487 into 486sx motherboard turned off the 486sx. My recollection is that the 487 was more expensive than the basically identical 486. It is interesting that intel is still maintaining the fiction that the 487 was a separate chip.

I have been told I should be more forgiving. But I decided six years ago that I would never buy another intel CPU.

I don't know anything about the 487, although I would imagine they built it because their customers asked for it (seems like something an OEM would love).

Hmmm. When I wrote my reply to you I was surprised how hard it was to dig up authoritative references about the 487 that were as critical as I remember at the time.

Intel has often had two versions of their processors. A more expensive one, for "power users", and one that was crippled in some way, but available at a lower price, to compete with their low end rivals.

I have heard some wags refer to the 8088 as the "8086sx". I know there was an 80188, to serve as the 80186sx. I have heard some wags say the "SX" versions are called that because they suck. I have heard some say the various versions of the Celeron were really the Pentium II SX, the Pentium III SX and the Pentium 4 SX.

At the time, it was widely believed that the 486sx was exactly the same chip as the 486dx and the 487. And if you check these three intel web-pages describing the 486sx , the 486dx and the 487 , you will see that they all extremely similar. They all have 1,200,000 transistors. The buzz was that as 486 chips were baked, they were tested at different speeds. Those capable of working reliably at 33MHz were destined to become 486dx chips. Less reliable chips had their FPU burned out by a laser, and were packaged as 486sx chips.

Some 486 chips were packaged in a different pinout, and marketed as the 487, the floating point co-processor for the 486sx. Plugging a 487 into 486sx motherboard turned off the 486sx. My recollection is that the 487 was more expensive than the basically identical 486. It is interesting that intel is still maintaining the fiction that the 487 was a separate chip.

I have been told I should be more forgiving. But I decided six years ago that I would never buy another intel CPU.

I don't know anything about the 487, although I would imagine they built it because their customers asked for it (seems like something an OEM would love).

Hmmm. When I wrote my reply to you I was surprised how hard it was to dig up authoritative references about the 487 that were as critical as I remember at the time.

Intel has often had two versions of their processors. A more expensive one, for "power users", and one that was crippled in some way, but available at a lower price, to compete with their low end rivals.

I have heard some wags refer to the 8088 as the "8086sx". I know there was an 80188, to serve as the 80186sx. I have heard some wags say the "SX" versions are called that because they suck. I have heard some say the various versions of the Celeron were really the Pentium II SX, the Pentium III SX and the Pentium 4 SX.

At the time, it was widely believed that the 486sx was exactly the same chip as the 486dx and the 487. And if you check these three intel web-pages describing the 486sx , the 486dx and the 487 , you will see that they all extremely similar. They all have 1,200,000 transistors. The buzz was that as 486 chips were baked, they were tested at different speeds. Those capable of working reliably at 33MHz were destined to become 486dx chips. Less reliable chips had their FPU burned out by a laser, and were packaged as 486sx chips.

Some 486 chips were packaged in a different pinout, and marketed as the 487, the floating point co-processor for the 486sx. Plugging a 487 into 486sx motherboard turned off the 486sx. My recollection is that the 487 was more expensive than the basically identical 486. It is interesting that intel is still maintaining the fiction that the 487 was a separate chip.

I have been told I should be more forgiving. But I decided six years ago that I would never buy another intel CPU.

The replies to this message apparently are very skewed towards those that receive little or no training, or of training with little quality. I'd like to add a counter balance to that.

My background: I've been a trainer for two years for a small training & consulting company out of New York (though I've since moved on). I've trained (and consulted) globally, with my courses ranging from beginner to advanced Java, C++, Web Services, XML/XSLT, J2EE, EJB, and most recently the Microsoft 2-day VS.NET seminars. I've taught principal engineers and developers of products you may have heard of, as well as various other companies.

Is training worth it? It depends. The main benefits of training vs. books are:
a) you can't ask a book a question
b) books can't help you when their examples don't compile
c) you'd like to get an answer to that gnatty problem you've been experiencing in that DLL you've been screwing with for 3 days (i.e. free consulting advice)
d) some authors really can't write
e) some technologies are so new or specialized there isn't much in the way of quality books out there (i.e. advanced oracle performance tuning, advanced J2EE architecture, writing for an EAI framework like TIBCO, etc.)

Training is a way of imparting knowledge that the books have IN CONTEXT of the real world AND providing the extra knowledge that the books don't have.

Most training sucks, of course, because
a) it's not relevant to your day-to-day job
or
b) the buyer doesn't know what constitutes good training.

This really harkens back to the scourge of the land of IT: a lack of good managers. It's up to managers to know what training is needed & whether the vendor is of sufficient quality. It's also up to the managers to involve the team with this decision -- I fully agree with the premise of this article that those being trained should influence the training -- if you're not seen as being competent enough to know what you need, there's a real reality-deficiency occurring.

Given the above, what makes a good instructor for technical courses? IMHO, in order:
a1) advanced technical knowledge & expertise
a2) good teaching skills
b) patience
c) energy (you have to carry the crowd through the tough parts)
d) humility (you can sometimes be wrong)

They're all needed, though at bare minimum A1 & A2... if you have teaching skills but don't know much, you're not accomplishing anything except entertaining/babysitting a crowd for a few days. In an advanced crowd this will generate a lot of anger. Conversely, if you know a lot but have the communication skills of a potato chip, you'll still get a lot of angry people wanting to give you the boot.

Having said that, a good course with a good instructor can be a very rewarding experience, probably a major highlight of your career growth -- assuming you get the right course for the right reasons with a good instructor.

In perspective, a 5 day course can run between $1-3k a person, depending on the depth, level, and reputation of the instructor. That's not cheap. It's probably only worth it to go with the "world class" instructors, whether well known (like the folks at DevelopMentor, or Hotsos), or relatively unknown but promising (like my old company).

As for what industries regularily offer training -- generally in my experience, financial and insurance companies. There's always ongoing training there for new technologies, and most new IT hires get 4-12 weeks of training in business and technology.

The libraries used would matter more than the OS. Look at Intel's API.

http://www.intel.com/research/mrl/research/opencv/

for non-commercial purposes, anyway

The winner of this year's Intel Science Talent Search invented it.

Ah, but they do care. 85 C seems to be the official redline.

Although, informally, if you're breaking 60, rethink your cooling setup.

My top secret information sources are Intel's website. You see, they publish what the sucker looks like so people like me can design applications (hardware and software) for it. Like:

here for instance.

Using that information I determined the architecture is ill suited for consumer applications. It has too many redundent parts that consume mad power. Those parts are sped up by speculative lookahead routines, and a pipeline that makes the one in Alaska look short in comparison.

I can neither confirm nor deny your other allogation about my access to secret information. I can however tell you that the matter is handled by the State Department, not the NSA.

All you have to do is run some benchmarks to prove [that the Athlon is faster clock for clock than the P4].

In that case, Microsoft SQL and Oracle are infinitely slower than MySQL and PostgreSQL because I can't even get past the stupid EULAs that make me promise I won't release benchmark results to the general public. Watch for Intel to start pulling the same sh*t when the AMD Opteron trounces both the Pentium 5 and the Itanic.

Disks are as unreliable as ever and are not close to following moore's law in speed up.

Well, Moore's law was actually about the number of transistors on a die and not about speed at all. While drives have not gotten significantly faster over the years, their density has grown by an unbelievable amount. The first hard drive I ever used was on a Mac. That was probably 15 years ago, and was a 20MB drive. I can now go buy a 200GB drive (10,000 times bigger!) for less money in a smaller case. And the fact that you can even build a system which can hold a hundred gigs speaks wonders for the reliability of hard drives. Can you imagine the uptime on a drive farm of 10,000 drives? Do you know how many would fail every hour? It would have been a challenge to build a 200GB data farm at any price in 1985. It is a shame about the speed though. Seek times are what, like 10% of what they used to be?

On a similar note Dell has been configuring their laptops with the intel 830m chipset (I purchased an Inspiron 2600) so the BIOS won't play nice with Xfree86. The BIOS only allocates 1mb of video memory which isn't enough to get full screen resolution. You need a Windows specific BIOS hack from the restore CD just to get decent screen resolution. That's bad when even the WindowsXP CD can't play nice with the BIOS settings.
Here is post on Xfree86 about it.
Here is the Intel page. Notice at the bottom where they bitch at companies like Dell.

I don't know if anyone mentioned ROOT yet, so here goes.

There's a framework from CERN called ROOT, which has a lot of nice features for numerical scientific computing.

The language is C++, but don't let that scare you - in time you will also frown upon procedual languages (they are hard to maintain) and functional languages (they just don't do the job for numerical stuff - to bad - I like the concept).

ROOT provides things like histograms, persistent object storage (and it beats Objectivity by miles!), and ladida. ROOT also has an interactive scripting environment, using C++. This is cool, as it means you can prototype your algorithms as scripts, and when your happy with them, you can simply compile them, and get much higher speeds.

Also note, that Intel's free C++ compiler is reputed to give a 30% increase in speed compared to GCC 3.0.

ROOT is used by some 70+ physics research projects around the world - from the gigantic Alice and STAR to the more modest Athena and BRAHMS.

If I were you, I'd defently consider C++ again. The stuff you've found on netlib is almost all outdated, and there's a good chance that it's been ported to C/C++.

Digital Paper/Ink Digital Paper

This new paper, with electronic ink would mean one book could hold all your books. One piece of paper could be your news paper, magazine, even your favorite website. One peice of paper could have all your schoolwork on it.

SympodiumInteractive Lecture technology, This allows students to view the board, as well as move along at their own pace doing their own thing. This would allow a student to learn more due to the class not slowing them down. Its interactive so if a person wants
more detail about something they can get it.

Reason, Logic, Cause and effect.

This is something schools never teach and this is one of the most important things we must teach kids, as well as adults.
Example

I would have thought that IBM would plug their own hardware whenever possible -- the T221 display is certainly phenomenal, and they provide a link so you could buy one of those... It has me wondering how I can come up with $8400 to get one. (Heck, when those things came out, they were $20,000! Ah, progress.)

So, this leaves us to wonder... no mention of processors, "low" clock speed -- compared to what we're used to seeing -- something new from AMD? IBM pissed off at Intel? Some new massively parallel top secret silicon from IBM?

Watch... it'll turn out to be Pentium IIIs -- they call 'em "workstations," so they might have recovered them from some other project. (Or all the engineers got new workstations and wondered what cool project they could do with their old ones... Q3A at 3840x2400? What the heck!) What's the limiting factor in this case, processor power or network bandwidth?

I would have thought that IBM would plug their own hardware whenever possible -- the T221 display is certainly phenomenal, and they provide a link so you could buy one of those... It has me wondering how I can come up with $8400 to get one. (Heck, when those things came out, they were $20,000! Ah, progress.)

So, this leaves us to wonder... no mention of processors, "low" clock speed -- compared to what we're used to seeing -- something new from AMD? IBM pissed off at Intel? Some new massively parallel top secret silicon from IBM?

Watch... it'll turn out to be Pentium IIIs -- they call 'em "workstations," so they might have recovered them from some other project. (Or all the engineers got new workstations and wondered what cool project they could do with their old ones... Q3A at 3840x2400? What the heck!) What's the limiting factor in this case, processor power or network bandwidth?

Dialogic is the standard in the PBX industry. If you use Dialogic boards, you can be assured of compatibility with the most software, and a long useful life for your hardware.

On the other hand, Intel is good only with microprocessors, m. support chips, and motherboards. It might not be a good thing that Intel bought Dialogic. (Intel closed its consumer electronics division after many, many blunders.)

System Release 5.1 for RedHat Linux

You can build a PBX with Intel (formerly Dialogic) "MSI" boards. The MSI can take an analog interface from the outside and generate ring and dial tone for your station sets. You can use an SC bus capable voice board for voice mail. Ought to be able to find this stuff on e-bay at a reasonable price. As for how-tos, there is a wealth of material on the dialogic/Intel support site Check out the various documentation, especialy the the "Application Notes." There are also forums you can join for free and folks on the forum are very knowledgeable. The bayonne user community is also very helpful. I've been dying to do this kind of project for years but haven't had the time. Enjoy!

the press release

Besides, it's better to worry about the very high-volume low(er)-cost processor such as the 2.4 and 2.53 and soon to be 2.8 and 3.0 GHz P4s. Intel has been worried about their shrinking margins, and 300mm brings them back up nicely. 300mm was not created as a consequence of Itanium, but rather Itanium was aggressively featured as a consequence of needing to compete and having the luxury of a 300mm wafer to help lower costs. With the enormous L3 memories and the resources that Sun dreams of having, Intel can properly push an Itanium out the door that will have no problem outperforming even the fastest competition. (see this press release )

Given the amount of capital and planning involved, 300mm must have been a decision long in process -- and consequently it was completely independent of the recession which gave a much shorter advance warning. However, it was extremely convenient that they had it in the pipeline when the recession hit so they could better tolerate the lower demand, the shrinking number of big players in the PC business and therefore the very high downward pressure on pricing.

Free 30-day evaluation

Vince Harron

Something that might be helpful, but not exactly what you are looking for is profiling and performance tools. Intel released their compiler and vtune (a performance analysis tool) recently for Linux:

http://www.intel.com/software/products/index.htm

I can't speak for the debugger, but when we switched our simulator from gcc to icc with profiling, we gained 25-30% performance. Needless to say, that was way cool. The other threading and vtune items might provide some useful insights to your code.

I hate to say it, but all the stuff I work on is generally so small, it's not worth the overhead to attach a debugger to it, so I'm not much of an expert in this area :-(

- Mike

"Now, if only there was an 802.somethingelse hack that let these 'clouds' contact each other over inter-city distances"

That is partially possible. I recently bought two Intel wireless access points where one can act as a repeater. I have a wired network in my house, but it only is at the extent of my office. I wanted to get to the back yard, so I put one AP (access point) in my office, that covers the front of the house. Then, all I did (after *extensive* configuration/headaches) is plug the other AP in to power in the kitchen and put it on top of the cabinets, and voiala! If I'm on the porch, I talk to AP2 who talks to AP1 who talks to my router. :) Looking here you can see the purdy pictures that show you what I'm talking about. The one setback: you cannot do more than 4 hops (I'm doing 1 hop...2 APs), but you could theoretically have one central AP, then multiple APs that only have one hop back to it, but go in different directions.

Is it one of these concepts?

Simply saying "dumb buses are bad" is dumb. Without considering the CPU speed, availability, and loading from the "dumb bus" at its rated speed, such a statement is meaningless.

It is not that simple. You cannot say a piece of equipment is simply dumb or intelligent. There are variations from the very dumb through the little dumb and little intelligent up to the very intelligent equipment.

In some cases a little dumb equipment is no problem to a fast CPU. But equipment can be so dumb that speeding up the CPU is no help at all.

If communicating with the equipment requires the CPU to do busywaiting a fast CPU doesn't help. Maybe a fast CPU can poll the device 100 million times in a second where a slow CPU can only poll the device 10 million times in a second. But that doesn't make the device respond faster. So no matter how fast you poll, you are still wasting all your precious CPU time, a faster CPU will just increase the waste.

Maybe hyperthreading can be a little help here, but you would still be wasting resources. And requiring so much from the CPU just to support very dumb equipment is not a good idea.

So in fact a device can be so dumb that it is without doubt bad. I don't know if USB is this dumb, but I do know that a parallel port with an interlink cable is.

Without looking at the specs to see, it's rather obvious that the hardware people just redesigned the interface all over again.
>>>>>>>>>
Well, here are the specs so you don't have to make stuff up:
USB 2.0
USB 1.0
The real difference is here:
OHCI (USB 1.0 host controller, this is the better one)
UHCI (USB 1.0 host controller, the sucky one)
EHCI (USB 2.0 host controller spec, has more smarts like OHCI)

Without looking at the specs to see, it's rather obvious that the hardware people just redesigned the interface all over again.
>>>>>>>>>
Well, here are the specs so you don't have to make stuff up:
USB 2.0
USB 1.0
The real difference is here:
OHCI (USB 1.0 host controller, this is the better one)
UHCI (USB 1.0 host controller, the sucky one)
EHCI (USB 2.0 host controller spec, has more smarts like OHCI)

I am not sure where you get this information from, or why not the editors have not checked this statement. The IA64 platfrom supports IA32 code. Read Intel Itanium Architecture Software Developer's Manual Vol. 2 rev. 2.0: System Architecture Part II chapter 9 entitled IA32 Application Support

Support by the operating system is needed, something that already has been built into the Linux kernel. I recomend reading Chapter 11 in IA64 Linux Kernel - design and implementation. IA32 programs will think they are running on a Pentium III computer.

The recomendation is to not run IA32 programs on IA64, but to recompile them for the new architechture... but that is kind of obvious..

A quick web search shows Itanium is x86 compatible.

Admittedly, the Itanium does this using emulation, whereas the Opteron is supposed to handle 32-bit instructions natively, however the statement that 32-bit code will not work on Itanium is quite misleading.

A quick web search shows Itanium is x86 compatible.

Admittedly, the Itanium does this using emulation, whereas the Opteron is supposed to handle 32-bit instructions natively, however the statement that 32-bit code will not work on Itanium is quite misleading.

Itanium does have backwards compatibility:
Q10. Will Itanium processor-based systems be compatible with IA-32 systems? Will IT be able to effortlessly migrate their systems to Itanium processor-based systems? A10. Optimal performance for Itanium processor-based systems will be achieved with 64-bit software. The Intel Itanium processor supports 32-bit binary compatibility in hardware.

from this link

I honestly think we (the IBM PC users of Earth) should ditch IA-32 and use IA-64 as a stepping stone (future Itaniums will not have the binary compatibilty). The backwards compatibility is killing PC performance. Look at how high an x86 CPU has to be clocked just to achieve equal performance with a RISC computer. And higher clock rates == more heat and more power consumption.

~ SleezyG

"RISC: any computer announced after 1985." -- Steven Przybylski

It happens yearly (incidentally, last weekend). 4 days of non-stop gaming, contests & silliness. Lots of case mods (my fav was the labatts blue fridge system). A buddy of mine won a can of SPAM for the best "Ghetto mod" PC - a beat up gateway with duct-tape keeping the cover on.

3 & 4AM Sunday MOHAA: funnies included 'nade dancing, an orgy, an unsuccessful congo line (some dumbass kept dropping nades) and a human pyramid.

Official tourney's were were 5v5 Counterstrike (blech!), 4v4 RA3, and an Xbox Halo tourney. See the site for the give-a-way goodies & details.

It was loads of fun and I'll definitely be back next year. We even had a guy from Washington state (but the guy arrived with a fried HDD). And wow...chicks...and 1 in a skipping contest, no less...*droool*

You possibly are approaching this problem in a "like UNIX" sort of way, however security on Windows system depends more on all encompassing technologies like L2TP or IPSec: Take a look at IPSec. It separates encryption and payload integrity from the application, and of course works with all applications because they're unaware that it's acting as a pipe between systems. If you're concerned about performance then get yourself a NIC that offloads encryption processing. Note that your system can be configured to only allow connections to certain services if an IPSec connection has already been established: Launch an MMC console (Start/Run/mmc.exe) and add the snap-in "IP Security Policies" for the local computer and play around: The possibilities are endless.

Next time you're at your local book store, take a look for the Microsoft training book for their exam number 70-220 : Designing Windows 2000 Network Security. Because XP is 2000 with a nice GUI it is entirely relevant.

If memory serves... Isn't Intel already utilizing asynchronous technology in thier StrongARM line of processors? I thought they developed an asynchronous processor back in the early pentium days, but the costs of mass producing it were pretty steep.

Use VTune (http://www.intel.com/software/products/vtune/vtun e60/), Intel's profiler.

It does a pretty good job, and it uses performance counters.

Somebody, please mod this up because jeff is right damn it!!!

I've worked with both the SA-11x0 (StrongARM) and the PXA250 "Cotulla" (Xscale) CPUs and everything jeff says is pretty much on the money (except the CLZ instruction is far from useless, it's *awesome* for fixed-point logarithms, dude).

Also, the DSP coprocessor in the X-scale is about as useful as tits on a bull for codecs with 16-bit data streams. You spend so many clocks marshalling data around to get it in and out of the thing that it's *much* more efficient to use the MAC instructions native to ARM v4 on normal registers! Even the Intel engineers who put together their IPP's have avoided the DSP coprocessor since it provides no real advantage.

It's pretty clear to me the v4/v5 thing is a red herring. Let's face it DEC was much better at putting out a general purspose ARM-based CPU than Intel.

If you are doing anything that requires performance, you shouldn't rely on the compiler. Intel has their "Integrated Performance Primitives" which give you a nice abstraction layer so you can wring the most power out of each processor without having to hand code asm for each one.

Actually, you and the CNet link you posted have it wrong, also. Moore predicted transistor density would double, not the number of transistors on a Microprocessor. Here's the reference from the man himself.