• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

more multi-threaded programs since i7

If we finally start getting more multi-threaded apps, it won't be because of i7, it will be because the average person finally has something that can process more than one thread (anything from a Hyperthreading P4 to an Athlon X2 to a Core2). It's the foundation of existing processors which finally have created an environment where programming for multi-threading is no longer a niche. Of course the i7 will benefit greatly from those optimizations.

I'd guess we might also see some existing multi-threaded apps, some of which currently only make use of 2 cores/processors, expand to use more.
 
Would be nice to see other browsers follow Chrome with the individual process for each tab.
 
Multi-core CPUs have been out for several years now, so I highly doubt that i7 specifically will have any significant impact on the advent of more multithreaded apps. However, the vast majority of new PCs nowadays have dual or quad-core CPUs, so as time goes on and more and more people purchase systems with multiple cores, there will be an increasing emphasis on SMT optimizations.
hahahahahahahahahahaha

How insightful.
 
How insightful.

Here is a question for everyone. Why do we need applications that can "utilize" more than one core? Answer... We don't. I think that people have confused what multicore cpu's are for. The future of programming, imho, will be stream processing to the point everything is done in real time.
 
Here is a question for everyone. Why do we need applications that can "utilize" more than one core? Answer... We don't.

Answer: so we can run them faster, and make more efficient use of the multiple cores that most CPUs nowadays have.
 
Answer: so we can run them faster, and make more efficient use of the multiple cores that most CPUs nowadays have.


That's not what multicore cpu's are for. They are more for multithreading. If you want programs to run faster, its going to have to be on a stream processor.
 
That's not what multicore cpu's are for. They are more for multithreading. If you want programs to run faster, its going to have to be on a stream processor.
What you're saying makes no sense. Multithreading exists specifically for the purpose of making things run faster. If you can split something into two threads and run them simultaneously, it will end up being executed twice as fast as if you had to shove them both through the same thread.

Also, a "stream processor" is a multi-core processor. It's simply a ton of very simple CPU cores packed into the same die.
 
The logic between stream processors and cpu's are totally different. I am saying that even though a mutlithreaded app will run faster than a single threaded app, it will still be slower than a program that can utilize a stream processsor. That is why we are seeing cuda and stream coming out.
 
A stream processor is still not a CPU, and it is nowhere near as generalized. If we could use stream processors for everything, we wouldn't have CPUs any more. The fact is, there are distinct benefits to multithreading applications, and you cannot deny that.
 
What you're saying makes no sense. Multithreading exists specifically for the purpose of making things run faster. If you can split something into two threads and run them simultaneously, it will end up being executed twice as fast as if you had to shove them both through the same thread.

Also, a "stream processor" is a multi-core processor. It's simply a ton of very simple CPU cores packed into the same die.
I am going to second this.
Do you have any idea what you're talking about?

Zero82z, I have money on this kid failing out of second year computing science because he can't even do algorithms...

Wow... He is so CONFUSED!
 
The logic between stream processors and cpu's are totally different. I am saying that even though a mutlithreaded app will run faster than a single threaded app, it will still be slower than a program that can utilize a stream processsor. That is why we are seeing cuda and stream coming out.

Let's see, we're talking about a stream processor and a CPU. Just in case you didn't know, CPU is an acronym for Central Processing Unit. Hm... stream processor and Central Processing Unit. The main word between the two is basically the same thing.

Since you are relating stream processor to video cards, I'll continue on with that. When you get down to the nitty gritty, stream processors are nothing but simple, specialized CPUs. They can crunch a very limited type of calculations but they are very fast at crunching those specific calculations. They also excel in situations where there are many of them and what they are crunching can be broken down into a lot of small pieces to be crunched at the same time.

What you are doing is confusing a general purpose CPU with a specialized CPU. Stream processors are nothing more than specialized CPUs. Specialized CPUs are very fast at doing what they do but are very limited in what they can do. General purpose CPUs are basically made up of a number of "specialized processors". You have things such as embedded math coprocessors, SSE extensions and many other things. The reason why general purpose CPUs aren't as fast on many things is because they don't have large numbers of the same specialized processors compared to something like the stream processors in video cards. General purpose CPUs such as the Core line, the i7, Athlons and Phenoms are made to be able to compute a lot of different types of calculations and therefore can't be masters of all of those types of calculations.

Now to bring all of this back together. Multicore CPUs can act in the exact same manner as stream processors on GPUs. If the types of calculations of the whole can be broken down into parts to be run on the different cores, the overall time it takes to finish the whole is shortened. This is the exact same way stream processors are used. A good example of gains which can be made using multicore CPUs is video encoding. A properly threaded and optimized encoder can almost halve the time needed to encode a video with each doubling of the number of cores.

 
stream processors uses a parallel logic http://en.wikipedia.org/wiki/Stream_processing while a "cpu" uses a series logic, if that makes since. I know what you are saying, some programs could not work on a stream processor, nor would you want some of them to, ie: office programs. But for encoding, decoding, video, etc... these types of programs would benefit greatly from a steam processor and these are the programs you guys are probably hoping to run faster.
 
Considering Intel will eventually only offer the Core i7, I imagine that developers will start making programs that can scale with 2-4 or more cores, by themselves. There's going to be anywhere between 2-8 cores or more in mainstream system in the next few years. They have to do something.
 
Multi-core CPUs are parallel. Two cores running a thread each simultaneously: parallel. Seriously, quit while you're behind. You clearly aren't very well-informed about the things you're trying to talk about.

I said parallel logic... you know, like nand, nor, and and gates are what make up logic.
 
Sadly we actually have more multithreaded apps because od the lowly Pentium 4 w/HT. That is what paved the way, and Intel getting everyone to compile for it is the sole reason core and core2 were so fast out of the gate with true dualcore. Thats what SSE3/4 are all about.
 
I said parallel logic... you know, like nand, nor, and and gates are what make up logic.

Then your statement is just as incorrect. A "stream processor" is still made up of many individual cores, each of which uses series logic, although the logic in a stream processor core is much simpler than that of a general purpose processor. A stream processor is a many-core CPU, pure and simple.
 
zero I think he's trying to express his noob half-adder full-adder logic we're taught in first year (lols IRL)
 
No, I'm just a programmer who laughs at someone who talks about things theyre totally inaccurate on.
 
Well, let's put this another way...as the number of cores continues to double every two years, it becomes infeasible to write code for each thread individually; I'm not going to manually write 256 code paths and deal with all the synchronization issues between threads, it's virtually impossible to get an ad hoc 256 thread application working properly.

Instead developers and engineers will have to work in a structured programming model, like the data parallel model (i.e. the model used by stream processors), in which one chunks a massive amount of data into several independent subproblems and have each stream processor handle the problem independently, and the synchronize the entire stream, then apply a second pass of processing and so on. That's the data parallel programming model in a nutshell.

Most other multithreaded programming models don't scale as well. For example, one could take the pipelined approach, where the problem is split into several consecutive subproblems, and we have multiple instances of the given problem, as a car assembly line, you can think of each thread as a person on the assembly line. The previous thread passes a task to a given thread and that gets queued up, and as soon as the thread is available to process the job, it does and passes it on to the next thread to complete its part.

Really these kinds of models need to be used in the future so that we don't have to rewrite the application as hardware manufacturers add more and more cores.
 
I thought this was something Windows 7 was going to take care of... Since most of the Windows 7 boxes will be quad core (or more) it made more sense for the OS to do this sort of thing.
 
Multiple-core CPUs were originally concieved to improve server applications in which many simple tasks are being performed simultaneously. In this case the OS is the "Threaded application." Multi-core CPUs improve desktop performance greatly as well. Does anyone remember when you had to touch the GO button to burn a CD and then avoid looking at the computer until it was done. the slightest hiccup would make a coaster. I loved my first hyperthreading CPU. I still own it and it folds even today.

Nowadays single-core performance has reached a feasible limit. The logical choice is to continue scaling the core count and let the software catch up. Many games and encoding apps take advantage of 2 cores. They logically should because dual-core CPUs are the vast majority in average users' computers. If they can save alot of development cost by writing for 2 cores only they only leave a handful of quad-core benchmark junkies out in the cold. Even if a single application can only utilize 2 cores your quad is not wasted. The OS will keep the overhead tasks out of the way of the high-performance app for the most part.
 
I thought this was something Windows 7 was going to take care of... Since most of the Windows 7 boxes will be quad core (or more) it made more sense for the OS to do this sort of thing.

The OS can't magically make an application multithreaded. It has to be specifically designed that way in order to take advantage of multiple cores. All the OS can do is assign different processes to different cores to make the best of that it has, but that still isn't really maximising the efficiency of a multi-core CPU.
 
Multiple-core CPUs were originally concieved to improve server applications in which many simple tasks are being performed simultaneously. In this case the OS is the "Threaded application." Multi-core CPUs improve desktop performance greatly as well. Does anyone remember when you had to touch the GO button to burn a CD and then avoid looking at the computer until it was done. the slightest hiccup would make a coaster. I loved my first hyperthreading CPU. I still own it and it folds even today.

Nowadays single-core performance has reached a feasible limit. The logical choice is to continue scaling the core count and let the software catch up. Many games and encoding apps take advantage of 2 cores. They logically should because dual-core CPUs are the vast majority in average users' computers. If they can save alot of development cost by writing for 2 cores only they only leave a handful of quad-core benchmark junkies out in the cold. Even if a single application can only utilize 2 cores your quad is not wasted. The OS will keep the overhead tasks out of the way of the high-performance app for the most part.



This kind of reasoning will only work for the next 4 years or so. As the number of cores in a mainstream machine shifts to 8 or 16, if you need to program for each core individually, chances are, you'll have extremely buggy deadlock and race condition ridden code. The push by Intel and AMD to continually increase the number of cores in a processor package will force developers to switch to a new programming model or an advanced parallelizing compilers (which are extremely difficult to write and are still the subject of much research by Intel and others).


In a nutshell, are 8 virtual cores going to affect the way software is being produced? You betcha!!! There will always be lazy developers and companies who will avoid multithreading but soon they'll have to adjust their practices to remain competitive.
 
Back
Top