Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Does simultaneous multithreading still make sense?

codeblueprint.co.uk

Post reply on HN
Print view View original

61–66 of 66 posts

Re: Does simultaneous multithreading still make sense?

#61

Post by tyingq »

AdrianB1 wrote: post #49
altmind wrote: post #5

Of course SMT makes sense. Why would it not be? Article says that thats because ppl only count the threads in their "cpuinfo" output and get the wrong impression? Intel vulnerabilities are not SMT vulnerabilities per-se, they are side channel attacks on a specific SMT implementation.

When you pay licenses per-CPU and SMT is doubling the cost with the licenses without doubling the performance, SMT does not make sense. For other cases, it makes. There is no universal use case for it.

There's a persistent rumour that Oracle does this, but they don't. For example:

"Amazon EC2 and RDS - count two vCPUs as equivalent to one Oracle Processor license"

https://www.oracle.com/assets/cloud-licensing-070579.pdf

Is there a vendor that does count a hyperthread as a core for software licensing?

Re: Does simultaneous multithreading still make sense?

#62

Post by zamadatix »

jcelerier wrote: post #59
zamadatix wrote: post #57

Earlier quoted context omitted.

Can you give examples of something that scales via threading but requires in a single thread the function takes 500 microseconds instead of 600 microseconds to compute that actually contradicts that "most" systems aren't this way?

Most professionnal audio software is like that - you can have e.g. a thread per track to make it simple but you also have to ensure that each execution cycle does not take more than 1 millisecond else you get audio glitches. And there is no limit to how hard you have to improve - this is a central factor for people buying your software (see dawbench) and artists really really don't like limits - they will always try…

Agreed but I'd hardly call pure software professional real time audio setups a disruptor of the vast majority of systems. Put all of these niche compute heavy multithreaded real time use cases and you have I.e. my claim was "There aren't really many 'performance critical' multithreaded environments in the world." not that there aren't any.

Re: Does simultaneous multithreading still make sense?

#63

Post by jcelerier »

zamadatix wrote: post #62
jcelerier wrote: post #59

Earlier quoted context omitted.

Most professionnal audio software is like that - you can have e.g. a thread per track to make it simple but you also have to ensure that each execution cycle does not take more than 1 millisecond else you get audio glitches. And there is no limit to how hard you have to improve - this is a central factor for people buying your software (see dawbench) and artists really really don't like limits - they will always try…

Agreed but I'd hardly call pure software professional real time audio setups a disruptor of the vast majority of systems. Put all of these niche compute heavy multithreaded real time use cases and you have I.e. my claim was "There aren't really many 'performance critical' multithreaded environments in the world." not that there aren't any.

> Agreed but I'd hardly call pure software professional real time audio setups a disruptor of the vast majority of systems.

I mean, there's still a few hundred thousand people registered on DAW-related forums so certainly a fair bit more are using those. That is more than a dozen european countries. Sure, it's not angry birds but I do not think that it is relevant to cater to the lowest common denominator of software.

Re: Does simultaneous multithreading still make sense?

#64

Post by touisteur »

ridiculous_fish wrote: post #53

How will SMT evolve with the frequency down-clocking required by AVX-512? Might a thread be penalized because it happens to be executed concurrently with a AVX-512 thread on the same score?

I thought down-clocking was on the first generation of low-end almost-not-Xeons with AVX-512? Will a 2018/19 Xeon Gold or Platinum really down-clock?

Re: Does simultaneous multithreading still make sense?

#65

Post by rumanator »

tyingq wrote: post #61
AdrianB1 wrote: post #49

Earlier quoted context omitted.

When you pay licenses per-CPU and SMT is doubling the cost with the licenses without doubling the performance, SMT does not make sense. For other cases, it makes. There is no universal use case for it.

There's a persistent rumour that Oracle does this, but they don't. For example: "Amazon EC2 and RDS - count two vCPUs as equivalent to one Oracle Processor license" https://www.oracle.com/assets/cloud-licensing-070579.pdf Is there a vendor that does count a hyperthread as a core for software licensing?

Please don't cherry pick quotes. The full quote with the bit you left out is as follows:

> Amazon EC2 and RDS - count two vCPUs as equivalent to one Oracle Processor license if hyper-threading is enabled, and one vCPU as equivalent to one Oracle Processor license if hyper-threading is not enabled.

As you see, your own quote confirms that yes the rumors are true: Oracle does charge per CPU.

Re: Does simultaneous multithreading still make sense?

#66

Post by tyingq »

rumanator wrote: post #65
tyingq wrote: post #61

Earlier quoted context omitted.

There's a persistent rumour that Oracle does this, but they don't. For example: "Amazon EC2 and RDS - count two vCPUs as equivalent to one Oracle Processor license" https://www.oracle.com/assets/cloud-licensing-070579.pdf Is there a vendor that does count a hyperthread as a core for software licensing?

Please don't cherry pick quotes. The full quote with the bit you left out is as follows: > Amazon EC2 and RDS - count two vCPUs as equivalent to one Oracle Processor license if hyper-threading is enabled, and one vCPU as equivalent to one Oracle Processor license if hyper-threading is not enabled. As you see, your own quote confirms that yes the rumors are true: Oracle does charge per CPU.

Yeah, that's what I said. Oracle charges per core. I didn't cherry pick anything.
Post reply on HN