|This is the talk page for discussing improvements to the Hyper-threading article.|
|This article is of interest to the following WikiProjects:|
- 1 Plagiarism obvious in this article.
- 2 Contradiction
- 3 Hyper-threading related security weakness
- 4 Hyper-threading architecture
- 5 Clairvoyant Wikipedia?
- 6 cache sharing
- 7 codename
- 8 Needs disambiguation or explanation of difference from AMD's "HTT" or "Hyper Transport"
- 9 Requested move
- 10 Hyper-treading is not an Intel trademark ?
- 11 need special OS support or not?
- 12 Is HyperThreading really SMT?
- 13 Originally DEC technology patent
- 14 Super-Scaler Processor a design requirement for Hyper-Threading
- 15 "Hyper-Threading" vs. "HyperTransport"
- 16 dead link?
- 17 a bit dated?
- 18 CDC 6400 Peripheral Processors
- 19 Downside of HT
- 20 Is the headline image legit?
- 21 Reads like written by a hater 10 years ago.
- 22 Resource starvation
- 23 Intel performance conclusion
- 24 NPOV dispute - Performance claims
Plagiarism obvious in this article.
Someone, without even bothering to rephrase lines, has copied chunks of text from a website. The text is primarily:
- that need to be fixed very rapidely by
- changing it's state from plagiarism to fair use...that means citing the sources and simiilar thing
- then remplacing it...
- or asking the autorisation to the website
- by the way the adress changedd:http://www.osdcom.info/content/view/30/39/
- we must also check the dates in order to know who has copied(that could also be the website...)
220.127.116.11 09:38, 16 April 2006 (UTC)(only for the comment)
- Amusingly, the OSDEV article contains text copied from the Ars article on HTT. For example, the text
- appears in both articles (albeit the OSDEV version introduces a number of grammatical mistakes, and doesn't include the diagrams the text is referring to). As for the anon user's suggestion we need to fix this "rapidly", I don't see the rush—I'll remove and rewrite the copyvio'd material when I get a chance, if no one beats me to it. Neilc 18:16, 16 April 2006 (UTC)
- I don't think plagiarism or a violation of copyright in Wikipedia content is so "obvious" here. Wikipedia's changes are old and have been accumulating over a very long period of time. Here's an example, if you'll excuse the verbiage...
- Looking back at the history, the last sentence of the first paragraph in Wikipedia achieved its current form on 24 July 2003, and the first sentence got reasonably close in the same edit:
- This, of course, is the version that matches that appears on the OSDEV Web site.
- Of course, the OSDEV Web site was recently revamped, so all of their articles are dated 26 March 2006. This makes it hard to conclusively demonstrate that the content in Wikipedia is older, and that it's the OSDEV author who "borrowed" it. But the fact that Wikipedia content took form gradually over a two-year time period makes it hard for me to believe that someone really "copied chunks of text from a website" into Wikipedia. bert 19:18, 20 April 2006 (UTC)
- It looks nobody is able to prove the suspected copyvio because the site in question does not support a page history. If there's nothing new in the next days I'll remove the obvious wrong copyvio tag. It really looks more the OSDEV author used text from various other sites fo his own text. --Denniss 18:00, 25 April 2006 (UTC)
Hyper-Threading works by duplicating certain sections of the processor—those that store the architectural state—but not duplicating the main execution resources
is is also say that :
allowing multiple threads to run simultaneously
how can the processor EXECUTE 2 process or threads at once with only one execution unit...that's impossible
the reality is that:
- technicaly they duplicated "certain sections of the processor—those that store the architectural state—but not duplicating the main execution resources" allowing the processor to make a context switch in almost no time
- there is a huge marketting going on Hyper Threading saying that it behave as 2 processors
allowing the operating system to schedule two threads or processes simultaneously
mabe an expert could help me on this point because i have realy no idea
that's why i called for an expert,i doesn't know evrything on hyperthreading and it's specific design so i prefer beeing prudent and call an expert rather that make errors...
- There's no contradiction. Hyperthreading allows the processor dispatch instructions from two different threads to the processor's execution units. This is not the same as a very cheap context switch: the processor is capable of executing instructions from multiple threads simultaneously (by dispatching those instructions to different execution units). See the Ars article on HTT for more information. Neilc 18:11, 16 April 2006 (UTC)
- understood,i'll read this and then if i still have question i will ask here
18.104.22.168 22:35, 16 April 2006 (UTC)
- By the way i prefer over-reacting that doing nothing(discuting endlessly in the talk page,that kind of behaviour can lend to big mistakes such as what i've done but in another hand it permit changes,for example once evryone was talking endlessly on the talk page about a problem in a page(windows vs linux) i proposed a new design and nobody replyed and now my design is still there(and improved because it needed a lot of improvement...)),another example is the copyright violation that was signaled ONLY in the talk page and so not fixed(another fact is that users must take care themselves of this kind of task because of the low percentage of admin between all the wikipedia editors)
But i'm sorry to have made such technical error error...lol and thank a lot for the link!!! 22.214.171.124 22:35, 16 April 2006 (UTC)
Here is a paper that attempt to document data leaks related to hyper-threading. 
- I think the security link in the article should be removed (or explained). It's bunk. -- Mikeblas 08:42, 31 December 2005 (UTC)
- It's completely real, and somewhat terrifying for certain types of multi-user situations. Suppose there is a hospital computer that lets people phone in to get the results of AIDS tests. Suppose that the records for positive and negative results are a bit different in size or layout. Suppose an employee wants to know the status of someone, perhaps a coworker or a potential lover. Obviously, the employee is not authorized to view medical records for this purpose. The employee could use cache misses to observe what happens when the patient's data gets added to the system. While the technique is not 100% reliable, it can be good enough to cause problems. 126.96.36.199 21:24, 1 January 2006 (UTC)
- Cache misses aren't determnistic or predictale enough to reliably get the information. It's simply too abstract and indirect in order to be of any real threat. Has the alleged exploit ever been demonstrated in working code as a test? The premise is just silly; it's not specific to hyperthreading, and the flawed reasoning could be applied to dual-core proessors (those which share a level of cache) or even disk drives. -- Mikeblas 23:58, 1 January 2006 (UTC)
- You're not paranoid enough. This kind of stuff has been done, and has led to password compromise. Dual-core processors are indeed a danger. Anything shared can be a danger, though some things are worse than others. Another good example is CPU usage. A properly secured system does not allow low-security processes to run slower when high-security processes are active. This could be done with a dummy high-security process that runs if the real high-security process has nothing to do. The mere existance of an activity might reveal insider info that could be abused for stock trading or leaking word of military actions. 188.8.131.52 02:25, 3 January 2006 (UTC)
- This has nothing to do with your personal evaluation of my paranoia level. Let's stick to the facts: can you cite a reference or an example of the password snatching you've offered as an example? Or examples of systems which handle military actions or stock trading which also host abitrary guest processes? -- Mikeblas 04:24, 3 January 2006 (UTC)
- Look it up yourself. Some details to help you: I believe it was a DEC minicomputer. The password was placed across a page boundry. The password checking code would stop at the first mismatched character. By moving the password and observing execution time of the password checking routine, one could greatly reduce the guesses needed. You'd only need to guess one character at a time. So, to have an example with simple math, guessing a 5-digit numeric password would go from 100000 choices (50000 average guesses) to 50 choices (25 average guesses). Timing attacks are a time-tested part of breaking security; messing with cache misses or TLB misses is a form of timing attack. Check out the side channel attack article, which specifically mentions cache misses. Note: I haven't yet edited that page, and I did not place the original mention on this page either. The military certainly does care about multiple security levels on a single system; typically this is not authorized, in part because of problems like the one discussed here. Nobody would mix TOP SECRET with UNCLASSIFIED, but mixing two adjacent levels would often be useful. The stock example does not involve trading computers. Rather, it involves business operation computers whose activity reveals something of interest to a stock trader. Perhaps the date of a major activity is revealed before it is properly announced. Trades based on such info could be considered illegal insider trading, and could be harmful to some of the stockholders. 184.108.40.206 05:14, 3 January 2006 (UTC)
- I will, if you can give me one more hint: which DEC minicomputers use hyper-threading-enabled processors? -- Mikeblas 05:55, 3 January 2006 (UTC)
- Not only that but it makes the whole computer suceptible to crashing due to drivers not able to take two cpu's and then getting mixed up and so crashing. User:bmendonc 07:37, 16 April 2009 (UTC)
I thoat hyper-threading was an hardware implementation of thread switching processus who takes a lot of cpu time
From the article: "The real question is not whether Hyper-Threading returns, because it will, but how it works." Says who? While this may be true, predictions about the future must never be presented as facts. -- Grahn 17:26, 19 December 2005 (UTC)
- He was right though, since it will be in the new Intel i7. J5689 (talk) 17:05, 19 October 2008 (UTC)
Why did User:The1physicist delete the contribution about cache misses? Are the cache misses really less substantial than the effect the replay system has? Even if the issue is the replay system, the Intel documentation says that cache misses are one of the events that invoke the replay system. Is there any denying that cache misses (e.g./entirely* because of capacity and collisions) will be more frequent when the cache is shared between the two threads? -- Mikeblas 01:34, 3 January 2006 (UTC)
- I deleted it because it isn't true. Yes, running two threads will result in more cache misses, but your overall throughput is still higher. Cache misses do invoke the replay system (among other things), but cache misses are not responsible for decreasing performance. As proof, look at the two benchmarks here. Hyperthreading got its bad reputation from the abysmal performance of the Northwood core. However, Prescott's hyperthreading has been vastly improved. As the second benchmark attests, the Prescott CPU has an increase in performance despite massive cache misses.the1physicist 21:37, 6 January 2006 (UTC)
Can someone add which processors have hyperthreading?
HT was codenamed "Jackson Technology"
Needs disambiguation or explanation of difference from AMD's "HTT" or "Hyper Transport"
Not qualified to write it just know it needs to be done. When I look up HTT, I'm expecting an explanation of AMD's Hyper Transport, which is listed on Atlon 64s and relevant motherboards as HTT. It has something to do with AMD's version of frontside bus. Cheers. —The preceding unsigned comment was added by Mlhwitz (talk • contribs) 15:06, 20 February 2007 (UTC).
Correct title should be Hyper-Threading (currently a redirect here), not Hyper-threading. This is the name as used by Intel, and in fact as used repeatedly throughout this article. If there are no objections, I will move it in a few days. — Aluvus t/c 00:02, 14 March 2007 (UTC)
- Well, I think moving the article to Hyper-Threading Technology would be more appropriate, as the article states it is the official brand name. Saxbryn 11:21, 18 March 2007 (UTC)
Hyper-treading is not an Intel trademark ?
The single expression "Hyper-threading" does not appear as such in the lists of trademark nouns on the Intel Website. Is there any reference or evidence for the first sentence claming that it is an Intel trademark ? Intel does not claim it.
- See: intel trademarks in english and in french —Preceding unsigned comment added by Jp78450 (talk • contribs) 09:52, 29 October 2007 (UTC)
Does not appear to be an Intel trademark, based on Intel's own list of trademarks, and the US Patent and Trademark Office Trademark Electronic Search System. Furthermore, Intel's own description of Hyper-Threading does not mark Hyper-Threading as a trademark. 220.127.116.11 (talk) 03:38, 23 June 2009 (UTC)
need special OS support or not?
The introduction says
Conventional multiprocessor support is not enough to take advantage of hyper-threading.
The "Details" section says
All that is required to take advantage of Hyper-Threading is symmetric multiprocessing (SMP) support in the operating system, as the logical processors appear as standard separate processors.
- Yeah, this was bothering me, too. Obviously these entries were made by separate people. I won't claim to be an expert on how HTT and the OS mesh, but I'm fairly sure that while OS-level SMP support is all you need for threads to be passed to each virtual processor, if the OS is not aware of the HTT nature of the processor, it may for example on a dual processor HTT setup pass two threads to the same processor, rather than one to each processor which would be the desired result. It seems that the OS needs to be HTT-aware so it knows to balance threads between physical processors/cores. Obviously this wouldn't be a problem on a single HTT processor setup. --18.104.22.168 (talk) 01:47, 20 September 2008 (UTC)
- I've corrected this statement. HT does not require OS support, the referenced page is referring to HT Logo Certification. This can be verified by Googling for experiences of people that have used HT-enabled CPUs in Win2k, and is consistent with the technology as described in the rest of this article. Alereon (talk) 07:49, 3 May 2009 (UTC)
Is HyperThreading really SMT?
Reading this article, it sounds like HyperThreading is replicating enough software context that each thread can run an OS. That's not the same thing as SMT, which is the ability to simultaneously execute instructions from multiple different threads within one pipeline stage. So my question is HyperThreading really SMT?
Also, people ought to realize that HyperThreading - whether it's SMT or the OS-capable hw context (or both), is an Intel marketing name. Other architectures have equivalent facilities which use different nomenclature. The article ought to mention that this is an Intel marketing name. Dyl (talk) 03:13, 3 January 2009 (UTC)
- HyperThreading stores an extra context so that the processor can quickly switch contexts if one process. To the operating system and above, this behaves like SMT. rictic (talk) 03:44, 13 February 2009 (UTC)
Originally DEC technology patent
I think there needs to be at least a link to the fact that DEC created this technology and Intel had to settle a lawsuit/agreement with them to get out of it...
Quote "In 1997, Intel licensed the patents and hired many of the employees who worked on the project as part of a massive legal settlement between the companies"
This was well known in Alpha programming circles at the time (I was a software engineer working on DEC Alphas at the time) but for some reason Intel or whoever has been very good at brushing it under the carpet. —Preceding unsigned comment added by 22.214.171.124 (talk) 19:52, 26 May 2009 (UTC)
Super-Scaler Processor a design requirement for Hyper-Threading
My understanding of Intel's Hyper-Threading processors requires that the processor a super-scaler one in order to have at least two separate execution units in order to execute the simultaneous threads. There's no mention of this and how hyper-threading really works. Additionally, the diagram presented in this article of hyper-threading makes no sense. Either a different diagram needs to be presented or text must accompany the current diagram to explain what is happening. 126.96.36.199 (talk) 21:12, 17 August 2009 (UTC)
I found an excellent article on hyper-threading on Ars-Technica and found that who ever put the hyper-threading diagram up copied it from this article. This article did not mention that super-scaler processors are a requirement but did point out that multiple execution units along with other processor features (like separate IPs) are necessary. --188.8.131.52 (talk) 23:05, 17 August 2009 (UTC)
"Hyper-Threading" vs. "HyperTransport"
Regarding my edit here, Denniss' reversion here ("rev section deleting; the section was there for a reason: to explain what HT is and what many user believe HT to be"), and Widefox's additional link (this): none of this addresses the fundamental flaws in that section.
Basically, the statement "There has been some marketing confusion..." is unsourced and unquantified (WP:WEASEL), and the statement "It is sometimes, though incorrectly, referred to as HT" is demonstrably false. Intel used an emblem with "HT" or "Pentium 4 HT inside" on its P4 processor boxes and logos (see de:Intel Pentium 4 for sample images) and continues to use "HT Technology" in its marketing and technical materials—that's the foremost authority asserting that it is in fact a correct usage. Conversely (although I don't know how true this is), the HyperTransport article says that that name should be spelled out, not abbreviated, according to the HyperTransport consortium.
Furthermore, it appears you're using the IBM link as a reference to support the contention that "HT" is incorrect in this context—that's an original synthesis, because nowhere does that reference say that this is an incorrect usage. (You can't just point to an example of what you believe is incorrect usage; you've got to reference someone else making that observation.) The IBM link is properly used to reference the Linux kernel information (a variable "ht" exists), but that information is so trivial that it hardly bears mentioning.
The recently-added link states "So, what is HyperTransport technology? It's a new technology, that'll probably use the abbreviation HT and be confused with Intel's HyperThreading Technology." That's evidence that one reviewer speculated that the technologies would be confused on the basis of their abbreviations. That's not evidence that such confusion took place, nor the notability of that confusion—it's just a statement of a hypothetical problem.
In any event, if you genuinely think that encyclopedia readers will be confused (irrespective of the level of confusion in the marketplace), the way to deal with this is a disambiguation page. That exists already. As for the rather remote possibility that someone will end up at this article while having HyperTransport in mind, I'm adding a disambiguation link.
I'm also removing the "Name" section, per all of the above concerns. You probably shouldn't put it back unless you track down some sources that support the nature of the confusion and incorrectness you mentioned. TheFeds 00:57, 10 November 2009 (UTC)
Hyper-Threading Technology Architecture and Microarchitecture, technical description of Hyper-Threading (1.2 MB PDF-file) Appears to be dead. Cannot open or save. Pity too because I wanted to use it for a project :( -Winter123 (talk) 22:59, 10 November 2009 (UTC)
a bit dated?
Just curious why every example in the article seems to be based off the pentium 4. Shouldn't we really base it off the more modern processors like the i7 with maybe a note it originally started in the p4 instead of the opposite like it is now? The article has a very dated feel and feels like a blast from the past. I have no idea if the performance is similar on the i7 or vastly different. Seems like a kind of important fact. -Tracer9999 (talk) 19:23, 3 March 2010 (UTC)
- I agree. Some hard info on more modern processors would be appreciated. Riordanmr (talk) 19:10, 10 January 2015 (UTC)
CDC 6400 Peripheral Processors
The CDC 6400 (circa 1964) had 10 Peripheral Processors. In hardware, each PP had its own state but they all shared one execution unit. The wikipedia page on the 6400 mentions it. Sounds just like Hyper Threading to me. —Preceding unsigned comment added by 184.108.40.206 (talk) 02:46, 20 September 2010 (UTC)
- From what I can understand, the main idea with hyper-threading is that you use more than one separate execution units in parallel for different threads. For example, one thread can use the integer multiplication unit while another is busy dividing a floating point number. What the CDC 6400 article describes is another common setup, which seems to speed up switching between threads. pipatron (talk) 13:44, 26 June 2012 (UTC)
- How can we make this article more clear?
- Would a list like the following help?
- scalar processor: a single thread, with a single program counter, using a single execution unit.
- barrel processor: Multiple threads, each with their own program counter and other state, sharing a single execution unit. (Apparently the CDC 6400 is in this category).
- superscalar: a single thread, with a single program counter, executing multiple instructions (all from the same thread, and typically more-or-less sequential in memory) simultaneously on multiple execution units.
- symmetric multiprocessing: multiple identical processors, each running a different thread, each processor with its own dedicated program counter and other state, and each with its own dedicated execution unit.
- simultaneous multithreading (such as hyper-threading): a combination of a barrel processor and a superscalar processor, such that two simultaneously-executing instructions may be from different threads fetched from widely separated locations in memory, each thread with its own program counter and other state.
- ... super-threading, temporal multithreading, etc. ...
- --DavidCary (talk) 19:38, 8 October 2013 (UTC)
Downside of HT
Would someone be able to contribute information about the downside of HT. I believe it would be nice if someone could talk about the situations where you don't want to use this technology, (to turn it off). 220.127.116.11 (talk) 03:43, 31 August 2011 (UTC)
I agree this would be helpful. On chips with both turbo boost and HT it seems like there would be a trade-off between fewer/faster real cores with more/slower virtual cores. Jp489x (talk) 18:22, 29 February 2012 (UTC)
From the specs I understand HT switches between threads with lower overhead. While this overhead is lower it's still existing. Now if program checks the number of processing cores and forks according to this the result is less work done. HT is mostly useful in production environment with tens or hundreds of threads simultaneously running. Anttir717 (talk) 07:27, 22 May 2012 (UTC)
- I wouldn't be so sure about this before running a benchmark. Even the most trivial algorithms would use different execution engines. One line will multiply, the next will add, and those are two different execution units in the CPU. Sometimes you stall while reading a new batch of data to process, while the other thread can perform a few more operations. Running two identical threads could just as well be faster because you get rid of some of these problems. pipatron (talk) 13:57, 26 June 2012 (UTC)
Hyper threading does improve throughput. This is not the same as performance. Performance is how well something performs in relation to the task or goal it is assigned. So for a task where throughput is the most important goal, Hyper Threading improves performance. However, for low latency work such as real time audio or CNC (computer controled machining) where reliable low latency operation is required (in the case of CNC for safeties sake) Hyper threading results in missed time commitments causing buffer over runs. I have found that a P4 running at 2.4Ghz has a minimum guaranteed latency of over 3ms with HT turned on in bios and less than .66ms with it turned off. I have not been able to repeat this experiment on newer CPUs as I bought an i5 in my latest machine with no HT. My measurement method is to tune jackd to a certain number of samples per buffer and see how low I can go before I start to see under runs. 128samples at 48000 samples per second with HT on and 32 with HT off. The latency may be even less with HT off, but that is the minimum buffer size with my audio interface (ice1712 based) I can use. Through put and latency are both measures of "performance", but high performance through put, generally comes at the cost of latency performance while latency performance often lowers through put performance. I don't know how to cite my own experiments so I have added it to the talk page rather than the main page. More information can be found on pages that deal with the real time Linux kernel and it's use in CNC. Len 18.104.22.168 (talk) 01:21, 28 March 2015 (UTC)
- First P4 with HT appeared in 2003 and last in 2005. I wonder how modern (for example Haswell (microarchitecture)) CPUs would fare in your tests. King Vivil talk 19:51, 30 March 2015 (UTC)
Is the headline image legit?
The headlining image in this article may have been put in the "public domain" by its creator, but appears nearly identical to an image by Jon Stokes at ArsTechnica.
Reads like written by a hater 10 years ago.
HT is well understood nowadays.
1. No OS that is installed on a common computer has any problem with it.
2. Benchmarks _consistently_ show an improvement with it.
3. Single threaded applications consistently show a marginal benefit with it and never a negative.
- I think because it's the real history which the article is presenting. Hyperthreading has a 'rich history' of challenges, one myth is that it is simply a context switch (or save) mechanism. This is what I was told, and it seems to be quite common today going on some of the comments here. (The article has it right.) It wasn't until I was faced with the decision of buying an i7 vs i5 some years ago that I really looked into it, and realised the extra virtual processor uses actual physical resources of a superscalar core in parallel. I'm glad I got the i7, with big performance gains when encoding video. I just came here to see what they generally are these days, the article seems to be a bit out of date in that area. Adx (talk) 00:02, 4 September 2013 (UTC)
- 1. Operating Systems that have no support for HyperThreading will do scheduling wrong, it is still a valid problem. OS needs to consider hyperthreading. Fortunately all mainstream OS have pretty good support for HT, but this does not mean that the statement is invalid.
- 2. Please link the benchmarks, but that should also depend on OS support and the workload.
- 3. I can believe that if no other process takes the other logical cpus of the same core, but where does the article say the opposite?
- --K0zka (talk) 08:57, 9 January 2014 (UTC)
The latest rewrite doesn't really help here. What actually happens is that HT reduces lulls between CPU requests for memory accesses. (Resource requests for things other than memory would of course cause a standard context switch.) If these requests successfully overlap memory fetches with computation (on the same physical core, but a different virtual core) then HT is a win, but if the excess fetches simply knock data out of the CPU cache just before it is needed again then HT is a loss. Simple enough? Hcobb (talk) 16:47, 5 February 2014 (UTC)
http://software.intel.com/en-us/intel-hyper-threading-technology-your-questions-answered On a server with high CPU utilization, it can open up more performance on each core. In general, you will see the most benefit from Hyper-Threading when running software threads that experience large memory or other latencies. Suppose for example you have 2 software threads running on 2 hardware threads both running on the same core. If the 2 software threads each have some I/O, long memory access, or sleep times then you are more likely see a significant benefit from Hyper-Threading. (Because having 2 hardware threads allows for more efficient use of resources during long periods of waiting.)
Intel performance conclusion
- "A November 2009 analysis by Intel concludes that performance impacts of hyper-threading result in increased overall latency in case the execution of threads does not result in significant overall throughput gains. In other words, overall processing latency is significantly increased due to hyper-threading, with the negative effects becoming smaller as there are more simultaneous threads that can effectively use the additional hardware resource utilization provided by hyper-threading."
Current article states that according to conclusion of article which I will quote below there is always a negative impact to performance with HT enabled.
This is said reference of above quote (https://software.intel.com/en-us/articles/performance-insights-to-intel-hyper-threading-technology):
- Intel HT Technology boosts performance for many applications, resulting in higher performance and higher efficiency. Applications that scale well with cores will typically also scale well with Intel HT Technology. The Nehalem core brings many improvements that complement Intel HT technology, allowing significant performance gains.
- Core and thread counts will continue to increase, and good multi-core scaling will continue to be important into the future.
- It is important when evaluating performance of applications running with Intel HT Technology to understand the differences in performance tool data and that many times, comparing data between Intel HT Technology disabled and Intel HT Technology enabled systems requires more than an intuitive understanding to accurately assess the performance implications.
- Finally, Intel is committed to helping the ISV community and system users attain the best performance on Intel systems. We encourage you to visit the Intel Developer Zone Parallel Programming and Multi-Core Developer Community for any questions not addressed here on Intel HT Technology and other Intel products."
- Indeed, the referenced article is not a really good one. --K0zka (talk) 20:23, 26 February 2015 (UTC)
- Hello! It is by no means about finding references that fit just to craft specific content; the content is based exclusively on references, not vice-versa.
- There are no reasons to restrict the reference to its "Conclusion" section, and "a November 2009 analysis by Intel concludes that..." doesn't imply that; I've a bit so any confusion is avoided. If you read the whole reference, you'll see that the article content matches it very well; for eaxmple, please read the "Latency versus Throughput" section in the reference and have a look at the chart in Figure 12. That section clearly confirms that "performance impacts of hyper-threading result in increased overall latency in case the execution of threads does not result in significant overall throughput gains", as the article states.
- Can anyone provide better references, please? I'd be more than happy to have more than a few of them. — Dsimic (talk | contribs) 04:02, 28 February 2015 (UTC)
- I've read this section and it clearly confirm that opposite is true. That section show two scenarios: no performance gain and performance gain of x1.25. As you can see this is contrary to current article which state that there is no/minimal performance gain.
- Just above the graph there is explanation of increased latency:
- "Note that while this would seem to indicate that response time would increase with Intel HT Technology enabled for a variety of server workloads, this is generally not the case. The CPU time does increase, but typically, wait time in OS queues decreases. An example is described later in this paper to illustrate this result. Please see the article "Hyper-Threading: Be Sure You Know How to Correctly Measure Your Server's End-User Response Time" for additional exploration of the impact of Intel Hyper-Threading Technology on end-user server response times."
- Again this is contrary to current article which states that latency is significantly increased.
- I can provide more references but I don't see the point in this currently because this is likely that my contribution will get twisted to contrary of what reference say. King Vivil talk 17:51, 28 February 2015 (UTC)
- Let's just have a look at the chart in Figure 12, which shows "relative compute latency of threads running with Intel HT Technology enabled versus disabled for a different performance gains with Intel HT Technology". As we can see, relative thread latency never touches the 1.0 value, even for a very significant 1.7× throughput/performance gain achieved by turning hyper-threading on, which is pretty much as far as hyper-threading can go. If the 1.4–2.0 factor for increased thread latency isn't significant, I really don't know what would be significant. Also, could you please provide some of the references you've mentioned? — Dsimic (talk | contribs) 08:12, 1 March 2015 (UTC)
- So you agree that it can significantly increase performance. Why do you then do not include this scenario in the article? Also note that graph show only execution latency of thread on CPU and it doesn't take into account reduced latency in OS queue which is vital for understanding real execution latency. I've written about it above. I've also written about additional references. King Vivil talk 12:59, 1 March 2015 (UTC)
- Overall performance and throughput aren't the same thing, what the chart clearly shows; the whole hyper-threading thing might be compared to the bufferbloat phenomenon, to some extent of course. Also, the process scheduler queue latency doesn't necessarily reflect the overall execution latency: threads/processes might get to run more frequently, but that doesn't necessarily mean they will finish faster, what's highly dependant on what the processes actually do and how well the hardware sharing works out for them. Which sources you refer to? Sorry, but I see no links. — Dsimic (talk | contribs) 13:36, 1 March 2015 (UTC)
NPOV dispute - Performance claims
Neutral point of view is disrupted in last paragraph of this section. Current article use reference which explain this technology. But current statements are opposite of findings in the reference because of strong bias and erroneous understanding. I've written about errors in section above after unsuccessful attempt to resolve the issue by editing article (my edits were reverted numerous times). Second reference in this paragraph is not available any more but it's possible to access it by Internet Archive here. Current article state it's "performance analysis" while it's small section which [Typo. I meant with. King Vivil talk 13:24, 2 March 2015 (UTC)] one small erroneous argument based on outdated misunderstanding of this technology which assume that each core work with half speed with HT turned ON. King Vivil talk 13:30, 1 March 2015 (UTC)
- How do you conclude on my misunderstanding "that each core work with half speed with HT turned ON"? That's nonsense. Also, you've mentioned additional sources more than once, but hand-waving doesn't cut it: show me the links, please, I want to read them. By the way, the second reference is perfectly accessible. — Dsimic (talk | contribs) 13:59, 1 March 2015 (UTC)
- Looks like we have a language barrier here. I understand this isn't your native language so I'll explain in detail; don't worry.
- I wrote that this is the misunderstanding of the technology in the second reference. I didn't write this is your misunderstanding (unless you're the author of that article).
- This is what that article is saying near the end of section.
- I said why I won't post more references. But for a start I can show you this.
- I've checked different browsers. It's not working for me in Chrome but it works in Firefox. Why would this website block Chrome from access? Hmmm.. King Vivil talk 14:36, 1 March 2015 (UTC)
- I would appreciate if you weren't trying to put me down, as my knowledge of the English language is good enough to understand very well everything you write. However, please don't get me wrong, but your style of writing could be slightly better and less mangled, with fewer grammar mistakes; for example, you should have written one of the sentences above as "currently, the article uses a reference which explains this technology", or "current version of the article uses references which explain this technology" – note my corrections in bold. So much about the language barrier.
- I had a look at http://www.extremetech.com/computing/133121-maximized-performance-comparing-the-effects-of-hyper-threading-software-updates (which I also ), and that source benchmarks hyper-threading on a very high level, without going into latency vs. throughput. As the Hyper-threading § Performance claims section describes, latency increases "in case the execution of threads does not result in significant overall throughput gains"; thus, it clearly states that throughput gains are a reality. In other words, and if you read it carefully enough, that description never ruled out the possibility for hyper-threading to result in higher throughput.
- By the way, I'm not the author of the https://calomel.org/network_performance.html article, and I can't know why there are issues with certain web browsers. — Dsimic (talk | contribs) 05:14, 2 March 2015 (UTC)
- If someone says that my English is bad and I can't understand something, while that isn't true, of course I'll take that personally. Just as another reminder, this time for you: WP:COMPETENCE. However, I agree that we need input from more editors. — Dsimic (talk | contribs) 20:09, 2 March 2015 (UTC)