-
We tested the Nvidia App performance problems — games can run up to 15 percent slower with the app
phial
Splendid
- Oct 29, 2002
- 6,757
- 0
- 25,780
stfu, his post made sense and i enjoyed it
better than the stupid flame wars that everyone takes so personally
=)
-------
<A HREF="http://www.albinoblacksheep.com/flash/you.html" target="_new">please dont click here! </A>
<A HREF="http://www.subhi.com/keyboard.jpg" target="_new">This is you, interweb junky</A>
http://www.cs.wisc.edu/~mulvihil/752_paper.pdf
Here, I found your answer. Remember, a driver must also support SMT (creative seemed to have issues early on).
I'm not so sure why you feel hyperthreading has to be 100% effective to be a valid technology.
Are you supporting the concept of 100% compatability?
delete all the non compatible applications till we can pretend that it is now 100% compatible?
You asked who I was, I told you. I'm flattered you think Im so super. Not admitting a lack of knowledge is the most difficult barrier to learning it. I was curious about your request and found a good paper on it. Glad you asked.
It is amazing how well it works with good drivers and software. Most CPU cycles are wasted by current software.
It seem true physical CPU's will pretty much displace hyperthreading and we won't really get to see mature software for the technology. Lock-ups or no, it still doesn't give the needed performance gains verses single proc systems.
Driver people, are drivers easier to write for multi CPU systems or are there simply more code that is bugged to apply to physical CPU drivers? Have virtual core CPU's been used in earlier systems verses true dual physical processor systems?
Here, I found your answer. Remember, a driver must also support SMT (creative seemed to have issues early on).
I'm not so sure why you feel hyperthreading has to be 100% effective to be a valid technology.
Are you supporting the concept of 100% compatability?
delete all the non compatible applications till we can pretend that it is now 100% compatible?
You asked who I was, I told you. I'm flattered you think Im so super. Not admitting a lack of knowledge is the most difficult barrier to learning it. I was curious about your request and found a good paper on it. Glad you asked.
It is amazing how well it works with good drivers and software. Most CPU cycles are wasted by current software.
It seem true physical CPU's will pretty much displace hyperthreading and we won't really get to see mature software for the technology. Lock-ups or no, it still doesn't give the needed performance gains verses single proc systems.
Driver people, are drivers easier to write for multi CPU systems or are there simply more code that is bugged to apply to physical CPU drivers? Have virtual core CPU's been used in earlier systems verses true dual physical processor systems?
yeah i totally agree with you, the average user doesnt do any specific computing so anyone in that group would be fine with an athlon system. in my years of building and testing systems, i have grown tired of all the benchmark wars. synthetic benchmarks are really a waste of time and are only for frivilous competitions.
as far as your creditials, there is no need for you or anyone to prove the experience they have. in the years that ive bene in the industry form getting my degree to running my own pc business, another thing i know is that even those with creditials can have the elast knowledge in the tech business, not refering to you of course. things are evolving constantly, and many get left behind or not care to keep up. the point is, just throwing around titles doesnt mean a person know more in this field.
as far as your creditials, there is no need for you or anyone to prove the experience they have. in the years that ive bene in the industry form getting my degree to running my own pc business, another thing i know is that even those with creditials can have the elast knowledge in the tech business, not refering to you of course. things are evolving constantly, and many get left behind or not care to keep up. the point is, just throwing around titles doesnt mean a person know more in this field.
i dont think hyperthreading was meant for long term adoption. i think at the time, intel needed something to keep its edge, and it came up with this. while i like the technology, its biggest strength is using multiple apps at once, which owuld be something anyone could see, and not quite as much wiht specialized tasks. also hyperthreading really works best on the current p4 platform becuase of its architecture. it wouldnt be nearly as succesful on an athlon 64 or even p-m dothan becuase of thier architecture. those two designs dont use the same long pipeline structures and therefore arent idle as much as p4 northwoods or prescotts would be if it didnt have HT. not to mention things like better branch prediciton for dothan and ahtlon 64 versus prescott,the p4 just needed something to put those idle clocks to use and keep its pipeline filled, or as close to it as possible.
i think its a nice tech, but i dont see it as having a long term future. i agree with you about dual core, physical multiprocessing is still the best way to go, software just cant reach that level today.
i think its a nice tech, but i dont see it as having a long term future. i agree with you about dual core, physical multiprocessing is still the best way to go, software just cant reach that level today.
My intitial post was an attempt to lighten the mood buddy. I saw the "bandwagon" thing taking off. I think sometimes people just don't realize that although they may be joking or even just a bit huffy in the moment the comments stay up in print. I think sometimes though the reader can take it personally and then it becomes cruel whether it was intended to be or not. Anyway, I wasn't being sarcastic or commenting one way or the other on the validity of what you said. I thought it had some interesting thoughts.
I think I did actually go get a glass of milk after I posted that comment though.
...I like milk...
I think I did actually go get a glass of milk after I posted that comment though.
...I like milk...
Tavelkyosoba
Distinguished
- Oct 14, 2003
- 188
- 0
- 18,680
i severyone who goes to purdue boreing and self vindicating like rower30?
its posting, not essaying. and we should all remember the logical falacies of argument, otherwise we start to sound like rower30
"I see" said the blind man to his deaf dog
its posting, not essaying. and we should all remember the logical falacies of argument, otherwise we start to sound like rower30
"I see" said the blind man to his deaf dog
>It seem true physical CPU's will pretty much displace
>hyperthreading and we won't really get to see mature
>software for the technology
Hyperthreading and CMP are definately not mutually exclusive. HT is just a way to make more effective use of a (long) pipeline and increasing its efficiency. Simply put: insert instruction into the pipeline where there would otherwise be bubbles. This method is presented towards the OS as a dual thread capable cpu, much like a 2 way SMP or dual core system, but that is about the only resemblence.
Having two or more cores, be it on the same chip or on different cpu's doesn't negate this (potential) advantage at all. The only thing that changes is that if you only have 2 concurrent threads, and you have 2 physical cores (SMP or CMT), HT will not be able to provide a benefit, much like there is no benefit in having a single core cpu with HT running single threaded apps.
If you doubt the viability or usefullness of HT in combination with CMT, I suggest you look take a look at the Power5. If you doubt the usefullness of HT in combination with SMP, I suggest you look at some server benchmarks of 2 or 4 way Xeons with and without HT. It still offers just as tangible benefits, as long as you have enough threads to process in parallel.
So dual core chips will in no way replace HT. HT will still be a technology that allows you to make more effective use of a single core. performance gains might not be quite as big as with dual core, but then it also takes up neglectable die estate compared to multicore.
> Lock-ups or no
HT is (almost²) no different from a dual core or 2 way SMP system from a programming POV, that even includes OS support. In the (extreme rare) cases an app or driver would misbehave on a HT enabled cpu, I bet you a fortune it would behave just as bad on a 2 way SMP or CMP system. Code that crashes on such systems typically have race conditions, or rely on loop based timers (which could just as well cause crashes on faster-than-expected CPU's, remember the K6-300 issue with Win98 ?). Blame incompetent developpers, not the technology.
(²) the only differences I'm aware off is optimization; HT enabled virtual cores share the same L1, L2 and trace cache, unlike CMP/SMP implementations. This can result in cache trashing when one virtual core monopolizes the cache, and with each context switch the content of the cache must be reloaded from ram (or a higher level cache).
Furthermore, the OS ideally must be aware a logical cpu <> physical cpu, otherwise it will always try and assign the same thread to the same cpu whenever possible, which is good with 2 physical cores as it increases cache hit ratio, but can be decremental with 2 logical CPU's where the cache is shared anyhow. This is a minor change to the scheduler, just modify the thread/cpu affinity code, something that has been done for XP, but not Win2K.
>Driver people, are drivers easier to write for multi CPU
>systems or are there simply more code that is bugged to
>apply to physical CPU drivers?
You may want to rephrase that question, but if I understood you correctly: writing code for HT is no different than writing it for SMP/CMT. If you want to maximize performance, you may need some minor additional work to reduce chances of cache trashing, but this would be no different for a dual core CPU with a shared L2 (or L3).
>Have virtual core CPU's been used in earlier systems verses
>true dual physical processor systems?
Again, its not one approach versus the other. That is like saying "AMD64 versus SSE3". But no, AFAIK, the xeon was the first implementation of a SMT ("hyperthreading") cpu. Meanwhile Power5 also has it, and there are rumours Itanium would implement it. Note Power5 is already multicore, and Itanium will be soon as well. Its not "or" its "and".
PS: in case you wondered about my credentials, I'm 13 years old, I failed miserably in primary school since I just couldn't grasp 10 times tables; my biggest personal achievement is my diploma of 25m breastroke. No one else in my family ever achieved that so late in their lives or required more than the 7.5 minutes it took me. I also think its a record in the 50 year existance of our school.
= The views stated herein are my personal views, and not necessarily the views of my wife. =
>hyperthreading and we won't really get to see mature
>software for the technology
Hyperthreading and CMP are definately not mutually exclusive. HT is just a way to make more effective use of a (long) pipeline and increasing its efficiency. Simply put: insert instruction into the pipeline where there would otherwise be bubbles. This method is presented towards the OS as a dual thread capable cpu, much like a 2 way SMP or dual core system, but that is about the only resemblence.
Having two or more cores, be it on the same chip or on different cpu's doesn't negate this (potential) advantage at all. The only thing that changes is that if you only have 2 concurrent threads, and you have 2 physical cores (SMP or CMT), HT will not be able to provide a benefit, much like there is no benefit in having a single core cpu with HT running single threaded apps.
If you doubt the viability or usefullness of HT in combination with CMT, I suggest you look take a look at the Power5. If you doubt the usefullness of HT in combination with SMP, I suggest you look at some server benchmarks of 2 or 4 way Xeons with and without HT. It still offers just as tangible benefits, as long as you have enough threads to process in parallel.
So dual core chips will in no way replace HT. HT will still be a technology that allows you to make more effective use of a single core. performance gains might not be quite as big as with dual core, but then it also takes up neglectable die estate compared to multicore.
> Lock-ups or no
HT is (almost²) no different from a dual core or 2 way SMP system from a programming POV, that even includes OS support. In the (extreme rare) cases an app or driver would misbehave on a HT enabled cpu, I bet you a fortune it would behave just as bad on a 2 way SMP or CMP system. Code that crashes on such systems typically have race conditions, or rely on loop based timers (which could just as well cause crashes on faster-than-expected CPU's, remember the K6-300 issue with Win98 ?). Blame incompetent developpers, not the technology.
(²) the only differences I'm aware off is optimization; HT enabled virtual cores share the same L1, L2 and trace cache, unlike CMP/SMP implementations. This can result in cache trashing when one virtual core monopolizes the cache, and with each context switch the content of the cache must be reloaded from ram (or a higher level cache).
Furthermore, the OS ideally must be aware a logical cpu <> physical cpu, otherwise it will always try and assign the same thread to the same cpu whenever possible, which is good with 2 physical cores as it increases cache hit ratio, but can be decremental with 2 logical CPU's where the cache is shared anyhow. This is a minor change to the scheduler, just modify the thread/cpu affinity code, something that has been done for XP, but not Win2K.
>Driver people, are drivers easier to write for multi CPU
>systems or are there simply more code that is bugged to
>apply to physical CPU drivers?
You may want to rephrase that question, but if I understood you correctly: writing code for HT is no different than writing it for SMP/CMT. If you want to maximize performance, you may need some minor additional work to reduce chances of cache trashing, but this would be no different for a dual core CPU with a shared L2 (or L3).
>Have virtual core CPU's been used in earlier systems verses
>true dual physical processor systems?
Again, its not one approach versus the other. That is like saying "AMD64 versus SSE3". But no, AFAIK, the xeon was the first implementation of a SMT ("hyperthreading") cpu. Meanwhile Power5 also has it, and there are rumours Itanium would implement it. Note Power5 is already multicore, and Itanium will be soon as well. Its not "or" its "and".
PS: in case you wondered about my credentials, I'm 13 years old, I failed miserably in primary school since I just couldn't grasp 10 times tables; my biggest personal achievement is my diploma of 25m breastroke. No one else in my family ever achieved that so late in their lives or required more than the 7.5 minutes it took me. I also think its a record in the 50 year existance of our school.
= The views stated herein are my personal views, and not necessarily the views of my wife. =
Someone asked a question, I honestly answered it. No more, no less. It was a reasonable question and I'm sorry if an accurate answer was somehow "throwing" anything around.
I disagree that there is no need to prove experience. Your posts, spelling, and thought process all "prove" your experience. Some are aggressive with degreed individuals because they themselves have not spent the time to advance their ability to discuss things in an even and fair manner.
Life doesn't discount ANY experience no mater where it comes from, that I agree with. There are educated idiots and an education is only as fresh as its use.
I disagree that there is no need to prove experience. Your posts, spelling, and thought process all "prove" your experience. Some are aggressive with degreed individuals because they themselves have not spent the time to advance their ability to discuss things in an even and fair manner.
Life doesn't discount ANY experience no mater where it comes from, that I agree with. There are educated idiots and an education is only as fresh as its use.
There you go guys and gals, trooper has a great set of points on HT and the long pipeline in Intel CPU's. This makes good factual sense for Intel to figure out how to fill this long pipe.
I do some multi app work but the work done in the background isn't really being expected anytime soon. I lazily get around to it at the desktop level.
A server, though? Everyone is waiting on a server. This is still better with real dual CPU's.
I do some multi app work but the work done in the background isn't really being expected anytime soon. I lazily get around to it at the desktop level.
A server, though? Everyone is waiting on a server. This is still better with real dual CPU's.
Be careful P4man, they might think were buddies. Wow, a good, long post that makes perfect sense. Oh, I didn't ever offer my past till I was asked about it. What's the shame in that? people deserve an truthful answer.
With HT turned on, several systems we use will lock-up if your Outlook Express is turned on. shut off the computer, reboot, and try again and it is fine. Till next time, anyway. The random nature (with wintel software no less) is consistent with HT enabled. Turned off, all is well.
What part of HT is being handled differently at each boot for this to be so consistent? It renders these PC's HT incompatible.
With HT turned on, several systems we use will lock-up if your Outlook Express is turned on. shut off the computer, reboot, and try again and it is fine. Till next time, anyway. The random nature (with wintel software no less) is consistent with HT enabled. Turned off, all is well.
What part of HT is being handled differently at each boot for this to be so consistent? It renders these PC's HT incompatible.
>Be careful P4man, they might think were buddies.
Let's set the record straight then, since I don't like pretentious fudders that talk out of their clueless rear.
>What's the shame in that?
No one asked, the comment you responded to was sarcastic, in reaction to <i>your</i> rethorical 'where did you get your eductation' question, but apparently sarcasm is lost on your award winning genius.
>With HT turned on, several systems we use will lock-up if
>your Outlook Express is turned on. shut off the computer,
>reboot, and try again and it is fine. Till next time,
>anyway. The random nature (with wintel software no less) is
>consistent with HT enabled. Turned off, all is well.
Considering intel sells roughly 15 million Pentium 4's per quarter, and over 90% of them ship with Windows (therefore, OE) installed and HT enabled, I seems rather unlikely we wouldn't have head of any related stability issues. There might be something screwed with *your* machine(s), could be flaky driver, virus, BIOS that is not up to date, overheat, bad PSU, anything really, but it is NOT a general problem. So stop spouting FUD.
>What part of HT is being handled differently at each boot
>for this to be so consistent?
"Is it true only car cylinders turn around compression when the carburator and not the injection system is tuned for low emission in the exhaust charger or battery" ?
Man, I sure hope you know more about wires and cables...
= The views stated herein are my personal views, and not necessarily the views of my wife. =
Let's set the record straight then, since I don't like pretentious fudders that talk out of their clueless rear.
>What's the shame in that?
No one asked, the comment you responded to was sarcastic, in reaction to <i>your</i> rethorical 'where did you get your eductation' question, but apparently sarcasm is lost on your award winning genius.
>With HT turned on, several systems we use will lock-up if
>your Outlook Express is turned on. shut off the computer,
>reboot, and try again and it is fine. Till next time,
>anyway. The random nature (with wintel software no less) is
>consistent with HT enabled. Turned off, all is well.
Considering intel sells roughly 15 million Pentium 4's per quarter, and over 90% of them ship with Windows (therefore, OE) installed and HT enabled, I seems rather unlikely we wouldn't have head of any related stability issues. There might be something screwed with *your* machine(s), could be flaky driver, virus, BIOS that is not up to date, overheat, bad PSU, anything really, but it is NOT a general problem. So stop spouting FUD.
>What part of HT is being handled differently at each boot
>for this to be so consistent?
"Is it true only car cylinders turn around compression when the carburator and not the injection system is tuned for low emission in the exhaust charger or battery" ?
Man, I sure hope you know more about wires and cables...
= The views stated herein are my personal views, and not necessarily the views of my wife. =
im just thinking that Ht is at the end of its life, if intel does indeed adopt the p-m architecture for desktops and gives up on netburst. if they do, and sense aperently HT doesnt work well with the p-m, im guessing becuase of the shorter pipelines, then HT will slowly fade away as netburst does.
I doubt it. Power5 has 2 way SMT, Sun's upcoming Niagra features 4 way SMT per core (and 8 cores/chip), future Itaniums are more than llikely to feature a form of SMT (corse grain), and if I'm not mistaken, Fujitsu (and therefore now Sun) is also working on SMT Sparc64's chips.
Dothan based desktop/server chips may not feature it, but its a fair guess to assume future x86 chips will include it (again), be it K9 or Meron, or both.
= The views stated herein are my personal views, and not necessarily the views of my wife. =
Dothan based desktop/server chips may not feature it, but its a fair guess to assume future x86 chips will include it (again), be it K9 or Meron, or both.
= The views stated herein are my personal views, and not necessarily the views of my wife. =
P4man,
My rear is indeed clueless (I have lots of clueless body parts!), it doesn't even know....
Ok, my rear is taken care of. In place of a real knowledge base I guess I could replace it with aggressive profanity and chest thumbing that isn't seen as, "pretentious fudders" talking about themselves, either?
I can take issue with most all of what I know since it came from those before me. So did almost ALL of your knowledge, too. So what's the issue with "knowing"? If you "know" something before me you're smarter? Even if your knowledge isn't really yours either? I'd say that's fudding (good word). So that's it...we're ALL FUDDING around.
What FUD, I have no fear of many HT PC's locking. They simply do. Sure, if you message ALL the parameters, or buy DELL PC's where all the messaging is done for you, you might have an artificially perfect HT world. PC's simply have fewer configuration issues with HT disabled since it adds to issues already there. A stone stock PC still can have issues and single proc OS'es have been around awhile. What is it about system issues that have got everyone so defensive?
You make assumptions about HT's perfection that is too intertwined to really support. I turn it on and more issues arise. Well, there seem to be more issues doesn't it? You say its FUD / bad. I say it simply is. HT can sometimes do "this" (generally no), most of the time it can do that. Add issues and they statistically multiply the matrix of possible "none compliant" configurations of two raised to that power. You also seem insistent that I'm against HT in general. No, it simply doesn't do as much as people think it should, as supported by Tom's Hardware guide tests. Is it FUD your afraid of (isn't any) or that the HT world has smears on its glass exterior you're somewhat ashamed of (shouldn't be)?
This is the exact type of response I pointed out in my, "got milk" post that started all this. We have strong tendency to make closed-minded stands that get in the way of really developing anything past the idol crowd stage pushed on use by marketing. HT is perfect...right? The tattooed Harley crowd rears it's head.
Off of that for a second, you seem very well versed in the pursuit of HT perfection (not that it is there yet) and Intel architecture. And, based on your posts, you seem at least pretty concise on these issues. You deserve credit for that and your facts seem correct. Even if they are someone else's, just like mine.
Questions ( I know nothing about this, in other words, or my rear, it talks, I asked it!);
1.0 In a dual HT enabled system, is the motherboard seeing "four" CPU's? Two real / physical and two virtual?
2.0 If a pipeline prediction is incorrect and flushed, is the data in BOTH CPU's pipeline common to that processor flushed? If so, would this not have a double negative if too many wrong predictions were made?
3.0 Would this would be a negative if you use short duration type desktop tasks verses longer consistent one where you have convinced me that HT really will benefit this user?
4.0 Dual core type HT enabled tasks are more server centric than desktop, possibly?
Sometimes we get what we ask for, only to find it's not what we need. But it sure feels great seeing two CPU's when we boot. That is until the evaluations say it comes up short of expectations. Where are those application (most are not synthetic) benchmarks that show an Intel CPU beats an AMD in desktop use with HT enabled, and loses with it turned off? If we don't use scripted "real" applications what do we use to "prove" our point? More profanity?
My rear is indeed clueless (I have lots of clueless body parts!), it doesn't even know....
Ok, my rear is taken care of. In place of a real knowledge base I guess I could replace it with aggressive profanity and chest thumbing that isn't seen as, "pretentious fudders" talking about themselves, either?
I can take issue with most all of what I know since it came from those before me. So did almost ALL of your knowledge, too. So what's the issue with "knowing"? If you "know" something before me you're smarter? Even if your knowledge isn't really yours either? I'd say that's fudding (good word). So that's it...we're ALL FUDDING around.
What FUD, I have no fear of many HT PC's locking. They simply do. Sure, if you message ALL the parameters, or buy DELL PC's where all the messaging is done for you, you might have an artificially perfect HT world. PC's simply have fewer configuration issues with HT disabled since it adds to issues already there. A stone stock PC still can have issues and single proc OS'es have been around awhile. What is it about system issues that have got everyone so defensive?
You make assumptions about HT's perfection that is too intertwined to really support. I turn it on and more issues arise. Well, there seem to be more issues doesn't it? You say its FUD / bad. I say it simply is. HT can sometimes do "this" (generally no), most of the time it can do that. Add issues and they statistically multiply the matrix of possible "none compliant" configurations of two raised to that power. You also seem insistent that I'm against HT in general. No, it simply doesn't do as much as people think it should, as supported by Tom's Hardware guide tests. Is it FUD your afraid of (isn't any) or that the HT world has smears on its glass exterior you're somewhat ashamed of (shouldn't be)?
This is the exact type of response I pointed out in my, "got milk" post that started all this. We have strong tendency to make closed-minded stands that get in the way of really developing anything past the idol crowd stage pushed on use by marketing. HT is perfect...right? The tattooed Harley crowd rears it's head.
Off of that for a second, you seem very well versed in the pursuit of HT perfection (not that it is there yet) and Intel architecture. And, based on your posts, you seem at least pretty concise on these issues. You deserve credit for that and your facts seem correct. Even if they are someone else's, just like mine.
Questions ( I know nothing about this, in other words, or my rear, it talks, I asked it!);
1.0 In a dual HT enabled system, is the motherboard seeing "four" CPU's? Two real / physical and two virtual?
2.0 If a pipeline prediction is incorrect and flushed, is the data in BOTH CPU's pipeline common to that processor flushed? If so, would this not have a double negative if too many wrong predictions were made?
3.0 Would this would be a negative if you use short duration type desktop tasks verses longer consistent one where you have convinced me that HT really will benefit this user?
4.0 Dual core type HT enabled tasks are more server centric than desktop, possibly?
Sometimes we get what we ask for, only to find it's not what we need. But it sure feels great seeing two CPU's when we boot. That is until the evaluations say it comes up short of expectations. Where are those application (most are not synthetic) benchmarks that show an Intel CPU beats an AMD in desktop use with HT enabled, and loses with it turned off? If we don't use scripted "real" applications what do we use to "prove" our point? More profanity?
i only ment as far as intel p4 chips in the desktop area. i dont think this extends to the server arena, im sure SMT will go on for some time there, im just saying it probably wont in desktops. Anew form of SMT may be developed and used in desktops, but the current HT intel uses wont be used in p-m based mobile and desktop chips, so its likely HT will drop out of favor in the desktop area, while other forms of SMT will still be useful in server areas for sure.
I dont really see why you would think K9 or Meron would impliment a form of SMT, there arent really any hints at such a thing, especially on the amd side. in fact it looks like they are more concerned with physical multi threading and letting the software developers work on adapting to it.
I dont really see why you would think K9 or Meron would impliment a form of SMT, there arent really any hints at such a thing, especially on the amd side. in fact it looks like they are more concerned with physical multi threading and letting the software developers work on adapting to it.
>I can take issue with most all of what I know since it came
>from those before me.
What a great point. The issue is not what you know or dont know, its what you proclaim to know when you don't. I'm allergic to that. You keep stating over an over hyperthreading results in instability, even when it has been pointed out to you over and over what a nonsense claim that is. If you do not know, don't spread fud, and if you think you know because you have an unstable setup, that perhaps is less unstable with HT disabled and therefore you conclude HT is definately the cause, and this phenomena has got to be universal, then that shows something about you as well.
>we're ALL FUDDING around.
Maybe you do not realize what the word FUD means.
>What FUD, I have no fear of many HT PC's locking.
By claiming there is a causal relation between HT and instability, you inflict fear (uncertainty, doubt), which is not warranted. Hence, you spread fud.
>PC's simply have fewer configuration issues with HT
>disabled since it adds to issues already there.
I've asked you before, and will ask you again: please show us half a shred of credible evidence hyperthreading results in instability, and it is therefore warranted someone owning or buying a P4 should be warry of enabling it.
>What is it about system issues that have got everyone so
>defensive?
its your false conclusions you keep posting as facts that get me offensive.
>You make assumptions about HT's perfection that is too
>intertwined to really support. I turn it on and more issues
>arise. Well, there seem to be more issues doesn't it?
Guess what; I've got an old Athlon system from a friend sitting here, with a Tbird 1400/133 FSB. When I set FSB to 133/266, it crashes every 5 minutes, sometimes it won't even boot. When I set it to 200x10.5 (1050 MHz) it works just fine. So, can I conclude there are issues with Tbird 1400 ? Using your logic, I could. People should think twice before setting it to the FSB is was designed for.. or risk instability. Makes sense no ? Unless, maybe, could it be the box has crappy cooling, inadequate powersupply or the memory doesnt support 266 DDR ? Maybe I didnt flash the bios, maybe I've got a KT133 that doesnt run at 133 Mhz ? Maybe even the chip is a 200 Mhz part and I should set a 14x multiplier ? There are plenty of reasons that cause this behaviour, and since AMD sold millions of those chips, and I've not read anywhere they do not work as advertised, common sense says something else is the problem.
>No, it simply doesn't do as much as people think it should,
>as supported by Tom's Hardware guide tests
Performance of HT has been known for a long time to varry somewhere from -5 to +15% on average. If you expected more (or less) blame your expectations. Besides, you really think this board needs your expert opinion on HT performance ? You reallly think posters here have not read two gazillion P4 reviews ?
> Is it FUD your afraid of (isn't any) or that the HT world
>has smears on its glass exterior you're somewhat ashamed of
>(shouldn't be)?
LMAO ! You have clearly not been around here for very long. I can't wait to be labeled an intel fanboy for the first time in my life; please make it happen.
> HT is perfect...right?
Not anymore than AMD64 or SSE is "perfect", its just another technology that helps performance under certain circumstances. Its cheap in die size, and has little downsides, there is nothing wrong with it.
>1.0 In a dual HT enabled system, is the motherboard seeing
>"four" CPU's? Two real / physical and two virtual?
Yes.
>2.0 If a pipeline prediction is incorrect and flushed, is
>the data in BOTH CPU's pipeline common to that processor
>flushed? If so, would this not have a double negative if
>too many wrong predictions were made?
No. Each logical processor has its own context, if the pipeline is flushed, this only affects one context. The other logical cpu is not affected.
>3.0 Would this would be a negative if you use short
>duration type desktop tasks verses longer consistent one
>where you have convinced me that HT really will benefit
>this user?
I have no idea what you're asking. What do you mean "longer task" ? I hope you do realize just opening a print dialog in word would translate in maybe tens of millions of clockcycles and the cpu might be interrupted and switch threads and contexts perhaps several thousand times between your click and the appearance of the dialog ? So please define "a long task".
>4.0 Dual core type HT enabled tasks are more server centric
>than desktop, possibly?
Tasks arent "dual core or HT enabled". Software can be multithreaded or not. Or you can run several single threaded cpu intensive apps at once. Some apps lend themselves well to multithreading, and for instance any half decent rendering program can be configured to spawn as many threads as you like. For other programs, like games, creating multithreaded code will be a lot harder. But again, there is nearly no difference between creating software that takes advantages of several physical cores or logical cores. Obviously, server software tends to be much more multithreaded friendly since it is designed to support several users simultanously, and designed to take advantage of SMP systems.
> Where are those application (most are not synthetic)
>benchmarks that show an Intel CPU beats an AMD in desktop
>use with HT enabled, and loses with it turned off?
What sort of nonsense criterium is that to judge a technology ?
> If we don't use scripted "real" applications what do we
> use to "prove" our point?
My point was never to claim hyperthreading enabled enormous speedups. My point is that it does NOT inflict instability like you claimed, unless with software that is so crappy that it will not run on SMP or CMP systems either. Creative Labs drivers are indeed a prime example or worthless coding, and are known to give problems on all sorts of configurations, which may include HT for all I know. If there is a lesson to be learned, it is to avoid Creative products at all costs, something most people here have known for ages.
Damn.. I don't think I ever wrote such a long post to defend an intel technology..
= The views stated herein are my personal views, and not necessarily the views of my wife. =
>from those before me.
What a great point. The issue is not what you know or dont know, its what you proclaim to know when you don't. I'm allergic to that. You keep stating over an over hyperthreading results in instability, even when it has been pointed out to you over and over what a nonsense claim that is. If you do not know, don't spread fud, and if you think you know because you have an unstable setup, that perhaps is less unstable with HT disabled and therefore you conclude HT is definately the cause, and this phenomena has got to be universal, then that shows something about you as well.
>we're ALL FUDDING around.
Maybe you do not realize what the word FUD means.
>What FUD, I have no fear of many HT PC's locking.
By claiming there is a causal relation between HT and instability, you inflict fear (uncertainty, doubt), which is not warranted. Hence, you spread fud.
>PC's simply have fewer configuration issues with HT
>disabled since it adds to issues already there.
I've asked you before, and will ask you again: please show us half a shred of credible evidence hyperthreading results in instability, and it is therefore warranted someone owning or buying a P4 should be warry of enabling it.
>What is it about system issues that have got everyone so
>defensive?
its your false conclusions you keep posting as facts that get me offensive.
>You make assumptions about HT's perfection that is too
>intertwined to really support. I turn it on and more issues
>arise. Well, there seem to be more issues doesn't it?
Guess what; I've got an old Athlon system from a friend sitting here, with a Tbird 1400/133 FSB. When I set FSB to 133/266, it crashes every 5 minutes, sometimes it won't even boot. When I set it to 200x10.5 (1050 MHz) it works just fine. So, can I conclude there are issues with Tbird 1400 ? Using your logic, I could. People should think twice before setting it to the FSB is was designed for.. or risk instability. Makes sense no ? Unless, maybe, could it be the box has crappy cooling, inadequate powersupply or the memory doesnt support 266 DDR ? Maybe I didnt flash the bios, maybe I've got a KT133 that doesnt run at 133 Mhz ? Maybe even the chip is a 200 Mhz part and I should set a 14x multiplier ? There are plenty of reasons that cause this behaviour, and since AMD sold millions of those chips, and I've not read anywhere they do not work as advertised, common sense says something else is the problem.
>No, it simply doesn't do as much as people think it should,
>as supported by Tom's Hardware guide tests
Performance of HT has been known for a long time to varry somewhere from -5 to +15% on average. If you expected more (or less) blame your expectations. Besides, you really think this board needs your expert opinion on HT performance ? You reallly think posters here have not read two gazillion P4 reviews ?
> Is it FUD your afraid of (isn't any) or that the HT world
>has smears on its glass exterior you're somewhat ashamed of
>(shouldn't be)?
LMAO ! You have clearly not been around here for very long. I can't wait to be labeled an intel fanboy for the first time in my life; please make it happen.
> HT is perfect...right?
Not anymore than AMD64 or SSE is "perfect", its just another technology that helps performance under certain circumstances. Its cheap in die size, and has little downsides, there is nothing wrong with it.
>1.0 In a dual HT enabled system, is the motherboard seeing
>"four" CPU's? Two real / physical and two virtual?
Yes.
>2.0 If a pipeline prediction is incorrect and flushed, is
>the data in BOTH CPU's pipeline common to that processor
>flushed? If so, would this not have a double negative if
>too many wrong predictions were made?
No. Each logical processor has its own context, if the pipeline is flushed, this only affects one context. The other logical cpu is not affected.
>3.0 Would this would be a negative if you use short
>duration type desktop tasks verses longer consistent one
>where you have convinced me that HT really will benefit
>this user?
I have no idea what you're asking. What do you mean "longer task" ? I hope you do realize just opening a print dialog in word would translate in maybe tens of millions of clockcycles and the cpu might be interrupted and switch threads and contexts perhaps several thousand times between your click and the appearance of the dialog ? So please define "a long task".
>4.0 Dual core type HT enabled tasks are more server centric
>than desktop, possibly?
Tasks arent "dual core or HT enabled". Software can be multithreaded or not. Or you can run several single threaded cpu intensive apps at once. Some apps lend themselves well to multithreading, and for instance any half decent rendering program can be configured to spawn as many threads as you like. For other programs, like games, creating multithreaded code will be a lot harder. But again, there is nearly no difference between creating software that takes advantages of several physical cores or logical cores. Obviously, server software tends to be much more multithreaded friendly since it is designed to support several users simultanously, and designed to take advantage of SMP systems.
> Where are those application (most are not synthetic)
>benchmarks that show an Intel CPU beats an AMD in desktop
>use with HT enabled, and loses with it turned off?
What sort of nonsense criterium is that to judge a technology ?
> If we don't use scripted "real" applications what do we
> use to "prove" our point?
My point was never to claim hyperthreading enabled enormous speedups. My point is that it does NOT inflict instability like you claimed, unless with software that is so crappy that it will not run on SMP or CMP systems either. Creative Labs drivers are indeed a prime example or worthless coding, and are known to give problems on all sorts of configurations, which may include HT for all I know. If there is a lesson to be learned, it is to avoid Creative products at all costs, something most people here have known for ages.
Damn.. I don't think I ever wrote such a long post to defend an intel technology..
= The views stated herein are my personal views, and not necessarily the views of my wife. =
>I dont really see why you would think K9 or Meron would
>impliment a form of SMT, there arent really any hints at
>such a thing, especially on the amd side
Simply because it makes sense. Dothan doesnt have it, since its just a respin of the Pentium Pro which clearly didn't sport it yet. K8 doesnt have it because AMD already faced enough challenges as it was (HTT, ODMC, AMD64, SOI,...) and it would probably have had an even smaller impact as on P4, but I'm fairly certain as time goes by, and also AMD keeps on making longer pipelined designs that SMT will make sense on AMD cpu's just as well. The benefit may not be enormous, but neither are the costs. Pretty much all the low hanging fruit is gone nowadays, rest assured AMD is looking into CMT as yet another trick in the book.
Besides, the Risc world is usually also a good indication of things that will be on our desktop only a few years later. AFAIK, there is no upcoming risc cpu that doesn't sport some form or SMT.
= The views stated herein are my personal views, and not necessarily the views of my wife. =
>impliment a form of SMT, there arent really any hints at
>such a thing, especially on the amd side
Simply because it makes sense. Dothan doesnt have it, since its just a respin of the Pentium Pro which clearly didn't sport it yet. K8 doesnt have it because AMD already faced enough challenges as it was (HTT, ODMC, AMD64, SOI,...) and it would probably have had an even smaller impact as on P4, but I'm fairly certain as time goes by, and also AMD keeps on making longer pipelined designs that SMT will make sense on AMD cpu's just as well. The benefit may not be enormous, but neither are the costs. Pretty much all the low hanging fruit is gone nowadays, rest assured AMD is looking into CMT as yet another trick in the book.
Besides, the Risc world is usually also a good indication of things that will be on our desktop only a few years later. AFAIK, there is no upcoming risc cpu that doesn't sport some form or SMT.
= The views stated herein are my personal views, and not necessarily the views of my wife. =
P4man,
No, you create the conspiracy. I never said, "and this phenomena has got to be universal" you did. You seem afraid that any indiscretion that does indeed occur on admittedly rare occasions will bring the house down. You try to slam you opinion that it's all perfected out there and to dismiss those few that DO have issues. They are simply posting them to solve a configuration problem that DOES have to be addressed BECAUSE of a HT enabled situation.
If a configuration has to be changed to make anything work, it is indeed a fault of that component's interaction if all else worked fine before. Yes, it may indeed be software, but not UNLESS HT is enabled is it a problem. Users just want to know why! Me, I need to know why Outlook Express crashes the system. I don't think BIOS needs to be OE5 aware, or XP isn't. What is it?
I DO know HT causes instability when turned on, its gone when HT is turned off. What more need be said. HT crashes the system with Outlook Express. How on earth can I not know that?
I will not post what I don't know. I haven't posted what I don't know. HT crashes my system. I know that. You don't know why, fine. Someone else may. There are kernel fixes all over out there "fixing" HT problems. Why?
Installing an HT enabled CPU into an HT "compliant" PC under NORMAL set-ups (no silly outside of spec overclocking) doesn't always (it is rare - I seem to keep pointing this out to you) result in a stable system.
Instead of trying to bury the problem, start considering solutions. What would you tell a client with a PC YOU built with this problem? You're nuts? Go away? Don't tell anyone? Disable it and don't bother me? You don't get what you pay for?
Lets consider SOLUTIONS and not act like it's an Intel slam dance issue to undermine the beloved empire with FUD.
Take a deep breath and repeat, HT is not a universal problem, a very few group of users need solutions to infrequent HT enabled stability problems and would like to define solutions.
Going to your very useful side, and again appreciating your knowledge....
What I mean by short / long tasks is this,
We run a program that calculates SPC numbers over several product attributes and hundreds of data points over several frequency ranges. You load the parameters click "start calculations" and it crunches for about and HOUR. It is in the background with other tasks running up front. This is a LONG task with (I can't say it because I would plagiarize Carl Sagen) CPU cycles. Not a simple work document. Encoding audio seems to be a LONG time task running in many minutes to an hour. 10-15% can make a difference here, no?
I still don't understand (getting closer) how a single HT enabled CPU can empty out a bad pipeline prediction if the data from multiple tasks is "threaded" into the pipeline and multiplexed at the output into two serial and independent program outputs. It seems all the data in the pipeline would have to be trashed and start over with BOTH processes. It seems like two cars going down the same road when the prediction says, whoops, we guessed the wrong lead car. Well, both cars have to back out so the lead car can be replaced with the right car and the second car again goes down the road again behind the "correctly" predicted lead car. Or, is the lead car simply discarded somehow at the output and the second car accepted while a replacement is then "sent" for the wrong initial lead car?
No, you create the conspiracy. I never said, "and this phenomena has got to be universal" you did. You seem afraid that any indiscretion that does indeed occur on admittedly rare occasions will bring the house down. You try to slam you opinion that it's all perfected out there and to dismiss those few that DO have issues. They are simply posting them to solve a configuration problem that DOES have to be addressed BECAUSE of a HT enabled situation.
If a configuration has to be changed to make anything work, it is indeed a fault of that component's interaction if all else worked fine before. Yes, it may indeed be software, but not UNLESS HT is enabled is it a problem. Users just want to know why! Me, I need to know why Outlook Express crashes the system. I don't think BIOS needs to be OE5 aware, or XP isn't. What is it?
I DO know HT causes instability when turned on, its gone when HT is turned off. What more need be said. HT crashes the system with Outlook Express. How on earth can I not know that?
I will not post what I don't know. I haven't posted what I don't know. HT crashes my system. I know that. You don't know why, fine. Someone else may. There are kernel fixes all over out there "fixing" HT problems. Why?
Installing an HT enabled CPU into an HT "compliant" PC under NORMAL set-ups (no silly outside of spec overclocking) doesn't always (it is rare - I seem to keep pointing this out to you) result in a stable system.
Instead of trying to bury the problem, start considering solutions. What would you tell a client with a PC YOU built with this problem? You're nuts? Go away? Don't tell anyone? Disable it and don't bother me? You don't get what you pay for?
Lets consider SOLUTIONS and not act like it's an Intel slam dance issue to undermine the beloved empire with FUD.
Take a deep breath and repeat, HT is not a universal problem, a very few group of users need solutions to infrequent HT enabled stability problems and would like to define solutions.
Going to your very useful side, and again appreciating your knowledge....
What I mean by short / long tasks is this,
We run a program that calculates SPC numbers over several product attributes and hundreds of data points over several frequency ranges. You load the parameters click "start calculations" and it crunches for about and HOUR. It is in the background with other tasks running up front. This is a LONG task with (I can't say it because I would plagiarize Carl Sagen) CPU cycles. Not a simple work document. Encoding audio seems to be a LONG time task running in many minutes to an hour. 10-15% can make a difference here, no?
I still don't understand (getting closer) how a single HT enabled CPU can empty out a bad pipeline prediction if the data from multiple tasks is "threaded" into the pipeline and multiplexed at the output into two serial and independent program outputs. It seems all the data in the pipeline would have to be trashed and start over with BOTH processes. It seems like two cars going down the same road when the prediction says, whoops, we guessed the wrong lead car. Well, both cars have to back out so the lead car can be replaced with the right car and the second car again goes down the road again behind the "correctly" predicted lead car. Or, is the lead car simply discarded somehow at the output and the second car accepted while a replacement is then "sent" for the wrong initial lead car?
well wether that makes sense or not i up for debate. for one, its obvious amd didnt need HT , it still have the power to outperform a p4 in alot of areas, likewise for dothan in some situations.
i just think right now, neither of us can say that it will go etiher way, but i will say this, i have big doubts amd will look to implimenting HT anytime soon, since the id bet amd is looking into other architectures that dont focus on extending the pipeline, and there fore wont take advantage of HT. plus the other thing is that there would need to be a large compelling software need for HT that would push amd to do that. they are heading for dual core, that is thier answer to HT. sure they could add HT on top of that, but there is really no need to at this point.
i dont think that your theory doesnt make sense, its just that based on trends now, id say its improbable that will happen as soon as you would think. now if for some reason intel pushes Ht on dothan, or changes its mind aobut brining dothan to desktops, then things would be different, but right now that doesnt seem to be the case at all.
i just think right now, neither of us can say that it will go etiher way, but i will say this, i have big doubts amd will look to implimenting HT anytime soon, since the id bet amd is looking into other architectures that dont focus on extending the pipeline, and there fore wont take advantage of HT. plus the other thing is that there would need to be a large compelling software need for HT that would push amd to do that. they are heading for dual core, that is thier answer to HT. sure they could add HT on top of that, but there is really no need to at this point.
i dont think that your theory doesnt make sense, its just that based on trends now, id say its improbable that will happen as soon as you would think. now if for some reason intel pushes Ht on dothan, or changes its mind aobut brining dothan to desktops, then things would be different, but right now that doesnt seem to be the case at all.
>f a configuration has to be changed to make anything work,
>it is indeed a fault of that component's interaction if all
>else worked fine before.
And you are supposed to be a scientist ? Apparently my thunderbird example was too difficult for you to understand, so lets try a simpler example to show your logical phallacy: my systems works fine, great, no problems, but when I run Prime95 it crashes. when I don't run prime95, it doesnt crash. Surely, prime95 has got to be the reason, no ? It doesn't matter that prime runs fine to tens of millions of computers, I don't need to know that. Not running prime=ok, running prime=crash, that's all I need to know. People, don't run prime cause it can crash your computer. Never mind the fact my cpu is overclocked by 50% and only exihibits this instability under extremely heavy load. Never mind the fact that other, similary taxing software would likely crash my computer just as well, never mind thinking or using logic.
>I DO know HT causes instability when turned on, its gone
>when HT is turned off. What more need be said. HT crashes
>the system with Outlook Express. How on earth can I not
>know that?
Because you attribute the cause to merely a symptom. You blame HT as if you'd have tried eliminating all other possible factors, yet you haven't even tried. Does the problem still ocur with the latest bios ? does it occur with a different PSU ? Does the problem still exist when you removed all virusses and spyware from your machine ? Does you your computer still crash when you disable certain periphirals or drivers ? Do those periphirals and drivers work on a 2 way SMP machine ?
Here is an educated guess: remove the soundblaster and drivers from your machines, and watch how it magically cures all problems. Now, would you say the problem is HT and not the SB drivers ? Even when any other soundcard will work just fine, with or without HT and the SB with the same drivers will cause the same lockups on otherwise completely stable 2 way workstations, servers, etc ?
> will not post what I don't know. I haven't posted what I
>don't know. HT crashes my system. I know that
No you <b>don't know</b> that. You wrongly <b>assume</b> that. enabling HT reveals a problem, but you have no way of knowing it is the cause. I tell you it is NOT the cause, and I challenge you again to provide any credible source that shows it is or could be. I can give you two million links of problems with soundblaster drivers, crappy psu's, spyware, badcap motherboards, BIOS issues, etc. Its fair to say it is known these things can cause problems, I have not ever read HT can, nor have I read dual cpu systems are known to be unstable.
>Instead of trying to bury the problem, start considering
>solutions.
Actually, you're the one that should have asked "what could cause this" instead of simply stating "HT can cause instability" as if it where a known fact. You're the one making the wrong assumptions on which I called you. I gave you plenty of possibilities allready.
>What would you tell a client with a PC YOU built with this
>problem?
Probably something like: "I didn't ship you that system with that soundblaster POS, why did you replace the soundcard ?" or "Why the hell did you flash your BIOS to a three year old one ?".
> You load the parameters click "start calculations" and it
>crunches for about and HOUR. <snip> 10-15% can make a
>difference here, no?
So what is your question or point ? Yes, 10% of an hour is 6 minutes.. ?
>I still don't understand (getting closer) how a single HT
>enabled CPU can empty out a bad pipeline prediction if the
>data from multiple tasks is "threaded" into the pipeline
>and multiplexed at the output into two serial and
>independent program outputs. It seems all the data in the
>pipeline would have to be trashed and start over with BOTH
>processes.
Why ? at any given stage in the pipeline, there are only instruction from one thread. why would you flush those when another thread hits a branch misprediction ? Using your (flawed) analogy the cars on just on different roads, and one doesn't follow the other one at all.
= The views stated herein are my personal views, and not necessarily the views of my wife. =
>it is indeed a fault of that component's interaction if all
>else worked fine before.
And you are supposed to be a scientist ? Apparently my thunderbird example was too difficult for you to understand, so lets try a simpler example to show your logical phallacy: my systems works fine, great, no problems, but when I run Prime95 it crashes. when I don't run prime95, it doesnt crash. Surely, prime95 has got to be the reason, no ? It doesn't matter that prime runs fine to tens of millions of computers, I don't need to know that. Not running prime=ok, running prime=crash, that's all I need to know. People, don't run prime cause it can crash your computer. Never mind the fact my cpu is overclocked by 50% and only exihibits this instability under extremely heavy load. Never mind the fact that other, similary taxing software would likely crash my computer just as well, never mind thinking or using logic.
>I DO know HT causes instability when turned on, its gone
>when HT is turned off. What more need be said. HT crashes
>the system with Outlook Express. How on earth can I not
>know that?
Because you attribute the cause to merely a symptom. You blame HT as if you'd have tried eliminating all other possible factors, yet you haven't even tried. Does the problem still ocur with the latest bios ? does it occur with a different PSU ? Does the problem still exist when you removed all virusses and spyware from your machine ? Does you your computer still crash when you disable certain periphirals or drivers ? Do those periphirals and drivers work on a 2 way SMP machine ?
Here is an educated guess: remove the soundblaster and drivers from your machines, and watch how it magically cures all problems. Now, would you say the problem is HT and not the SB drivers ? Even when any other soundcard will work just fine, with or without HT and the SB with the same drivers will cause the same lockups on otherwise completely stable 2 way workstations, servers, etc ?
> will not post what I don't know. I haven't posted what I
>don't know. HT crashes my system. I know that
No you <b>don't know</b> that. You wrongly <b>assume</b> that. enabling HT reveals a problem, but you have no way of knowing it is the cause. I tell you it is NOT the cause, and I challenge you again to provide any credible source that shows it is or could be. I can give you two million links of problems with soundblaster drivers, crappy psu's, spyware, badcap motherboards, BIOS issues, etc. Its fair to say it is known these things can cause problems, I have not ever read HT can, nor have I read dual cpu systems are known to be unstable.
>Instead of trying to bury the problem, start considering
>solutions.
Actually, you're the one that should have asked "what could cause this" instead of simply stating "HT can cause instability" as if it where a known fact. You're the one making the wrong assumptions on which I called you. I gave you plenty of possibilities allready.
>What would you tell a client with a PC YOU built with this
>problem?
Probably something like: "I didn't ship you that system with that soundblaster POS, why did you replace the soundcard ?" or "Why the hell did you flash your BIOS to a three year old one ?".
> You load the parameters click "start calculations" and it
>crunches for about and HOUR. <snip> 10-15% can make a
>difference here, no?
So what is your question or point ? Yes, 10% of an hour is 6 minutes.. ?
>I still don't understand (getting closer) how a single HT
>enabled CPU can empty out a bad pipeline prediction if the
>data from multiple tasks is "threaded" into the pipeline
>and multiplexed at the output into two serial and
>independent program outputs. It seems all the data in the
>pipeline would have to be trashed and start over with BOTH
>processes.
Why ? at any given stage in the pipeline, there are only instruction from one thread. why would you flush those when another thread hits a branch misprediction ? Using your (flawed) analogy the cars on just on different roads, and one doesn't follow the other one at all.
= The views stated herein are my personal views, and not necessarily the views of my wife. =
TRENDING THREADS
-
-
News Intel terminates x86S initiative — unilateral quest to de-bloat x86 instruction set comes to an end- Started by Admin
- Replies: 28
-
-
Discussion What's your favourite video game you've been playing?- Started by amdfangirl
- Replies: 4K
-
-
Latest posts
-
-
-
-
-
Question Issues with Windows 11 loading when I try to upgrade the RAM to 64GB ?- Latest: Unolocogringo
Facebook
Twitter
Instagram