Who on earth would be using 95, 98 or NT and running any form of BOINC anyway?

I have a 930 MHz Coppermine Dell host on Windows 98 SE which runs both Einstein and SETI.

Do you object?

No.

---

Who on earth would be using 95, 98 or NT and running any form of BOINC anyway?

I have an NT 4.0 server that works perfectly, does a specific job just fine, and is in no desperate need of being upgraded.

Should I stop running BOINC on it, or should I invest time and money to upgrade the OS when that won't change what it does, or make it run any faster or better?

Keep crunching

---

...
Most of what I'm doing these days is real-time, interrupt-driven, and network intensive -- but it doesn't even think about floating point, it's all integer math (and mostly shifts and masks). I like the C3 CPU alot.
...

Oh SSE+ does integer math too. really fast.

IIRC, that was the big complaint about MMX, fast integer math, but no FP.

I rarely have a case where I'm doing the same op on an array of values, so SIMD doesn't help, unfortunately.

---

Who on earth would be using 95, 98 or NT and running any form of BOINC anyway?

I have an NT 4.0 server that works perfectly, does a specific job just fine, and is in no desperate need of being upgraded.

Should I stop running BOINC on it, or should I invest time and money to upgrade the OS when that won't change what it does, or make it run any faster or better?

NT4.0 was always rock-solid........if it's doin' what you need it to do, no reason to change it.....

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Like I said in the other thread. I finally actually read the tech specs for SSE2 and SSE3.

Using SSE3 instead of SSE2 is apparently safe. It does not look like any new registers were introduced here.

Using SSE2 instead of SSE does not look safe. SSE2 doubled the size of the registers. If the OS does not support SSE2, then it does not know to save the extra length of the registers.

The move from MMX to SSE also does not look safe. SSE introduced new registers that MMX did not have. If the OS does not know about these, then these registers will not be saved.

I did not loook at SSE4. If it uses the same registers as SSE2, then it is also a safe migration.

Incorrect context switches with these registers are more likely to produce garbage results than a crash.

---

BOINC WIKI

Like I said in the other thread. I finally actually read the tech specs for SSE2 and SSE3.

Using SSE3 instead of SSE2 is apparently safe. It does not look like any new registers were introduced here.

Using SSE2 instead of SSE does not look safe. SSE2 doubled the size of the registers. If the OS does not support SSE2, then it does not know to save the extra length of the registers.

The move from MMX to SSE also does not look safe. SSE introduced new registers that MMX did not have. If the OS does not know about these, then these registers will not be saved.

I did not loook at SSE4. If it uses the same registers as SSE2, then it is also a safe migration.

incorrect context switches with these registers are more likely to produce garbage results than a crash.

No problem with that except the two bolded points.
- SSE2 does not change the size of (they are still 128 bit) or add any registers (still XMM0-XMM7) [over SSE]... It does extend some MMX instructions to also work in XMM registers which could easily be confused with that. [It does add double precision floating point instructions, but these operate in the same 8 x XMM registers, using each 128 bit register to fit 2x64 bit doubles]

- secondly, An improper context switch could be either an OS issue, which will manifest in far more serious ways, or an application's programming failing to preserve certain general (not XMM) registers, failing to preserve these will generate a "This application has caused an error" type error.

I get the impression that there are errors in software applications being blamed on OS [or even hardware] bogeys. Errors in the application data are more likely to arise from limitations of floating point operations & representation, and a programmer error or misunderstanding on those limitations of precision in floating point. There are golden rules for handling this. In SSE, as the exceptions [such as even a simple divide by zero] are handled predominantly in hardware, this leads to the possibility of a missed data test case being transparently caught. Only thorough [carefully planned] testing can reveal these as they WOULD [& DO!] show as subtle data corruptions. [This occurs in FPU code also]

Mixed MMX/FPU code is not safe unless very carefully handled. Stepping from MMX to SSE , they are two separate entities, this code can generally be mixed. FPU & MMX cannot. SSE2 shifts MMX capability to work in both MMX & SSE(XMM) registers, A real bonus if you want to use the FPU as well.

I could rabble on about this stuff forever, but I'll stop as it's going nowhere, we'll probably just have to agree to disagree on a few fundamental points. If an OS isn't context switching correctly, then it is broken IMO and as far as I know Win98 and XP context switch all 8 x 128bit SSE registers just fine.

Jason

[Edit: typos]

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Like I said in the other thread. I finally actually read the tech specs for SSE2 and SSE3.

Using SSE3 instead of SSE2 is apparently safe. It does not look like any new registers were introduced here.

Using SSE2 instead of SSE does not look safe. SSE2 doubled the size of the registers. If the OS does not support SSE2, then it does not know to save the extra length of the registers.

The move from MMX to SSE also does not look safe. SSE introduced new registers that MMX did not have. If the OS does not know about these, then these registers will not be saved.

I did not loook at SSE4. If it uses the same registers as SSE2, then it is also a safe migration.

incorrect context switches with these registers are more likely to produce garbage results than a crash.

No problem with that except the two bolded points.
- SSE2 does not change the size of (they are still 128 bit) or add any registers (still XMM0-XMM7) [over SSE]... It does extend some MMX instructions to also work in XMM registers which could easily be confused with that. [It does add double precision floating point instructions, but these operate in the same 8 x XMM registers, using each 128 bit register to fit 2x64 bit doubles]

- secondly, An improper context switch could be either an OS issue, which will manifest in far more serious ways, or an application's programming failing to preserve certain general (not XMM) registers, failing to preserve these will generate a "This application has caused an error" type error.

I get the impression that there are errors in software applications being blamed on OS [or even hardware] bogeys. Errors in the application data are more likely to arise from limitations of floating point operations & representation, and a programmer error or misunderstanding on those limitations of precision in floating point. There are golden rules for handling this. In SSE, as the exceptions [such as even a simple divide by zero] are handled predominantly in hardware, this leads to the possibility of a missed data test case being transparently caught. Only thorough [carefully planned] testing can reveal these as they WOULD [& DO!] show as subtle data corruptions. [This occurs in FPU code also]

Mixed MMX/FPU code is not safe unless very carefully handled. Stepping from MMX to SSE , they are two separate entities, this code can generally be mixed. FPU & MMX cannot. SSE2 shifts MMX capability to work in both MMX & SSE(XMM) registers, A real bonus if you want to use the FPU as well.

I could rabble on about this stuff forever, but I'll stop as it's going nowhere, we'll probably just have to agree to disagree on a few fundamental points. If an OS isn't context switching correctly, then it is broken IMO and as far as I know Win98 and XP context switch all 8 x 128bit SSE registers just fine.

Jason

[Edit: typos]

The master has spoken....unless you're running WIN95 and BOINC (LOL and let's face it, no one is), then all is well!

Like I said in the other thread. I finally actually read the tech specs for SSE2 and SSE3.

Using SSE3 instead of SSE2 is apparently safe. It does not look like any new registers were introduced here.

Using SSE2 instead of SSE does not look safe. SSE2 doubled the size of the registers. If the OS does not support SSE2, then it does not know to save the extra length of the registers.

The move from MMX to SSE also does not look safe. SSE introduced new registers that MMX did not have. If the OS does not know about these, then these registers will not be saved.

I did not loook at SSE4. If it uses the same registers as SSE2, then it is also a safe migration.

incorrect context switches with these registers are more likely to produce garbage results than a crash.

No problem with that except the two bolded points.
- SSE2 does not change the size of (they are still 128 bit) or add any registers (still XMM0-XMM7) [over SSE]... It does extend some MMX instructions to also work in XMM registers which could easily be confused with that. [It does add double precision floating point instructions, but these operate in the same 8 x XMM registers, using each 128 bit register to fit 2x64 bit doubles]

- secondly, An improper context switch could be either an OS issue, which will manifest in far more serious ways, or an application's programming failing to preserve certain general (not XMM) registers, failing to preserve these will generate a "This application has caused an error" type error.

I get the impression that there are errors in software applications being blamed on OS [or even hardware] bogeys. Errors in the application data are more likely to arise from limitations of floating point operations & representation, and a programmer error or misunderstanding on those limitations of precision in floating point. There are golden rules for handling this. In SSE, as the exceptions [such as even a simple divide by zero] are handled predominantly in hardware, this leads to the possibility of a missed data test case being transparently caught. Only thorough [carefully planned] testing can reveal these as they WOULD [& DO!] show as subtle data corruptions. [This occurs in FPU code also]

Mixed MMX/FPU code is not safe unless very carefully handled. Stepping from MMX to SSE , they are two separate entities, this code can generally be mixed. FPU & MMX cannot. SSE2 shifts MMX capability to work in both MMX & SSE(XMM) registers, A real bonus if you want to use the FPU as well.

I could rabble on about this stuff forever, but I'll stop as it's going nowhere, we'll probably just have to agree to disagree on a few fundamental points. If an OS isn't context switching correctly, then it is broken IMO and as far as I know Win98 and XP context switch all 8 x 128bit SSE registers just fine.

Jason

[Edit: typos]

The master has spoken....unless you're running WIN95 and BOINC (LOL and let's face it, no one is), then all is well!

I have a Win95 client that I was running. I only powered down because I cannot afford the electricity anymore, otherwise I'd still be running it.

Like I said in the other thread. I finally actually read the tech specs for SSE2 and SSE3.

Using SSE3 instead of SSE2 is apparently safe. It does not look like any new registers were introduced here.

Using SSE2 instead of SSE does not look safe. SSE2 doubled the size of the registers. If the OS does not support SSE2, then it does not know to save the extra length of the registers.

The move from MMX to SSE also does not look safe. SSE introduced new registers that MMX did not have. If the OS does not know about these, then these registers will not be saved.

I did not loook at SSE4. If it uses the same registers as SSE2, then it is also a safe migration.

incorrect context switches with these registers are more likely to produce garbage results than a crash.

No problem with that except the two bolded points.
- SSE2 does not change the size of (they are still 128 bit) or add any registers (still XMM0-XMM7) [over SSE]... It does extend some MMX instructions to also work in XMM registers which could easily be confused with that. [It does add double precision floating point instructions, but these operate in the same 8 x XMM registers, using each 128 bit register to fit 2x64 bit doubles]

- secondly, An improper context switch could be either an OS issue, which will manifest in far more serious ways, or an application's programming failing to preserve certain general (not XMM) registers, failing to preserve these will generate a "This application has caused an error" type error.

I get the impression that there are errors in software applications being blamed on OS [or even hardware] bogeys. Errors in the application data are more likely to arise from limitations of floating point operations & representation, and a programmer error or misunderstanding on those limitations of precision in floating point. There are golden rules for handling this. In SSE, as the exceptions [such as even a simple divide by zero] are handled predominantly in hardware, this leads to the possibility of a missed data test case being transparently caught. Only thorough [carefully planned] testing can reveal these as they WOULD [& DO!] show as subtle data corruptions. [This occurs in FPU code also]

Mixed MMX/FPU code is not safe unless very carefully handled. Stepping from MMX to SSE , they are two separate entities, this code can generally be mixed. FPU & MMX cannot. SSE2 shifts MMX capability to work in both MMX & SSE(XMM) registers, A real bonus if you want to use the FPU as well.

I could rabble on about this stuff forever, but I'll stop as it's going nowhere, we'll probably just have to agree to disagree on a few fundamental points. If an OS isn't context switching correctly, then it is broken IMO and as far as I know Win98 and XP context switch all 8 x 128bit SSE registers just fine.

Jason

[Edit: typos]

It was my impression that SSE used 64 bit registers and SSE2 used 128 bit registers.

An improper context switch (caused by the OS not understanding the hardware as the OS does the context switch) can cause a wide variety of problems. Typically a missed register that the OS does not use for anything will just cause program errors, not system crashes.

---

BOINC WIKI

Like I said in the other thread. I finally actually read the tech specs for SSE2 and SSE3.

Using SSE3 instead of SSE2 is apparently safe. It does not look like any new registers were introduced here.

Using SSE2 instead of SSE does not look safe. SSE2 doubled the size of the registers. If the OS does not support SSE2, then it does not know to save the extra length of the registers.

The move from MMX to SSE also does not look safe. SSE introduced new registers that MMX did not have. If the OS does not know about these, then these registers will not be saved.

I did not loook at SSE4. If it uses the same registers as SSE2, then it is also a safe migration.

incorrect context switches with these registers are more likely to produce garbage results than a crash.

No problem with that except the two bolded points.
- SSE2 does not change the size of (they are still 128 bit) or add any registers (still XMM0-XMM7) [over SSE]... It does extend some MMX instructions to also work in XMM registers which could easily be confused with that. [It does add double precision floating point instructions, but these operate in the same 8 x XMM registers, using each 128 bit register to fit 2x64 bit doubles]

- secondly, An improper context switch could be either an OS issue, which will manifest in far more serious ways, or an application's programming failing to preserve certain general (not XMM) registers, failing to preserve these will generate a "This application has caused an error" type error.

I get the impression that there are errors in software applications being blamed on OS [or even hardware] bogeys. Errors in the application data are more likely to arise from limitations of floating point operations & representation, and a programmer error or misunderstanding on those limitations of precision in floating point. There are golden rules for handling this. In SSE, as the exceptions [such as even a simple divide by zero] are handled predominantly in hardware, this leads to the possibility of a missed data test case being transparently caught. Only thorough [carefully planned] testing can reveal these as they WOULD [& DO!] show as subtle data corruptions. [This occurs in FPU code also]

Mixed MMX/FPU code is not safe unless very carefully handled. Stepping from MMX to SSE , they are two separate entities, this code can generally be mixed. FPU & MMX cannot. SSE2 shifts MMX capability to work in both MMX & SSE(XMM) registers, A real bonus if you want to use the FPU as well.

I could rabble on about this stuff forever, but I'll stop as it's going nowhere, we'll probably just have to agree to disagree on a few fundamental points. If an OS isn't context switching correctly, then it is broken IMO and as far as I know Win98 and XP context switch all 8 x 128bit SSE registers just fine.

Jason

[Edit: typos]

It was my impression that SSE used 64 bit registers and SSE2 used 128 bit registers.

An improper context switch (caused by the OS not understanding the hardware as the OS does the context switch) can cause a wide variety of problems. Typically a missed register that the OS does not use for anything will just cause program errors, not system crashes.

SSE registers are 128Bits wide and that they do not necessarly contain only one value. The special SSE registers are called XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6 and XMM7 (some trivia between the lines: these 8 registers are exact sufficient for a very elegant multiplication of 4x4 matrices). Each of them can hold up to four single precision (32Bit) floats at a time where the first float occupies Bits 0-31 of the register, the second Bits 32-63, the third 64-95 and the last 96-127. This is what we call a 'Packed Single'.

[edit] From Vector normalization done fast [/edit]

John McLeod VII wrote:

It was my impression that SSE used 64 bit registers and SSE2 used 128 bit registers.

An improper context switch (caused by the OS not understanding the hardware as the OS does the context switch) can cause a wide variety of problems. Typically a missed register that the OS does not use for anything will just cause program errors, not system crashes.

As CRMofTheCrop already said, SSE uses 128-bit registers.

I think you are confusing SSE with MMX registers...

Here is excerpt from Intel compiler documentation on intrinsics...

Intel processors provide special register sets. 

The MMX instructions use eight 64-bit registers (mm0 to mm7) which are aliased on the floating-point stack registers. 

The Streaming SIMD Extensions use eight 128-bit registers (xmm0 to xmm7).

Regards,
JDWhale

---

John McLeod VII wrote:

It was my impression that SSE used 64 bit registers and SSE2 used 128 bit registers.

An improper context switch (caused by the OS not understanding the hardware as the OS does the context switch) can cause a wide variety of problems. Typically a missed register that the OS does not use for anything will just cause program errors, not system crashes.

As CRMofTheCrop already said, SSE uses 128-bit registers.

I think you are confusing SSE with MMX registers...

Here is excerpt from Intel compiler documentation on intrinsics...

Intel processors provide special register sets. 

The MMX instructions use eight 64-bit registers (mm0 to mm7) which are aliased on the floating-point stack registers. 

The Streaming SIMD Extensions use eight 128-bit registers (xmm0 to xmm7).

Regards,
JDWhale

... and there are another 8 XMM registers on the ia-64 if I'm reading the documentation correctly.

In theory FXSAVE and FXRSTOR knows all of the SSE* registers by definition.

In practice, I still think I'd be very cautious.

---

John McLeod VII wrote:

It was my impression that SSE used 64 bit registers and SSE2 used 128 bit registers.

An improper context switch (caused by the OS not understanding the hardware as the OS does the context switch) can cause a wide variety of problems. Typically a missed register that the OS does not use for anything will just cause program errors, not system crashes.

As CRMofTheCrop already said, SSE uses 128-bit registers.

I think you are confusing SSE with MMX registers...

Here is excerpt from Intel compiler documentation on intrinsics...

Intel processors provide special register sets. 

The MMX instructions use eight 64-bit registers (mm0 to mm7) which are aliased on the floating-point stack registers. 

The Streaming SIMD Extensions use eight 128-bit registers (xmm0 to xmm7).

Regards,
JDWhale

... and there are another 8 XMM registers on the ia-64 if I'm reading the documentation correctly.

In theory FXSAVE and FXRSTOR knows all of the SSE* registers by definition.

In practice, I still think I'd be very cautious.

ia-64 is the itanium. It is like apples and oranges from the x86

---

John McLeod VII wrote:

It was my impression that SSE used 64 bit registers and SSE2 used 128 bit registers.

An improper context switch (caused by the OS not understanding the hardware as the OS does the context switch) can cause a wide variety of problems. Typically a missed register that the OS does not use for anything will just cause program errors, not system crashes.

As CRMofTheCrop already said, SSE uses 128-bit registers.

I think you are confusing SSE with MMX registers...

Here is excerpt from Intel compiler documentation on intrinsics...

Intel processors provide special register sets. 

The MMX instructions use eight 64-bit registers (mm0 to mm7) which are aliased on the floating-point stack registers. 

The Streaming SIMD Extensions use eight 128-bit registers (xmm0 to xmm7).

Regards,
JDWhale

... and there are another 8 XMM registers on the ia-64 if I'm reading the documentation correctly.

In theory FXSAVE and FXRSTOR knows all of the SSE* registers by definition.

In practice, I still think I'd be very cautious.

ia-64 is the itanium. It is like apples and oranges from the x86

I think we're getting a little too literal. Concept being that the processor designers have taken on the responsibility when they say "use FXSAVE and give us a 512 byte buffer."

In theory, if the OS uses FXSAVE/FXRESTOR per the specification as written in the late 90's, the manufacturers have promised that it'll work with processors heading off into the future.

In theory.

---

John McLeod VII wrote:

It was my impression that SSE used 64 bit registers and SSE2 used 128 bit registers.

An improper context switch (caused by the OS not understanding the hardware as the OS does the context switch) can cause a wide variety of problems. Typically a missed register that the OS does not use for anything will just cause program errors, not system crashes.

As CRMofTheCrop already said, SSE uses 128-bit registers.

I think you are confusing SSE with MMX registers...

Here is excerpt from Intel compiler documentation on intrinsics...

Intel processors provide special register sets. 

The MMX instructions use eight 64-bit registers (mm0 to mm7) which are aliased on the floating-point stack registers. 

The Streaming SIMD Extensions use eight 128-bit registers (xmm0 to xmm7).

Regards,
JDWhale

... and there are another 8 XMM registers on the ia-64 if I'm reading the documentation correctly.

In theory FXSAVE and FXRSTOR knows all of the SSE* registers by definition.

In practice, I still think I'd be very cautious.

ia-64 is the itanium. It is like apples and oranges from the x86

And from what I've read Itanium needs to emulate x86 to be x86 compatible, So It's definitely comparing Apples to Oranges, Unless one is Apple Computer suing a computer company called Orange for trying to make an Apple II clone(A while before the Apple II died of old age).

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

Can I draw the attention of NC readers / posters to this post by JM7 which seems to disagree violently with sentiments that have often been expressed here.

F.

The Poster is wrong, if an OS support the mechanism for SSE, all the Intel extension, from SSE2 to SSE4.2 uses the same mechanism, there is no issue.

who?