Intel Files Patent For Software-Defined Super Cores, Allowing 2 or More Cores to Function as One

This has been the wholly grail ever since hyperthreading and multicore were introduced. It's literally been decades since I saw the first efforts to make multicores work as one.
 
I wonder how much the software puts on overhead. This could be awesome for msql servers though. Especially considering license costs.
 
Grimlakin said:
I wonder how much the software puts on overhead. This could be awesome for msql servers though. Especially considering license costs.
Click to expand...
SQL server is muticore happy, so I don't think it would benefit as much.
 
My worry is OS scheduling problems; history has proven that desktop Windows is terrible at it and it takes MS forever to catch up with support, and then it's still not perfect.
 
Last edited:
Stoly said:
SQL server is muticore happy, so I don't think it would benefit as much.
Click to expand...
Yes and no.. it is multithreaded happy but being able to reduce core count to accelerate your threads would a boon for some and save on licensing.
 
Grimlakin said:
Yes and no.. it is multithreaded happy but being able to reduce core count to accelerate your threads would a boon for some and save on licensing.
Click to expand...
You're still paying for those cores. And SQL already uses parallelism for query acceleration.
 
Riccochet said:
You're still paying for those cores. And SQL already uses parallelism for query acceleration.
Click to expand...
We don't know that. If this is a bios level change like SMT to Hyperthreading but in reverse it will appear to the OS as fewer cores... and fewer cores = more performance. Right now we build some of our critical infrastructure with 50% more cores than we need to use day to day, but we turn 1/2 of them off in the bios. Having them available if we need the performance later.

So for us being able to just enable all cores and get the performance for our heavily threaded use, then we can save on core count licensing for SQL and have more performance at the same time for the same cost we would spend on those servers. IT's a win win. And since we JUST refreshed, our next cycle is a few years out as it stands so that would let this product stack mature as well.
 
Not all MySQL queries can be parralled to decrease execution time.

Some things have to go in a specific order 1 at a time.

If this can make the "single core" performance of that accelerate then I'm very interested.
 
Skillz said:
Not all MySQL queries can be parralled to decrease execution time.

Some things have to go in a specific order 1 at a time.

If this can make the "single core" performance of that accelerate then I'm very interested.
Click to expand...

Thank vendors that haven't updated their database design in 20+ years and just keep it compatible with current SQL revisions.
 
Grimlakin said:
We don't know that. If this is a bios level change like SMT to Hyperthreading but in reverse it will appear to the OS as fewer cores... and fewer cores = more performance. Right now we build some of our critical infrastructure with 50% more cores than we need to use day to day, but we turn 1/2 of them off in the bios. Having them available if we need the performance later.

So for us being able to just enable all cores and get the performance for our heavily threaded use, then we can save on core count licensing for SQL and have more performance at the same time for the same cost we would spend on those servers. IT's a win win. And since we JUST refreshed, our next cycle is a few years out as it stands so that would let this product stack mature as well.
Click to expand...

Vast majority of SQL environments are virtualized. And being a VMWare engineer myself I can't think of one reason why I'd want core reduction/binding at the BIOS level on my hosts. That would limit my ability to provision cores for multi-threaded applications.
 
Riccochet said:
Vast majority of SQL environments are virtualized. And being a VMWare engineer myself I can't think of one reason why I'd want core reduction/binding at the BIOS level on my hosts. That would limit my ability to provision cores for multi-threaded applications.
Click to expand...
You're not running very big SQL servers. :) I don't want to run servers with 32 cores and 512+ gigs of ram as a VM. Not without a 100 gig backbone for vm migration. OOF.
 
Smaller SQL boxes... SURE all day every day but the core reducing/binding isn't for those environments. some VM infrastructure you can just assign more priority to existing threads .. but SQL licensing is just so **** expensive you need to be running a cluster for all SQL for it to make sense.
 
Grimlakin said:
Thank vendors that haven't updated their database design in 20+ years and just keep it compatible with current SQL revisions.
Click to expand...

I've tried to update mine, but it got way, way worse performance. I had to move it back to MYISAM. InnoDB was 3x slower even when I tried implementing parallel processing.
 
Grimlakin said:
We don't know that.
Click to expand...
How do we not know this? MSSQL has been out for ages, and it's one of the most well documented servers out there.

The fact that the server can use parallelism is a totally different question than if a particular query can use it though...
 
Grimlakin said:
Yes and no.. it is multithreaded happy but being able to reduce core count to accelerate your threads would a boon for some and save on licensing.
Click to expand...
apples and oranges my friend, apples and oranges.

I think SQLserver would be the worst example. AFAIK SQLserver benefits more from more cores than faster cores.
 
Stoly said:
apples and oranges my friend, apples and oranges.

I think SQLserver would be the worst example. AFAIK SQLserver benefits more from more cores than faster cores.
Click to expand...
Again this is all use case based. There isn't a blanket this way is fastest all of the time... I mean other than having enough ram to load your entire database into memory....
 
Brian_B said:
How do we not know this? MSSQL has been out for ages, and it's one of the most well documented servers out there.

The fact that the server can use parallelism is a totally different question than if a particular query can use it though...
Click to expand...
SQL can handle that already. That what max degree of parallelism is for. We can dictate how many cores a query can potentially use. Whether that is efficient is up to the query design.

@Grimlakin And we have VM SQL servers with 32+ cores and 512+ GB of RAM. It makes no sense to put them on dedicated hardware when the hosts have exponentially more resources than that. Our clusters are massive. Been doing this for years as a VCAP.
 
Riccochet said:
SQL can handle that already. That what max degree of parallelism is for. We can dictate how many cores a query can potentially use. Whether that is efficient is up to the query design.

@Grimlakin And we have VM SQL servers with 32+ cores and 512+ GB of RAM. It makes no sense to put them on dedicated hardware when the hosts have exponentially more resources than that. Our clusters are massive. Been doing this for years as a VCAP.
Click to expand...
Oh ok that's cool. My clusters don't have nodes.. errr actually they do I we just don't like the idea of having our DB's in the cluster.. Sharing IOP's is not for us, nor is setting up direct mapped shares per host for the VM's themselves... I suppose I could read up on doing that, haven't tinkered with it. Now you got me thinking about it. lol. 512 is doable, but our host CPU's could get constrained... Our use for our environment is EXTREMELY time critical. We can't loose ticks. humm... worth revisiting though our hosts HAVE the threads and memory since our last refresh...

Do you license your entire virtual cluster for MSSQL? That's where the licensing becomes muddy for us and overly expensive.
 
Not to say mine is bigger than yours, but our last SQL on premise server has 64cores and 1TB ram.

From then on everything goes to the cloud.
 
You must log in or register to reply here.
Become a Patron!
Back
Top