Sign in with
Sign up | Sign in
Your question

Reverse HyperThreading? AMD's Next Marvel? Read On...

Last response: in CPUs
Share
April 14, 2006 1:22:09 AM

http://tweakers.net/nieuws/42019/AMD-werkt-aan-omgekeer...

Basically, AMD is working on a technique to allow multiple CPU's or Cores to work on a Single thread, the reverse of HyperThreading. This is to be implemented in the K10's. This would definately remove the need to make Multi-Threaded software and reduce the inefficiency of Multi-Threading.

~~Mad Mod Mike, pimpin' the world 1 rig at a time
April 14, 2006 1:43:43 AM

Quote:
I just read that AMD is scrapping plans for K10....

AMD will have a lot of work on its hands and it remains to be seen what the company has in store to follow the K8L marchitecture, since the company ditched both K9 and K10 architectures and isn't disclosing development of new architectures.


Source: http://www.theinquirer.net/?article=30970

Or course, it is only the inquirer :) 

Yea, and they also seem to think that Conroe is getting HyperTransport 3.0...

Regardless where this is being implemented, they're making it.

~~Mad Mod Mike, pimpin' the world 1 rig at a time
April 14, 2006 1:45:32 AM

Quote:
its in german,mike :cry:  nine sprechen ze! so how does this idea translate to performance?what kind of alterations are needed to use one thread for multiple cores?


Imagine a Quad-Core CPU working on a Single thread, the immense performance gains will be greater than a Quad-Core working on 4 threads, the big gains will be in Gaming with heavy calculations, also letting 4 CPU's work on 2 Threads is a possibility.

~~Mad Mod Mike, pimpin' the world 1 rig at a time
Related resources
April 14, 2006 1:45:57 AM

thats freakin sweet



:D 
April 14, 2006 1:50:25 AM

Quote:
what is a thread on a cpu?is that the pipeline?


Basically a "Thread" is part of the program broken up so that it can be done is sections, and 1 CPU w/o HyperThreading can work on 1 thread, so allowing 2 or more CPU's to work on 1 thread, means dramatic increases in performance, like Parallel Computing.

~~Mad Mod Mike, pimpin' the world 1 rig at a time
April 14, 2006 1:55:43 AM

That sounds like its going to be quite something. Practically going against what Intel have set out to do, but in the same way, will provide a decent performance boost. I will definitely be watching this space for more developments on this "Reverse Hyperthreading".
April 14, 2006 2:17:01 AM

Not that article, there's an article that this guy goes into a great rant of how HT is to be implemented inside Conroe or some Intel chip, it's like 10 paragraphs of him saying "This is what Intel is doing" Here

~~Mad Mod Mike, pimpin' the world 1 rig at a time
April 14, 2006 2:34:01 AM

This reverse Hyperthreading thing seems like a great idea, especially if no reprogramming is needed, allowing instant benefits from single-threaded programs on multi-core processors. They must have some interesting ways to get around the dependencies.
April 14, 2006 2:53:40 AM

Quote:
its in german,mike :cry:  nine sprechen ze! so how does this idea translate to performance?what kind of alterations are needed to use one thread for multiple cores?


Imagine a Quad-Core CPU working on a Single thread, the immense performance gains will be greater than a Quad-Core working on 4 threads, the big gains will be in Gaming with heavy calculations, also letting 4 CPU's work on 2 Threads is a possibility.

~~Mad Mod Mike, pimpin' the world 1 rig at a time

So what happens when one CPU runs into a branch stall?
April 14, 2006 4:02:18 AM

Quote:
its in german,mike :cry:  nine sprechen ze! so how does this idea translate to performance?what kind of alterations are needed to use one thread for multiple cores?


Imagine a Quad-Core CPU working on a Single thread, the immense performance gains will be greater than a Quad-Core working on 4 threads, the big gains will be in Gaming with heavy calculations, also letting 4 CPU's work on 2 Threads is a possibility.

~~Mad Mod Mike, pimpin' the world 1 rig at a time

So what happens when one CPU runs into a branch stall?
The tech will probably only work efficiently with P4ish-type programs like encoding and well whatever else the p4 is good at. Also AMD has had 3 years to work on branch prediction so maybe they'll suprise us all :) 
April 14, 2006 6:54:46 AM

Quote:
I just read that AMD is scrapping plans for K10....

I think the inquidiot just assumed that posponed ment the same as ditched. I have not seen anyone else suggest that K10 has been canceled.
April 14, 2006 7:14:40 AM

I can't believe ActionMan didn't chime in with his keyboard.....I realize not his usual target....but seemed right up his alley...
April 14, 2006 11:10:30 AM

Maybe he realized most of his posts are a waste of bandwidth
April 14, 2006 5:43:37 PM

Quote:
what is a thread on a cpu?is that the pipeline?


Basically a "Thread" is part of the program broken up so that it can be done is sections, and 1 CPU w/o HyperThreading can work on 1 thread, so allowing 2 or more CPU's to work on 1 thread, means dramatic increases in performance, like Parallel Computing.

~~Mad Mod Mike, pimpin' the world 1 rig at a time
MIKE, 1 CPU can work on many threads, but not many CPUs on 1 thread!
Prallel Computing means many threads on two or more CPUs.
Multicpu or multicore as idea exist for many years, but the only reason why it wasn't realised earlier is becouse the limitation of the perofrmance of 1 core therefore limitng the performance of one procedural thread. That means if you need a thread to be done fast you need 1 fast core, not many slow. When parallel processing performance isn't increasing linear to the number of added cores. Depends on the kind of the running code, ex: 1 CPU at 2.2GHz will finish any SuperPI calculation faster than a multicore system with million of CPUs linked with whatever link(it might be a galium arsenide optic link with aprox 1TB/s bandwith for 128bit) at 2GHz. Parallel processing today is usefull only becouse we are in the era of multimedia, and multimeda means a SSIMD on a lot of data that can be be processed independently.
April 14, 2006 6:10:12 PM

Quote:
MIKE, 1 CPU can work on many threads, but not many CPUs on 1 thread!
Prallel Computing means many threads on two or more CPUs.
Multicpu or multicore as idea exist for many years, but the only reason why it wasn't realised earlier is becouse the limitation of the perofrmance of 1 core therefore limitng the performance of one procedural thread. That means if you need a thread to be done fast you need 1 fast core, not many slow. When parallel processing performance isn't increasing linear to the number of added cores. Depends on the kind of the running code, ex: 1 CPU at 2.2GHz will finish any SuperPI calculation faster than a multicore system with million of CPUs linked with whatever link(it might be a galium arsenide optic link with aprox 1TB/s bandwith for 128bit) at 2GHz. Parallel processing today is usefull only becouse we are in the era of multimedia, and multimeda means a SSIMD on a lot of data that can be be processed independently.


what mike said was right, and what you said was basically also right, but I'm not sure why you said it.
April 14, 2006 6:20:14 PM

As a computer programmer who has done both single, and multi-threaded applications, I fail to understand how they would expect to execute in 2 or more threads a single process, and recombine it safely so it'll have the same effect as single threading, while still getting any significant benefit.

I have a feeling too many kooky things have been done in programs to make this a relatively unstable idea. (example, do xyz I/O operation, wait 10ms, continue, pray that I/O op is done, or another example: while file not exists, wait 10ms)

I personally avoid timed waits in my programs, but there have been times where you just do it, and move on.

Anyhow, I don't expect this idea to ever come to fruition. It would probably be easier to teach more programmers how to write multi-threaded applications. It's not all that difficult.

Just my two cents,

John
April 14, 2006 7:38:54 PM

Quote:
MIKE, 1 CPU can work on many threads, but not many CPUs on 1 thread!
Prallel Computing means many threads on two or more CPUs.
Multicpu or multicore as idea exist for many years, but the only reason why it wasn't realised earlier is becouse the limitation of the perofrmance of 1 core therefore limitng the performance of one procedural thread. That means if you need a thread to be done fast you need 1 fast core, not many slow. When parallel processing performance isn't increasing linear to the number of added cores. Depends on the kind of the running code, ex: 1 CPU at 2.2GHz will finish any SuperPI calculation faster than a multicore system with million of CPUs linked with whatever link(it might be a galium arsenide optic link with aprox 1TB/s bandwith for 128bit) at 2GHz. Parallel processing today is usefull only becouse we are in the era of multimedia, and multimeda means a SSIMD on a lot of data that can be be processed independently.


what mike said was right, and what you said was basically also right, but I'm not sure why you said it.

uh, gOJDO was refuting at MMM said, and here you are saying both are right? that's an oxymoron, I'm afraid. You see, MMM is saying that this RHT (Reverse Hyper-Threading) makes it faster, gOJDO is saying it's slower, and I think gOJDO is right, it makes more sense. Also, there are some doubts about the feasibility of RHT.
April 14, 2006 7:57:54 PM

Quote:
what is a thread on a cpu?is that the pipeline?


Basically a "Thread" is part of the program broken up so that it can be done is sections, and 1 CPU w/o HyperThreading can work on 1 thread, so allowing 2 or more CPU's to work on 1 thread, means dramatic increases in performance, like Parallel Computing.

~~Mad Mod Mike, pimpin' the world 1 rig at a time
MIKE, 1 CPU can work on many threads, but not many CPUs on 1 thread!
Prallel Computing means many threads on two or more CPUs.
Multicpu or multicore as idea exist for many years, but the only reason why it wasn't realised earlier is becouse the limitation of the perofrmance of 1 core therefore limitng the performance of one procedural thread. That means if you need a thread to be done fast you need 1 fast core, not many slow. When parallel processing performance isn't increasing linear to the number of added cores. Depends on the kind of the running code, ex: 1 CPU at 2.2GHz will finish any SuperPI calculation faster than a multicore system with million of CPUs linked with whatever link(it might be a galium arsenide optic link with aprox 1TB/s bandwith for 128bit) at 2GHz. Parallel processing today is usefull only becouse we are in the era of multimedia, and multimeda means a SSIMD on a lot of data that can be be processed independently.

Word.
April 14, 2006 8:16:17 PM

Quote:
As a computer programmer who has done both single, and multi-threaded applications, I fail to understand how they would expect to execute in 2 or more threads a single process, and recombine it safely so it'll have the same effect as single threading, while still getting any significant benefit.

I have a feeling too many kooky things have been done in programs to make this a relatively unstable idea. (example, do xyz I/O operation, wait 10ms, continue, pray that I/O op is done, or another example: while file not exists, wait 10ms)

I personally avoid timed waits in my programs, but there have been times where you just do it, and move on.

Anyhow, I don't expect this idea to ever come to fruition. It would probably be easier to teach more programmers how to write multi-threaded applications. It's not all that difficult.

Just my two cents,

John


As a programmer myself, I think you've hit the nail on the head.
I can see a 'background process' doing the work to determine how a single thread can be cut up into smaller bits and pieces to be executed in parallel, like loads and reads, but I think the overhead of that 'background process' would be high.

Shrug, I'll look into it when someone starts posting benchmarks on it. Until then, its not worth my time.
April 14, 2006 8:34:39 PM

sorry duplicate post
April 14, 2006 8:35:19 PM

Yeah, you and Mike are both right for the most part. Seeing this worries me a bit however. Being that programmers have had things easy until this current dual core era, and have not had to program efficiently, I almost don't want to see this as it would give them a reason to go back to their old (bloatful) ways. Having two cores working on one thread would be awesome, but having two cores work on one efficiently coded thread would be even better. Got to force their "bandaiding" to stop!
April 14, 2006 8:43:35 PM

Is it just me or does your logic dictate that slower, less efficient CPUs with older technology would be better for programming standards? Or am I totally missing the point here? I mean, efficient coding is good and all, but still...
April 14, 2006 9:05:51 PM

And how would Core 0 know what thread Core 1 is working on?
Sounds like it would need a "Master"-CPU to coordinate the cores.

However, development of multi-threaded software has already started even for home-users (for professionals and open-source its nothing new) so AMD is too late.

Oh, and erm... where does the shadow come from and what shadow?
April 14, 2006 9:05:59 PM

I think you are missing the point. My point is about efficiency. Because of how poorly software has been written for so many years, especially "Windows," software has started holding us back more than hardware. Running at 100% efficiency is almost never possible, but it makes more sense to be running a 2.0ghz CPU at 90%, than running a 3.2ghz at 40%. Because of how things are bandaided right now, due to developers depending on better hardware, half the software has to go there ridiculous translations which are much like translating from french to german, to spanish, to japanese, and then to english, after which there is still lots of code that does not serve a purpose. Strange bugs are going to occur in software, but properly written software will have very few, and will not need security patches every two weeks.
April 14, 2006 9:27:02 PM

AMD is not too late. There is a big difference between doing this sort of thing on the hardware level versus the software level. See CPU utilization of RAID systems.
April 14, 2006 9:27:14 PM

wouldn't the task manager already be doing this? run almost any task set on both affinities (even if their single threads) and the program takes up both "processors" (talking about my computer here with HT)

would this be a similiar thing?

Ara
April 14, 2006 9:28:54 PM

again, task manager = OS, = software, = less efficient than dedicated hardware.
April 14, 2006 9:30:15 PM

The article summarizes, with a link to, a particular x86-secret.com article. The link is: http://www.x86-secret.com/?option=newsd&nid=933

I ran a babelfish [babelfish.altavista.com] translation of that article, which appears at the end of this post.

The article appears to have resulted from the commiserations of the writer and an unnamed AMD engineer, regarding the performance of Conroe, while attempting to drown their views of AMD's misfortunes "in the same [alcoholic] beverage."

The article indicates that AMD understands that will not be able to compete with Intel's "next" offering with the K8, and so is pinning all its hopes on its post-K8 design(s). The writer indicates that only innovation will save AMD from the impending crisis. In that context, the writer describes a reverse hyper-threading technology on which AMD is pinning its hopes "for the moment."

The writer, though not the AMD engineer, labels this technology as "revolutionary." [Perhaps that is why he is a writer and not an engineer.]

From then on, it becomes difficult to distinguish between the writer's fantasies about performance and what the engineer actually said, over his alcoholic beverage. At least, however, the writer states correctly that: "K10 will be the Holy Grail... or will not be."

If anyone truly believes that this will eliminate the need for multithreaded software, I have an excellent bridge in Brooklyn available for sale to you at a very reasonable price.


Here is the babelfish translation of the linked article:
____________________________________________________________________________________________________
AMD studies the anti-HT for its K10
09-04-2006 23:24:12 - Samuel D.

The topicality has been dull for a few days. It is a fact. Afflicted to be able to propose interesting news to you, we were constrained to drown our distress in alcohol. It is thus with the bar that we met an engineer of AMD which tried, him also, to drown its misfortune in the same beverage. This one thus described us its fears as for the performances of Conroe, of which Juda with finally sent a specimen at AMD.

Conscious that K8 architecture could not compete with the next high-speed motorboat of INTEL, all its hopes are for the moment based on a new "revolutionary" technology (it is our opinion, not it his) on which AMD works in this moment for after-K8. This technology is in fact a kind of anti-HT: There or HyperThreading sought to emulate two virtual processors with a physical processor, it is a question for AMD of emulating a single virtual processor with two (or several) physical processors.

A mother chart comprising two Dual CPU Core would be thus seen by the operating system only like one processor, well on theoretical power four times higher than that of four CPUs. More need then for the developers to pass the hours in the optimization of the software, this one will be directly dispatché between different the cores. Threading hardware, truth. Alas, frightened by the threats of AMD on his life in the event of disclosure, our engineer did not want to say some to us more.

At all events, we have the certainty now that AMD also works on the threading hardware for its next generation. Also, because INTEL is also on the rails and presented at many recoveries its vision of the threading Hardware. The years to come thus will be complex for the two founders.

At AMD, the only solution to leave themselves the crisis which goes, with blow on, to cause the exit of Conroe is to innovate, and seriously. AMD will not be able indeed to draw on K8 architecture as it did for K7 architecture (FSB400 and others strictly did not bring anything). K10 will be the Holy Grail... or will not be. And for this one, not of Nexgen or other Alpha in help.

At INTEL, medium term is not pinker forcing. Conroe and consorts, certainly, will cause the euphoria at their exit, but it should not however not be forgotten that this architecture is far from being new and will not remain viable very a long time. After Conroe and Penryn (variation 45 Nm), it is Nehalem which will have to take the changing. A many times pushed back architecture over which INTEL hesitates obviously still.

At all events, the first manufacturer who will finalize a viable technology of threading hardware will have a very broad advantage vis-a-vis with his competitor, for little that this one always exists...
April 14, 2006 9:30:32 PM

Quote:
thats freakin sweet



:D 


yes
April 14, 2006 9:35:27 PM

Apologies. I got your point, but as something of a programming idiot, I had no idea the problem you described was that bad.

This forum never fails to make me feel stupid. I'm starting to remember the moment I lost my bet with my friend, the moment when I found out that CPU was, in fact, not someone who kicks ass at Street Fighter, but a chip. I got my ass whipped n times by a friggin CHIP!! Sad :cry: 
April 14, 2006 9:40:51 PM

So, if AMD simulates 1 virtual processor using 2 real processors, then the software would also have to fuse 2 "real" threads into 1 "virtual" so that 1 processor can work on 1 thread.
So, half the threads can be processed at double speed... in the end the result is a performance of 1 -.-

Err... sorry... dont we already have something better right now? (does Dual-Core/HT ring a bell?)
I also think that "technology" would decrease multi-tasking abilities.
April 14, 2006 9:41:42 PM

Ok, here I go again. First off, it is not at all surprising that the three year old K8 design is being beat by a yet-to-be-released design, regardless of by whom. Yes, innovation is going to be key to getting the performance crown, regardless of who you are (AMD/Intel/Samsung?/Sun?). Correct me if I am wrong, but I don't think there is anything HUGE AMD needs to do, they are not in THAT big of trouble. People are really taking too much from this conroe thing. Yes, it is better in some ways, but a new design should be, and that is why technologies tend to leap-frog each other. AMD was first to 64bit, they seem to have that down well, Conroe has limited 128bit capabilities in the fact that it can process a SSE instruction in one clock. Finding a way to implement that into K8 would not be revolutionary, it would be evolutionary, just as going from the 32bit K7 to the 64bit K8 was in the first place. Combine that with other bells and whistles (like ZRAM cache & SSOI) and AMD is doing just fine. You don't really think Intel can put AMD out of business in one CPU generation, do you? They got a lot more going for them than Cyrix did. They also are not telling us what is up their sleeve. Personally, I think that PC's are MORE than capable TODAY of what NORMAL people use them for. This INCLUDES gaming. But, just like we will always want more horsepower, we will always want more processing power, too. So, on to the 3D OS we really don't need.....
April 14, 2006 9:45:39 PM

No, no, that's not it, either. We are talking about hardware level. The OS would not even have to know the thread was being split if done properly. Yes, this does create overhead, just like SLI. Yes, it would never by 2X as fast to do things with 2 cpu's than with one, but just as SLI brings a performance boost in SOME cases, so would this.
April 14, 2006 9:51:56 PM

Quote:
No, no, that's not it, either. We are talking about hardware level. The OS would not even have to know the thread was being split if done properly. Yes, this does create overhead, just like SLI. Yes, it would never by 2X as fast to do things with 2 cpu's than with one, but just as SLI brings a performance boost in SOME cases, so would this.


Well show me software that doesn’t have dependencies and perhaps the idea will be more feasible. Otherwise this is a far fetched dream at manipulating software.

As well if the code isnt specifically taged for multi processor execution, you will see no performance increase.

And for the fellow that said multi threaded code is easy... no real programmer would ever agree with you.
April 14, 2006 9:54:30 PM

it is not that multithreaded software is harder to write, it isn't. In fact it is not about difficulty in coding at all. It is just that most older applications were made for single threaded machines and working on problems that are inherently single threaded. While some single threaded operations translate very well into multithreaded, like video/picture processing, many single threaded apps are that way by nature.

Take games for an instance in a VERY simplified view:

Everything in a modern 3-d game is dependent on the movement of the player. All triggers, AI reactions, 3-d displays and such are basically linear and based on a player doing action X. Once X happens, then npc Z moves to attack and sound Y goes off with graphics N being displayed. Now b/c all are dependent on each other you cannot run them in parallel. Even if they were all on a seperate thread they would happen in sequence and thus negating any parallel benefits.

With the advent of physics, (actual) AI and other things, at certain times the actions can "branch" off and do parallel processes but never through the entire process. Therein lies the difficulty: figuring where you can go parallel.

Basically the majority of apps like games are difficult to "make" multithreaded b/c they are like a timeline: tomorrow cannot happen until today is done, no matter how much you try. You can move tomorrow to another thread/core, but it still has to wait on today (on the first thread/core). Dont even think about two days from now! ;) 

Not sure if that was what you were getting at, but I hope that clears it up from a programmer's perspective.

The concept of multithreads working on a single one seems counterintuitive at first... but potentially you could be running the cores more akin to a serial setup, which would have each core operate more like an assembly line. This of course is no different than a single core, but w/ each of the multicores operating like a piece of a much larger processor... hmm...
April 14, 2006 10:03:02 PM

You have a point here, this type of setup would be something that would be easier to implement with certain tasks and OS's. For instance, I can pretty much promise you it would be easier to implement this into a Linux OS than a windows one. If you take my advice, and look into different raid setups, you'll find that there are some very nice setups for raid 5 that the OS doesn't even realize are not one disk. Sun's ultrasparc T1 CPU will not run windows and uses a extreme core setup that causes it to need driver/software support, this would be much the same. However, if a few drivers are needed to get a 30% increase in performance, I don't believe any of you would blink before you downloaded them. See Anandtech's T1 article, it is another way that CPU designs could go that would help in multitasking, and in a way is more the opposite of this idea than Intel's Hyperthreading is.
April 14, 2006 10:04:32 PM

Quote:
The concept of multithreads working on a single one seems counterintuitive at first... but potentially you could be running the cores more akin to a serial setup, which would have each core operate more like an assembly line. This of course is no different than a single core, but w/ each of the multicores operating like a piece of a much larger processor... hmm...


This is getting to be like that computer they had in NewScientist a while ago that was 'so much faster because it never completed it's program'. Confusing stuff.

I think this falls in the category of 'Why didn't I think of that?' as far as CPUs goes. It's a great idea.

It does seem like it would only be useful in certain situations, though. Most multi-CPU computers are servers, and isn't the point of multi CPU on a server so that it's not just one CPU getting loaded down with all the work and it gets divided up. So I'm not sure what the practical application is in that situation. Any environments in which this would be uber useful?
April 14, 2006 10:05:28 PM

ya, i agree w/ you... and dont take my above post to mean that it is "easy"... just that it is not coding it that is hard... it's figuring out where to split the threads that is.

I guess I am saying that the physical code itself is not much longer/different than a single threaded code fragment... it's the logic of the beast that is the tought part. :?

I also agree that what Mike is talking about would need special instructions (ie: SSE for p4) to make any use of it... but from a sheer implementation standpoint you would have the worst of both worlds: the lack of parallel benefits from single threading w/ the logic issues i mentioned above from multithreaded apps... wow.
April 14, 2006 10:08:59 PM

Quote:
So I'm not sure what the practical application is in that situation. Any environments in which this would be uber useful?


That's just it... I'm not sure where you would see any tangible benefits from something like this. I am by no means an all-knowing expert programmer, especially when you get into theory like this, but I just do not see much comming from it unless teh specific instructions that would possibly have to be used pull something out of a hat... I just dunno. 8O
April 14, 2006 10:18:22 PM

Quote:
ya, i agree w/ you... and dont take my above post to mean that it is "easy"... just that it is not coding it that is hard... it's figuring out where to split the threads that is.

I guess I am saying that the physical code itself is not much longer/different than a single threaded code fragment... it's the logic of the beast that is the tought part. :?

I also agree that what Mike is talking about would need special instructions (ie: SSE for p4) to make any use of it... but from a sheer implementation standpoint you would have the worst of both worlds: the lack of parallel benefits from single threading w/ the logic issues i mentioned above from multithreaded apps... wow.


Problem is with SSE/SSE2/MMX code is they are vetorized/streamed/stacked/ and otherwise packed data packages with 1 operation per set.

They work with data sets not a fancy way of vectorizeing instructions, and from what I have seen with my personal experience and known information (what’s available on the net), its simply not feasible on x86 machines, which are very much OOO.

I simply can’t see it working in that manner ILP is more EPIC or Cell like machine execution.
April 14, 2006 10:25:47 PM

true enough... I was just using sse as an example of having a specific coding set to be able to use the given operation, or in this case "reverse-multi-threading". But you are correct in what you said, I just used a bad example... the cell is much better. ;) 
April 14, 2006 10:27:08 PM

Quote:
true enough... I was just using sse as an example of having a specific coding set to be able to use the given operation, or in this case "reverse-multi-threading". But you are correct in what you said, I just used a bad example... the cell is much better. ;) 


Word.
April 14, 2006 10:34:33 PM

Quote:
And for the fellow that said multi threaded code is easy... no real programmer would ever agree with you.


I program for a living, and have written several multi-threaded applications. I once wrote one that had a real use in a matter of 4 hrs. It's a matter of just using threads when it's appropriate.

Spawning a thread to check the computer's time clock is not appropriate.

Spawning a thread for network I/O (DNS lookup, downloading a file, etc) is appropriate, and will reap REAL benefit.

A simple example of how games could benefit would be for computer AI to run in a separate thread from your own user interface.

Of course threading requires synchronization, but it's not really that hard. You just wrap calls to shared resources with a lock request, which blocks until you have access. Many times these calls are nearly as simple as wrapping your code in a begin .... code .... end. Another alternative would be to use a queueing system similar to how Windows messages work. The idea here is that the thread checking the queue is the sole thread to access that resource. Also, many new languages have several if not dozens of classes which are naturally thread-safe by design.

Perhaps real programmers should go back to their books if they think the complexity of multi-threading is a major obstacle to software development.

Just my two cents,

John
April 14, 2006 10:43:41 PM

what i said still holds i believe:

physically writing or coding a multithreaded app is not hard, and you made a fine example of that. finding the spot in the logic to split the thread is. I am refering to complex, inherently single threaded apps like games here.

Even putting the AI on a seperate thread will not always see benefits. Especially when the AI is dependent on other serial processes. It is not an impossibility to see benefits, but just putting something like AI on another thread and expecting it to work is not good design. Sometimes it could work, sometimes (most of the times) it may not unless you intelligently plan it out, hence the difficulty. Even w/ good design, some things are not multithread capable, like my timeline example above. Simple parallel computing theory concepts.

and yes, I am a programmer... B.S. in Computer Science.

(sometimes heavy on the BS lol :wink: )
April 14, 2006 10:47:59 PM

Quote:
And for the fellow that said multi threaded code is easy... no real programmer would ever agree with you.


I program for a living, and have written several multi-threaded applications. I once wrote one that had a real use in a matter of 4 hrs. It's a matter of just using threads when it's appropriate.

Spawning a thread to check the computer's time clock is not appropriate.

Spawning a thread for network I/O (DNS lookup, downloading a file, etc) is appropriate, and will reap REAL benefit.

A simple example of how games could benefit would be for computer AI to run in a separate thread from your own user interface.

Of course threading requires synchronization, but it's not really that hard. You just wrap calls to shared resources with a lock request, which blocks until you have access. Many times these calls are nearly as simple as wrapping your code in a begin .... code .... end. Another alternative would be to use a queueing system similar to how Windows messages work. The idea here is that the thread checking the queue is the sole thread to access that resource. Also, many new languages have several if not dozens of classes which are naturally thread-safe by design.

Perhaps real programmers should go back to their books if they think the complexity of multi-threading is a major obstacle to software development.

Just my two cents,

John

With all due respect for you and your skill I will rely on comments from John Carmack and Tim Sweeney even Gabe Newel complain about the code complexity and debug time and increased code size alone adding nearly 3x to engine development time. Take a 340,000 line engine and re-spinning it correctly to run in 2 threads is no where a easy task.

As well being selective with your code isn’t something easily done now as many engines including Windows aim to integrate engine modules into one which adds more dependencies, more debug time, more compiling time, then more debug time.

I'm not saying your wrong but when you are talking about 100,000 plus lines of code it isn’t something that can be done in 4 hours.
April 14, 2006 10:53:16 PM

You run the timeline on it's own thread, and have the user's thread, and the AI thread submit updates to it.

Games are only single threaded because programmers historically found it easier to organize their code, than to separate it any other way, considering a lot of it was done using C, or C++.

When people stop treating their programming as one large 300k line function, and more like 30,000 functions with a testable input, and output, you'll see this task become easier. If you can't understand all of it at once, break it down into a smaller useful, and testable unit.

Just my two cents,

John
April 15, 2006 2:30:01 AM

At first this idea sounds wicked cool... then I stop and think for a minute and I remember how well hyperthreading went over and make no mistake while its a different implementation from a logistic stand its exactly the same.... with the P4 Intel wanted to use hardware that was not being used by 2 threads or more now with AMD's idea they want to throw two sets of hardware at one thread or more.... I think the performance will be something like SLI video cards better then one but not 100% better and with code its even harder to do then with video :(  (I soooo wish this wasnt so) My example would be like an assembly line (often used) where they guy who installs a part takes his lunch break and some one says "hey why dont I do that for him" he comes back from break and says WTF I already did half of this..... This of course is completely comming out my butt and AMD might make me feel stupid (its happened before :p  ) but I think they should leave the software end of things to the programmers :) 
April 15, 2006 2:46:32 AM

Quote:

Take a 340,000 line engine and re-spinning it correctly to run in 2 threads is no where a easy task.


The time to implement a multi-threading architecture is not after 340,000 lines have been written. The difficulty here is not implementing multi-threading but a deficiency in design.
April 15, 2006 3:05:10 AM

Exactly, another good point. The problem with lots of current software, is that it uses code that was written before, sometimes many years before, to save the coders time, copy and past this subroutine, then that one, etc., etc., until things are at the point that to get to the 5th floor from the 8th floor you have to remove the 6th & 7th floors, and if you want to go back you have to jump through more hoops, again. If any developer would start a program from the ground up, things would not be so difficult, but nobody seems to want to start at the fundamentals when they can use already written building blocks.
!