Mike: FYI, you are aware that MS doesn't recommend that you run more than one server app per machine, right? SQL Server appears to have hardcoded that recommendation. <img src="graemlins/lol.gif" border="0" alt="[Laughing]" />
... why do corporate IT departments buy MS crap if that's the case? Why don't they just screw it and go Linux or some other Unix solution [our favorite would be nice of course] ...
Cost of migration?
Cost of training?
Plain stupidity?
Blinded by Marketing?
Open Bar At The MS Golf Course of Choice?
By the hahnd of Zeus, what manner of deviltry is this? I mean ... what gives?
My BIG dissapointment was that SQL wouldn't even run with more than 2G RAM installed. We knew that SQL was limited but we have some other applications that run on the machine as well and we were wanting to keep 6G RAM for use with the other apps...NOPE...SQL won't even start up with more than 2G RAM in the machine. Grrrrrr.
</strong><hr></blockquote>
You need to have MS SQL Server Enterprise Edition (rather than Standard Edition) for more than 2GB of RAM.
I know, it's lame that the Standard Edition won't run and just constrain itself to 2GB max. RAM usage, but at least there's a solution.
Isn't HT causing licensing problems? For instance say my company is running ISA Server and it's license is Per Processor. Won't HT or any SMT system cause problems with these apps? Has Microsoft already fixed this?
It's quite obvious that Per Processor licenses will have to be dramatically changed. Imagine a 32 Way Server with 4 threads per proc and it's licensing ....OUCH!</strong><hr></blockquote>
Yes and no. So far all companies we deal with for high end software only charge us for the actual number of physical cpu's. Where you are talking $7,000.00/cpu that means a whole lot!
Mike: FYI, you are aware that MS doesn't recommend that you run more than one server app per machine, right? SQL Server appears to have hardcoded that recommendation. <img src="graemlins/lol.gif" border="0" alt="[Laughing]" />
<hr></blockquote>
Yeah...we are working with some legacy stuff that I would LOVE to get rid of (FoxPro stuff) but we still need. For process scheduling we just threw it on the same machine to make life much easier. MS just wants us to purchase DataCenter SQL (or whatever it is called now) to support more memory.
A side note with all this discussion about MS app licensing:
I have switched nearly 100% of our operations from Windows to Linux. What's odd about this is that MS is a client of ours
The ONLY reason I was so dependent on Windows is that I purchased this company from out of Sunnyvale CA (belly up dot com) and they were 110% pro-Microsoft, vb, etc. Myself and the original team I put together was and is 110% pro Linux, php, etc (exept for my SQL DB administrator) so we slowly migrated 100% of our front end to Linux and about 50% of our back-end to Linux.
We had two primary reasons for switching:
1 - Performance - I knew that we could write a system that was MUCH better than our current system in both features and performance if we did it on some Unix variant with PHP/C etc.
2 - Price - Microsoft wanted $40,000.00 to license SQL on our database server about 2 years ago. There was no way I was going to spend that much money on software. I don't run the company like a dot com...I run it like a bricks and mortar company...maybe that is why we are 2.5 years down the road and profitable ;-)
Bottom line -- Mircrosoft made it easy for us to do business elsewhere.
So, back to the 970...
I will say this! Apple had better do something. If you have ever used a PIV Xeon you know what I am talking about!
<strong>What are the real world benefits of hyperthreading?
I heard that IBM mulled over adding hyperthreading logic to the POWER4 as they were designing it, but decided not to as it had limited real world advantages.
Is it buzzword compliant crap or something that could actually be useful?</strong><hr></blockquote>
I stumbled across some interesting papers on SMT the other day. "Simultaneous multithreading" (aka Intel's HyperThreading) has actually been around for a long time -- there was actually a conceptual SMT PPC design done by a researcher about ten years ago. The reason its only showing up in generalized processor designs now is because it is most advantageous on highly super-scalar, long pipeline designs. The current designs are the first ones where all other avenues for improving performance have been pursued far enough that SMT now represents the best choice for further improvements. Intel's not the only one following this path, either -- Sun's next UltraSPARC is 8-way (IIRC) SMT, and IBM's POWER5 will be as well.
SMT doesn't inherently represent a performance hit for straightline code. The design of the scheduling hardware could take several different approaches to its task, some of which ensure that the "primary" thread doesn't lose any of its performance although this does then require the OS to be aware of the hardware scheduler. A full SMT implementation does clearly represent a very significant improvement in a processor's efficiency, although this likely won't show up directly in single-thread performance. In a multi-threaded OS, however, a single thread can run faster because there will be fewer context switches. Based on the analysis in one of the papers I read, in the future I think we can expect to see at least 4-way SMT per core.
Comments
<strong>
Mike: FYI, you are aware that MS doesn't recommend that you run more than one server app per machine, right? SQL Server appears to have hardcoded that recommendation. <img src="graemlins/lol.gif" border="0" alt="[Laughing]" />
</strong><hr></blockquote>
Wha?!?!?!?! :eek:
GTFOH! <img src="graemlins/bugeye.gif" border="0" alt="[Skeptical]" />
NS? <img src="graemlins/surprised.gif" border="0" alt="[surprised]" />
BWA-HA-HA-HA-HA ... !!!!!!!!!!!!! <img src="graemlins/lol.gif" border="0" alt="[Laughing]" /> <img src="graemlins/lol.gif" border="0" alt="[Laughing]" /> <img src="graemlins/lol.gif" border="0" alt="[Laughing]" />
... why do corporate IT departments buy MS crap if that's the case? Why don't they just screw it and go Linux or some other Unix solution [our favorite would be nice of course] ...
Cost of migration?
Cost of training?
Plain stupidity?
Blinded by Marketing?
Open Bar At The MS Golf Course of Choice?
By the hahnd of Zeus, what manner of deviltry is this? I mean ... what gives?
[edit, freakin' spelling]
[ 03-15-2003: Message edited by: OverToasty ]</p>
<strong>
My BIG dissapointment was that SQL wouldn't even run with more than 2G RAM installed. We knew that SQL was limited but we have some other applications that run on the machine as well and we were wanting to keep 6G RAM for use with the other apps...NOPE...SQL won't even start up with more than 2G RAM in the machine. Grrrrrr.
</strong><hr></blockquote>
You need to have MS SQL Server Enterprise Edition (rather than Standard Edition) for more than 2GB of RAM.
I know, it's lame that the Standard Edition won't run and just constrain itself to 2GB max. RAM usage, but at least there's a solution.
Or use Oracle. And pay through the nose.
<strong>Mike,
Isn't HT causing licensing problems? For instance say my company is running ISA Server and it's license is Per Processor. Won't HT or any SMT system cause problems with these apps? Has Microsoft already fixed this?
It's quite obvious that Per Processor licenses will have to be dramatically changed. Imagine a 32 Way Server with 4 threads per proc and it's licensing ....OUCH!</strong><hr></blockquote>
Yes and no. So far all companies we deal with for high end software only charge us for the actual number of physical cpu's. Where you are talking $7,000.00/cpu that means a whole lot!
Mike: FYI, you are aware that MS doesn't recommend that you run more than one server app per machine, right? SQL Server appears to have hardcoded that recommendation. <img src="graemlins/lol.gif" border="0" alt="[Laughing]" />
<hr></blockquote>
Yeah...we are working with some legacy stuff that I would LOVE to get rid of (FoxPro stuff) but we still need. For process scheduling we just threw it on the same machine to make life much easier. MS just wants us to purchase DataCenter SQL (or whatever it is called now) to support more memory.
I have switched nearly 100% of our operations from Windows to Linux. What's odd about this is that MS is a client of ours
The ONLY reason I was so dependent on Windows is that I purchased this company from out of Sunnyvale CA (belly up dot com) and they were 110% pro-Microsoft, vb, etc. Myself and the original team I put together was and is 110% pro Linux, php, etc (exept for my SQL DB administrator) so we slowly migrated 100% of our front end to Linux and about 50% of our back-end to Linux.
We had two primary reasons for switching:
1 - Performance - I knew that we could write a system that was MUCH better than our current system in both features and performance if we did it on some Unix variant with PHP/C etc.
2 - Price - Microsoft wanted $40,000.00 to license SQL on our database server about 2 years ago. There was no way I was going to spend that much money on software. I don't run the company like a dot com...I run it like a bricks and mortar company...maybe that is why we are 2.5 years down the road and profitable ;-)
Bottom line -- Mircrosoft made it easy for us to do business elsewhere.
So, back to the 970...
I will say this! Apple had better do something. If you have ever used a PIV Xeon you know what I am talking about!
<strong>What are the real world benefits of hyperthreading?
I heard that IBM mulled over adding hyperthreading logic to the POWER4 as they were designing it, but decided not to as it had limited real world advantages.
Is it buzzword compliant crap or something that could actually be useful?</strong><hr></blockquote>
I stumbled across some interesting papers on SMT the other day. "Simultaneous multithreading" (aka Intel's HyperThreading) has actually been around for a long time -- there was actually a conceptual SMT PPC design done by a researcher about ten years ago. The reason its only showing up in generalized processor designs now is because it is most advantageous on highly super-scalar, long pipeline designs. The current designs are the first ones where all other avenues for improving performance have been pursued far enough that SMT now represents the best choice for further improvements. Intel's not the only one following this path, either -- Sun's next UltraSPARC is 8-way (IIRC) SMT, and IBM's POWER5 will be as well.
SMT doesn't inherently represent a performance hit for straightline code. The design of the scheduling hardware could take several different approaches to its task, some of which ensure that the "primary" thread doesn't lose any of its performance although this does then require the OS to be aware of the hardware scheduler. A full SMT implementation does clearly represent a very significant improvement in a processor's efficiency, although this likely won't show up directly in single-thread performance. In a multi-threaded OS, however, a single thread can run faster because there will be fewer context switches. Based on the analysis in one of the papers I read, in the future I think we can expect to see at least 4-way SMT per core.