SSE2 patch for x264

[CREXbzh]

I tested the amd64 code, and while it compiled alright, common/pixel.c had a ton of warnings with it and the resulting build segfaulted upon usage.
What's the version of gcc that you used? (gcc --version)

[nm]

I tested the amd64 code, and while it compiled alright, common/pixel.c had a ton of warnings with it and the resulting build segfaulted upon usage.
The warnings are harmless, they come from an unused debugging function, which Alexl probably uses to measure something. The segfault doesn't sound very nice though. Can you run minibench.sh successfully (copy minibench.c and minibench.sh to the x264 source directory and run sh minibench.sh)? Also check that you don't get a segfault on a vanilla source tree.

[yokem55]

The gcc version is gcc-3.4.4, yasm-0.4.0.

My dmesg output inludes the following:
x264[17981] general protection rip:43d2d3 rsp:7fffffa91ea0 error:0
Minibench does complete properly:
joe@yokem ~/x264 $ ./minibench.sh.txt
make: Nothing to be done for `default'.
minibench.c: In function `predict_16x16':
minibench.c:26: warning: use of cast expressions as lvalues is deprecated
cpuspeed = 2400034000.000000
loops = 100000000
emptyloop time = 1.9500 cpl = 46.801
x264_pixel_sad_16x16_mmxext time = 4.6100 cpl = 63.841
x264_pixel_sad_16x8_mmxext time = 3.1600 cpl = 29.040
x264_pixel_sad_8x16_mmxext time = 3.5000 cpl = 37.201
x264_pixel_sad_8x8_mmxext time = 2.7100 cpl = 18.240
x264_pixel_sad_8x4_mmxext time = 2.4200 cpl = 11.280
x264_pixel_sad_4x8_mmxext time = 2.7600 cpl = 19.440
x264_pixel_sad_4x4_mmxext time = 2.4300 cpl = 11.520
x264_pixel_ssd_16x16_mmxext time = 13.350 cpl = 273.60
x264_pixel_ssd_16x8_mmxext time = 7.8600 cpl = 141.84
x264_pixel_ssd_8x16_mmxext time = 8.2700 cpl = 151.68
x264_pixel_ssd_8x8_mmxext time = 5.4200 cpl = 83.281
x264_pixel_ssd_8x4_mmxext time = 3.9000 cpl = 46.801
x264_pixel_ssd_4x8_mmxext time = 4.1900 cpl = 53.761
x264_pixel_ssd_4x4_mmxext time = 3.3600 cpl = 33.840
x264_pixel_satd_16x16_mmxext time = 30.610 cpl = 687.85
x264_pixel_satd_16x8_mmxext time = 16.400 cpl = 346.80
x264_pixel_satd_8x16_mmxext time = 16.350 cpl = 345.60
x264_pixel_satd_8x8_mmxext time = 9.0800 cpl = 171.12
x264_pixel_satd_8x4_mmxext time = 5.8100 cpl = 92.641
x264_pixel_satd_4x8_mmxext time = 5.8300 cpl = 93.121
x264_pixel_satd_4x4_mmxext time = 3.9800 cpl = 48.721
x264_pixel_sad_16x16_sse2 time = 5.3900 cpl = 82.561
x264_pixel_sad_16x8_sse2 time = 3.8700 cpl = 46.081
x264_pixel_ssd_16x16_sse2 time = 11.610 cpl = 231.84
x264_pixel_ssd_16x8_sse2 time = 7.1200 cpl = 124.08
x264_pixel_satd_16x16_sse2 time = 33.040 cpl = 746.17
x264_pixel_satd_16x8_sse2 time = 17.630 cpl = 376.33
x264_pixel_satd_8x16_sse2 time = 17.640 cpl = 376.57
x264_pixel_satd_8x8_sse2 time = 10.130 cpl = 196.32
x264_pixel_satd_8x4_sse2 time = 6.4100 cpl = 107.04

[nm]

My dmesg output inludes the following:
x264[17981] general protection rip:43d2d3 rsp:7fffffa91ea0 error:0

Most likely there is a bug in my ported code that didn't come up in my tests. Can you reproduce the error on some publicly available source video file? Post your command-line (x264 parameters) too.

If you're up to the task, you could try to find out, which function(s) causes the problem. You can do this by brute-force testing (so you don't need to learn to use debugging tools). First comment out lines 483-493 in common/pixel.c and recompile. This disables all SSE2 functions, and therefore x264 should work. Next uncomment one or two of the functions and try again. Continue until you find the function causing your problems. This requires a bit of work, but someone has to do it anyway ;)

Note: If you are using some external tool that is statically linked with x264 (like mencoder), you'll also need to rebuild that tool each time you recompile x264.

[riggits]

[QUOTE=nm]I ported the SSE2 patch to amd64. No additional SSE registers used or any other fancy tricks made, so no speedup.
QUOTE]

Nm,I am greatful for your work,but listen me.If we want a significant speedup of x264 compression,then you must try to implement all that "other fancy tricks and additional SSE registers".Can you do it.

Hi Kostarum, maybe you can talk to your beotch like that, but other people will take offense. This applies doubly in areas where you obviously know next to nothing (ie, this entire thread). Show some respect.

@Sharktooth: thanks for the builds, mate!

[bill_baroud]

some interesting info about sse2 on amd64 with intels compiler:
http://forum.doom9.org/showthread.php?t=87299

well, that's when you use the Intel (or other) compiler to generate auto-vectorized code ... if you put some hand-made assembly in a program, this has nothing to do with the compiler. Hence, if the SSE2 code is slower on AMD is just because their SSE2 units isn't as good as Intel one's (and it has been well know)

[dragongodz]

well, that's when you use the Intel (or other) compiler to generate auto-vectorized code ... if you put some hand-made assembly in a program, this has nothing to do with the compiler. Hence, if the SSE2 code is slower on AMD is just because their SSE2 units isn't as good as Intel one's (and it has been well know)
could everyone here please read the whole of the thread bond linked to. it goes beyond just the Intel compiler. expecially read from trbarry's post please.

[bill_baroud]

i read it (and re-read it after your post), he's just talking about the problems you can encounter (16-bytes alignement...) when using SSE2 over MMX, which are problems well described in various place (Intel Optimization Guide...) and more likely why this first SSE2 code is x264 is slower than MMX. I was just reacting (a little late, i admit) to all the buzz around Intel compilers and why it's not revealant in the present case, the reason why SSE2 is slower on AMD(64) than on Intel lies elsewhere than in the compiler (which only auto-vectorize 2 non-critical loops in x264 if you didn't try).

[Sharktooth]

well, that's when you use the Intel (or other) compiler to generate auto-vectorized code ... if you put some hand-made assembly in a program, this has nothing to do with the compiler. Hence, if the SSE2 code is slower on AMD is just because their SSE2 units isn't as good as Intel one's (and it has been well know)
Not true. The AMD SSEx units perform pretty well (their efficiency is higher than the P4 units) but they're heavily penalized by the much lower CPU clock speed.

[bill_baroud]

so they are slower, and that's what matter.... no ?

http://www.x86-secret.com/articles/cpu/a64_3000/a64_3000-4.htm
(a bench is a bench, but ...)

[Sharktooth]

Yes, the bench is right. as i said SSEx are strictly correlated with the clock speed, that's why SSEx on AMD chips are slower in comparison to INT and FP.

[squid_80]

so they are slower, and that's what matter.... no ?


Not exactly. It can depend on the instructions being used - the Athlons for example tend to dislike pshufd, and their pipelines clog up pretty quick with a few pmaddwd ops. But most other instructions they do quicker than pentiums.
SSE3 can eleviate the need for these ops but I don't know how well AMD has implemented it - I'd be very interested to see how well they can do horizontal adding.

[dragongodz]

i read it (and re-read it after your post), he's just talking about the problems you can encounter (16-bytes alignement...) when using SSE2 over MMX, which are problems well described in various place (Intel Optimization Guide...) and more likely why this first SSE2 code is x264 is slower than MMX.
which was the point. the assumption that simply adding SSE2 code is going to make it faster,no matter what compiler or cpu, is false. sometimes you will get the same speed, sometimes a little faster, sometimes a lot faster and sometimes its actually slower. SSE2 is not the magic bullet Intel made it out to be and sometimes you will have to work hard tweaking your code to gain that little extra speed and sometimes you may not be even able to gain anything worthwhile even then.

sorry for interupting.

[708145]

About SSE(2) optimization there are 2 things I'd like to note:

1) For optimal results, different code paths for AMD64, Pentium4 and Pentium-M are needed.
2) For memory latency dependent code even different code paths for various clockspeeds are neccessary.

I have no idea if there was ever such an optimization taking place for any project. Most of the time a compromise is sought which runs well on all target CPUs. ;)

bis besser,
Tobias

[bond]

btw a new patch is up:
http://www.geocities.com/x264hack/sse2-pixel-routines-v4.diff.txt


Hello,

The SSE2 patch is getting there, I'd like to propose this version as a
candidate to be committed. It is the same speed or slightly slower
on Athlon64, but noticeably faster on P4 or Xeon. Some benchmark
results are here: http://www.firstmiletv.nl/vlc/x264/ (courtesy of
Trax).

It should be theoretically possible to speed it up on the Athlon64 as
well but I don't expect to make any progress on that without having
such a box available. It would be nice to have it off by default on
Athlon64 until it is actually faster there as well, but I'm not sure
how to best do that.

I reorganized it into a separate file, would you prefer that or would
you rather have it in the same file?

Regards,
-Alex Izvorski

[Sharktooth]

It should be the same as the one i use in my builds. However V4 is 2/3 weeks old?!?

[CiNcH]

Testing SSE2 optimized pixel routines v4 on an Intel Pentium M Dothan 1.6 GHz (SSE2, 2M L2 Cache) @ 1.1V using minibench utility:

cpuspeed = 2088000000.000000
loops = 100000000
emptyloop time = 2.0830 cpl = 43.493
x264_pixel_sad_16x16_mmxext time = 8.3520 cpl = 130.90
x264_pixel_sad_16x8_mmxext time = 4.5360 cpl = 51.219
x264_pixel_sad_8x16_mmxext time = 5.0470 cpl = 61.888
x264_pixel_sad_8x8_mmxext time = 3.5850 cpl = 31.362
x264_pixel_sad_8x4_mmxext time = 3.3850 cpl = 27.186
x264_pixel_sad_4x8_mmxext time = 3.8360 cpl = 36.603
x264_pixel_sad_4x4_mmxext time = 3.1740 cpl = 22.780
x264_pixel_ssd_16x16_mmxext time = 19.949 cpl = 373.04
x264_pixel_ssd_16x8_mmxext time = 9.9340 cpl = 163.93
x264_pixel_ssd_8x16_mmxext time = 11.958 cpl = 206.19
x264_pixel_ssd_8x8_mmxext time = 8.2710 cpl = 129.21
x264_pixel_ssd_8x4_mmxext time = 4.9580 cpl = 60.030
x264_pixel_ssd_4x8_mmxext time = 6.9800 cpl = 102.25
x264_pixel_ssd_4x4_mmxext time = 6.1380 cpl = 84.668
x264_pixel_satd_16x16_mmxext time = 52.266 cpl = 1047.8
x264_pixel_satd_16x8_mmxext time = 28.471 cpl = 550.98
x264_pixel_satd_8x16_mmxext time = 27.129 cpl = 522.96
x264_pixel_satd_8x8_mmxext time = 15.372 cpl = 277.47
x264_pixel_satd_8x4_mmxext time = 9.2630 cpl = 149.92
x264_pixel_satd_4x8_mmxext time = 9.8940 cpl = 163.09
x264_pixel_satd_4x4_mmxext time = 6.2090 cpl = 86.151
x264_pixel_sad_16x16_sse2 time = 8.3320 cpl = 130.48
x264_pixel_sad_16x8_sse2 time = 5.4780 cpl = 70.888
x264_pixel_ssd_16x16_sse2 time = 18.106 cpl = 334.56
x264_pixel_ssd_16x8_sse2 time = 12.498 cpl = 217.47
x264_pixel_satd_16x16_sse2 time = 54.008 cpl = 1084.2
x264_pixel_satd_16x8_sse2 time = 28.981 cpl = 561.63
x264_pixel_satd_8x16_sse2 time = 28.001 cpl = 541.17
x264_pixel_satd_8x8_sse2 time = 15.452 cpl = 279.14
x264_pixel_satd_8x4_sse2 time = 9.3330 cpl = 151.38

[Sirber]

Doesn't seems faster to me :confused:

[squid_80]

To enable it for Pentiums and not Athlon64s you could use:
if((cpu&X264_CPU_SSE2)&&!(cpu&X264_CPU_3DNOW))
in pixel.c, to determine if the function pointers get assigned to the SSE2 functions. Should work because the Pentiums don't have 3DNow, and I *think* the Athlon64s were the first line of AMD chips with SSE2.

By the way, has that minibench utility been modified to use buffers that are not 16-byte aligned? I did that when I was using it for testing the AMD64 routines and it turned up a few surprises.

[708145]

I love to quote myself ;)

Given the recent Pentuim M results it seems that I was right, huh?

About SSE(2) optimization there are 2 things I'd like to note:
1) For optimal results, different code paths for AMD64, Pentium4 and Pentium-M are needed.
2) For memory latency dependent code even different code paths for various clockspeeds are neccessary.


bis besser,
Tobias

[CiNcH]

Here's how SSE instructions perform on my Intel Pentium M 1.6 GHz:

cpuspeed = 2088000000.000000
loops = 100000000
"mm: movq" time = 4.1050 cpl = 85.712
"mm: paddw" time = 8.1420 cpl = 170.00
"mm: psrlw" time = 10.655 cpl = 222.48
"mm: punpcklwd" time = 8.8430 cpl = 184.64
"mm: pmulhw" time = 8.5020 cpl = 177.52
"mm: pmaddwd" time = 8.4930 cpl = 177.33
"mm: psadbw" time = 8.6220 cpl = 180.03
"mm: paddw, movq" time = 4.1160 cpl = 85.942
"mm: paddw, psrlw" time = 8.1320 cpl = 169.80
"mm: paddw, punpcklwd" time = 8.1310 cpl = 169.78
"mm: paddw, pmulhw" time = 5.0780 cpl = 106.03
"mm: movq, paddw, movq, paddw" time = 4.1050 cpl = 85.712
"mm: movq, paddw, movq, psrlw" time = 4.0960 cpl = 85.524
"mm: movq, paddw, movq, pmulhw" time = 4.5970 cpl = 95.985
"mm: movq, paddw, pmulhw, psrlw" time = 4.5160 cpl = 94.294
"movq, paddw, movq, punpcklwd" time = 4.0960 cpl = 85.524
"xmm: movdqa" time = 10.766 cpl = 224.79
"xmm: paddw" time = 16.223 cpl = 338.74
"xmm: psrlw" time = 16.153 cpl = 337.27
"xmm: punpcklwd" time = 16.144 cpl = 337.09
"xmm: pmulhw" time = 16.483 cpl = 344.17
"xmm: pmaddwd" time = 16.504 cpl = 344.60
"xmm: psadbw" time = 16.684 cpl = 348.36
"xmm: paddw, movdqa" time = 13.499 cpl = 281.86
"xmm: paddw, psrlw" time = 17.496 cpl = 365.32
"xmm: paddw, punpcklwd" time = 13.529 cpl = 282.49
"xmm: paddw, pmulhw" time = 16.203 cpl = 338.32
"xmm: movdqa, paddw, movdqa, paddw" time = 13.490 cpl = 281.67
"xmm: movdqa, paddw, movdqa, psrlw" time = 13.469 cpl = 281.23
"xmm: movdqa, paddw, movdqa, pmulhw" time = 13.510 cpl = 282.09
"xmm: movdqa, paddw, pmulhw, psrlw" time = 14.801 cpl = 309.04
"xmm: movdqa, paddw, movdqa, punpcklwd" time = 12.157 cpl = 253.8
"xmm: movaps" time = 10.776 cpl = 225.00
"xmm: addps" time = 16.484 cpl = 344.19
"xmm: mulps" time = 16.213 cpl = 338.53
"xmm: addps, mulps" time = 16.203 cpl = 338.32
"xmm: movaps, addps" time = 13.399 cpl = 279.77
"xmm: movaps, addps, movaps, mulps" time = 13.490 cpl = 281.67
"xmm: movapd" time = 10.785 cpl = 225.19
"xmm: addpd" time = 16.484 cpl = 344.19
"xmm: mulpd" time = 32.276 cpl = 673.92
"xmm: addpd, mulpd" time = 16.224 cpl = 338.76
"xmm: movapd, addpd" time = 13.379 cpl = 279.35
"xmm: movapd, addpd, movapd, mulpd" time = 13.499 cpl = 281.86

[AlexI]

Hello,

Just a quick heads up, there is a new version of the SSE2 patch here:

http://www.geocities.com/x264hack/sse2-pixel-routines-v5.diff.txt

Pentium 4 users will see a 10-18% overall speedup depending on settings. No speedup for Pentium M or Athlon 64, sorry. It will only enable the new routines on CPUs on which they are faster. The new patch also fixes a small bug and fixes building in 64-bit mode.

This is getting ready to merge with the main branch in svn. Probably the last pre-merge version, actually. Enjoy.

-A.

[Sharktooth]

It's already included in my builds since revision 286 :)

[Revgen]

Pentium 4 users will see a 10-18% overall speedup depending on settings. No speedup for Pentium M or Athlon 64, sorry.

-A.

Thats not true for me. I estimate that I got about a 3% to 5% boost when encoding some of my Garfield cartoons about a week ago. It's not as much as what the P4 gets, but it is something.

Say a boost from 5fps to 5.25fps.

I'm comparing the difference between the 186 version and the 170 version.

[squid_80]

Thats not true for me. I estimate that I got about a 3% to 5% boost when encoding some of my Garfield cartoons about a week ago. It's not as much as what the P4 gets, but it is something.

Must be the SSD functions... Which can actually be made faster. Expand from bytes to words before subtracting and use two registers to accumulate results, adding them together at the end. Also when moving the final result do xmm->mem, mem->eax and it'll knock a few ms off (this could help all the functions).

[Kostarum Rex Persia]

I don't understand,how is possible to Intel get 10-18 % speed-up,and Athlon 64 only 3-5 %.

There is something very strange in that.But,all new Athlon 64 have SSE,SSE2 and SSE3 instructions.

[Sirber]

Intel and AMD doesn't implement those the same way. They have the same instruction set, but phisicaly they are not the same. A fast path for Intel might not be for AMD64.

[Kostarum Rex Persia]

Well,that explain a lot of things.Intel purposely do that.AMD is right about Intel.

[CiNcH]

Well,that explain a lot of things.Intel purposely do that.AMD is right about Intel.

You should probably have better background information before saying something like that.

A time ago I have seen some benchmarks, testing per clock SSE performance. AMD won over Intel. But as SSE performance seems to scale pretty well with clock speed Intel has an advantage here.

[Sirber]

Intel developed SSE/SSE2/SSE3 and implemented them first. AMD implemented them after. Guess who's more right :p

[CiNcH]

Overall SSE/SSE2 performance:

http://www.tecchannel.de/imgserver/bdb/341800/341839/29005CE123F42F0AC8D6CC22090F951B_1000x700.jpg http://www.tecchannel.de/imgserver/bdb/341800/341841/C6741FC6EED7939F6D18C4ADE3D33B3E_1000x700.jpg


Per clock SSE/SSE2 performance:

http://www.tecchannel.de/imgserver/bdb/341800/341840/E87DCF003AF6D893AAA7419C0F0F9B0D_1000x700.jpg http://www.tecchannel.de/imgserver/bdb/341800/341842/208361C9899B910E1BBA9B8D67C91155_1000x700.jpg


It becomes apparent that AMD's SSE implementation performs pretty well clock-wise.

[squid_80]

Don't know exactly what their tests involve, but note how the SSE2 tests are slower than SSE.

[Rash]

Well noted Squid. It is almost twice as faster.

[Sirber]

Not the same "calculs". Like comparing bananas and apples :)

[squid_80]

Not that I'm saying SSE2 can't go faster... It just needs to be tweaked appropriately. Here's how the SSE2 functions I developed for my AMD64 build perform with unaligned data (closer to real encoding situation):
cpuspeed = 2088000000.000000
loops = 100000000
emptyloop time = 0.00000 cpl = 0.00000

x264_pixel_sad_16x16_mmxext time = 3.9690 cpl = 82.873
x264_pixel_sad_16x16_sse2 time = 3.7500 cpl = 78.300

x264_pixel_sad_16x8_mmxext time = 2.1720 cpl = 45.351
x264_pixel_sad_16x8_sse2 time = 2.2650 cpl = 47.293

x264_pixel_ssd_16x16_mmxext time = 13.563 cpl = 283.20
x264_pixel_ssd_16x16_sse2 time = 10.609 cpl = 221.52

x264_pixel_ssd_16x8_mmxext time = 7.0160 cpl = 146.49
x264_pixel_ssd_16x8_sse2 time = 5.5310 cpl = 115.49

x264_pixel_ssd_8x16_mmxext time = 7.1410 cpl = 149.10
x264_pixel_ssd_8x16_sse2 time = 5.5000 cpl = 114.84

x264_pixel_ssd_8x8_mmxext time = 3.8440 cpl = 80.263
x264_pixel_ssd_8x8_sse2 time = 2.9840 cpl = 62.306

Trying to optimize SAD is a waste of time because it's too basic, which is a shame because it seems to take up most of the encoding time. The smaller SSD functions won't gain much over MMX either. The SATD functions I haven't done yet.

[CREXbzh]

Not that I'm saying SSE2 can't go faster... It just needs to be tweaked appropriately. Here's how the SSE2 functions I developed for my AMD64 build perform with unaligned data (closer to real encoding situation):
Are your patches available somewhere? :D

[squid_80]

Not yet, they're not finished. Also they take advantage of AMD64 specific features and won't translate easily to regular x86 code.

[Sirber]

AMD64 32-bit?

[Kostarum Rex Persia]

Not yet, they're not finished. Also they take advantage of AMD64 specific features and won't translate easily to regular x86 code.

squid_80,you are a fantastic man.I really hope that your SSE2 patch will came out soon.I also hope that Sharktooth will include your future SSE2 patch in next revision of x264 codec.

[squid_80]

AMD64 32-bit?
64-bit mode only. I use store to load forwarding to get data out of the xmm registers and into the general purpose registers quickly. Store to load forwarding will fail in 32-bit mode since the GPRs aren't 64-bits wide. So results have to be accumulated in another xmm register (clogging the FPU pipelines with more paddd instructions) and horizontally summed at the end...
It's do-able but won't be as fast.

[Sirber]

Well, you can still add the 64bit SSE2 code to x264 64bit asm :D Keep the good work!

[Rash]

Not the same "calculs". Like comparing bananas and apples :)
Why? We are comparing speed. Whoever is faster wins. ;)

[Sirber]

If the bench is not about SSE vs SSE2 on the same tasks, then it's useless. Beware, I'm prepared to fight to death to keep my opinion ;)

[foxyshadis]

The point wasn't comparing SSE to SSE2, it was comparing the relative performance of each on various high-end procs. I'd assume it was obvious that optimizing one particular application for SSE vs SSE2 tests would not be remotely applicable to applications in general, let alone any other specific application. (Much like the above mmx vs. sse results alone don't mean anything if they were brought up in the context of, say, a 3d renderer.)

Also the flops/clock ratio is absolutely useless, since Intel and AMD have wildly different architectures, which affects their relative clock speeds. It's obvious when they're stacked like that, I don't know why they bothered to list it. Maybe just to show clock speed comparison isn't important? Flops/price would be useful, and to a lesser extent, flops/PR-rating.

[Rash]

If the bench is not about SSE vs SSE2 on the same tasks, then it's useless. Beware, I'm prepared to fight to death to keep my opinion ;)
But that's the bench I was talking about. I thought he did the test on the same tasks.

[Sirber]

I don't know if it's the same task. CiNcH?

[Sharktooth]

"Double precision matrix multiply" for both tests.
However as you can see, athlon CPUs have better relative efficiency than P4s for both SSE and SSE2 but since they have a lower clock frequency the absolute speed is slower than those intel counterparts.
Now you know why Intel pushed for removing FP and MMX from WinXP 64 and from future versions of Windows...

[Kostarum Rex Persia]

Well,that's confirm my attitude that Intel is a monopoly company.And Microsoft too.

[riggits]

Well,that explain a lot of things.Intel purposely do that.AMD is right about Intel.

OK, I'm sick of your uninformed and prolific commentary on subjects you have no clue about.
Please visit arstechnica.com and read EVERY f*cking article there before posting again.
Here are some easy and obvious places to start:
[/url]
http://arstechnica.com/articles/paedia/cpu/ppc-1.ars (http://arstechnica.com/articles/paedia/cpu/amd-hammer-1.ars)
READ THIS!!! (http://arstechnica.com/articles/paedia/cpu/pipelining-1.ars)
[url]http://arstechnica.com/articles/paedia/cpu/pentium-1.ars
http://arstechnica.com/articles/paedia/cpu/pentium-m.ars
this one is verrrry interesting (http://arstechnica.com/articles/paedia/cpu/p4andg4e.ars)
http://arstechnica.com/articles/paedia/cpu/g4vsk7.ars

Well,that's confirm my attitude that Intel is a monopoly company.And Microsoft too.
Please TAKE A CLASS IN LOGIC!!! Holey crap. How do you function in society??!

(sorry all, but it needs to be said..)

[Sirber]

Arsh but needed :)