Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Locked thread
evensevenone
May 12, 2001
Glass is a solid.

Nonpython posted:

With HyperThreading, the job scheduler needs to know how to deal with "full cores" and "shared cores." For instance, if you have 4 cores with HT, if you are only running 4 threads, you want them each spread out on to individual cores, you don't want all 4 of them sharing 2 cores while other cores are sitting idle. That is a relatively low level of scheduler complexity (relatively speaking.) But when 2 more threads come through, as you start sharing cores, you want to try to optimize the threads around execution. Let's say you have all 4 cores active with threads, 2 "heavy" threads and 2 "light" threads. If you need to "double up" the 2 new threads, you'd rather put them on the 2 cores that have light loads right now. So, this is a much more complex level of complexity. So, with HyperThreading, you have an added level of complexity. You have to think about WHERE to put threads vs. just looking for the next available resource.

This isn't actually true. The schedulers aren't that complex, and it ends up being OK because each core has multiple functional units and can do more than one thing at once, so the rate of structural hazards blocking execution is very very low even with HT.

That said, we have more transistors than we know what to do with nowadays so we might as well just go for more cores.

Adbot
ADBOT LOVES YOU

evensevenone
May 12, 2001
Glass is a solid.

fishmech posted:

Ask yourself: how many programs were ported to Itanium Windows? How many programs were ported to PowerPC Windows NT (when that existed)?

There's no particular reason to expect people to take the effort to compile ARM binaries.

Edit: Almost forgot: remember when there were like 4 different processor architectures for Windows CE 2.x/3.x? Remember how most programs would only be compiled for one architecture and the others ignored by the developer?

That was a long time ago though, when everything was written in C++ and using Win32, and a lot of code ended up being very low level and it was a pretty big deal to port something to a different architecture.

But people don't develop that way anymore. If you're using Java or a .NET language it's going to require no effort at all to port. You might have some QA issues just to sort out weird differences between the VMs. Same for most of the modern high-level languages, they're basically cross platform already.

Plus developers are already used to linux/BSD where you're targeting 10+ architectures or OSX where there was a long period of having both PPC and x86.

evensevenone
May 12, 2001
Glass is a solid.

fishmech posted:

Both systems with a vastly smaller software ecosystem than Windows, genius.


Did you just learn about .,net and Java or something? How naive :allears:

You're right, it it is just as difficult to write cross platform software as it was in 1998 when PPC NT was last relevant.

evensevenone
May 12, 2001
Glass is a solid.
Are you seriously arguing that win32 is as portable as .net? That's kind of what it sounds like.

evensevenone
May 12, 2001
Glass is a solid.

blowfish posted:

That... defeats the entire point of fines. Which is the point, I guess.

Well, technically, it defeats 35% of the point of fines. Assuming your corporation actually shows profits.

  • Locked thread