cujo said:
i wonder if the difference in boot speed is evidence to this. i'm not certain but when i install windows with oced cpu that's just set by multi and fsb i think i get slower boot speeds. since the most recent install i did when i had bios set to xp 3200+ i've noticed my comp boots super fast and continues to do so (even though cpu now set at 200x12). when i install stuff after format i keep all things equal yet sometimes my boot speed is way slower than other times. i've heard many people mention slower boot times with oced chips (especially 2500s) so maybe windows, when formatted with chip oced, doesn't recognize the extra cache or other optimizations of the barton.
i don't have the time to test this theory but someone here may.
It's doubtful. If it doesn't recognise it as the correct processor, you'll lose a few specific optimizations, probably mostly doing with what instructions programs use, for example SSE. Having booted linux both with and without SSE enabled on my CPU, I can tell you it makes no noicable difference in boot times. Of sourse, the kernel is entirely integer (except for the part that calculates bogomips, but that's not really all that usefull), and doesn't usually compile with SSE support anyway (not that the kernel doesn't support using SSE on the computer, in fact itturns on SSE support, butit doesn't itself use SSE). It may be that something strange is going on in your IDE/PCI bus. If they're locked, perhaps there is more overhead when they are not at an easy ratio of the FSB?
Prevail said:
i just tried encoding a mpeg with a whole slew of different optimizations. sse, mmx 3dnow 3dnow2, fpu, sse2. and with all of them i got different results. from 1.5 minutes to encode this file down to 65 seconds using sse2. so id say were fine. now stop your worrying 
Well that doesn't tell us a lot, because you forced the optimization support on. And, like I said, usually the BIOS enables SSE support on Athlon XPs, not the OS. The problem we are talking about is programs that have support for various optimizations (MMX, 3DNow, SSE). If they determine which code to run based on information they get from the OS which gets it from the BIOS which doesn't recognise the processor correctly, then they don't use the proper optimizations and performance is lost.
I don't know how programs/OSes actually do this, but I would think that to determine which optimizations to use, they would have to look at the feature flags of the processor. These tell of support for things like 3dnow, sse, sse2, and MMX. It would be very bad to just use them by CPU type, because like I said, SSE is not necessarily enabled on Athlon XPs. IF the program just detected it as an AXP and ran some SSE code on a AXP that did not have SSE enabled, bad things could happen. If, however, it checked to see if the SSE flag was present, it would only run SSE code on CPUs wit SSE support actually enabled.
Just for fun, here's the CPU in my laptop:
lappy src # cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : mobile AMD Athlon(tm) XP 1800+
stepping : 0
cpu MHz : 1500.698
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips : 2957.31
If I compile a kernel that doesn't enale SSE on my cpu at bootup, "sse" does not appear under flags.
