backtop


Print 50 comment(s) - last by surt.. on Mar 15 at 2:37 PM

Intel says parallel software is more important for many-core CPUs like "Larrabee"

Multi-core processors have been in the consumer market for several years now. However, despite having access to CPUs with two, three, four, and more cores, there are still relatively few applications available that can take advantage of multiple cores. Intel is hoping to change that and is urging developers of software to think parallel.

Intel director and chief evangelist for software development products talked about thinking parallel in a keynote speech he delivered at the SD West conference recently. James Reinders said, "One of the phrases I've used in some talks is, it's time for us as software developers to really figure out how to think parallel." He also says that the developer who doesn’t think parallel will see their career options limited.

Reinders gave the attendees eight rules for thinking parallel from a paper he published in 2007 reports ComputerWorld. The eight rules include -- Think parallel; program using abstraction; program tasks, not threads; design with the option of turning off concurrency; avoid locks when possible; use tools and libraries designed to help with concurrency; use scalable memory; and design to scale through increased workloads.

He says that after half a decade of shipping multi-core CPUs, Intel is still struggling with how to use the available cores. The chipmaker is under increasing pressure from NVIDIA who is leveraging a network of developers to program parallel applications to run on its family of GPUs. NVIDIA and Intel are embroiled in a battle to determine if the GPU or CPU will be the heart of future computer systems.

Programming for processors with 16 or 32 cores takes a different approach according to Reinders. He said, "It's very important to make sure, if at all possible, that your program can run in a single thread with concurrency off. You shouldn't design your program so it has to have parallelism. It makes it much more difficult to debug."

Reinders talked about the Intel Parallel Studio tool kit in the speech, a tool kit for developing parallel applications in C/C++, which is currently in its beta release. Reinders added, "The idea here [with] this project was to add parallelism support to [Microsoft's] Visual Studio in a big way."

Intel says that it plans to offer the parallel development kit to Linux programmers this year or early next year. The CPU Reinders is talking about when he says many-core is the Larrabee processor. Intel provided some details on Larrabee in August of 2008.

One of the key features of Larrabee is that it will be the heart of a line of discrete graphics cards, a market Intel has not participated in. Larrabee is said to contain ten of more cores inside the discrete package. If Larrabee comes to be in the form Intel talked about last year it will be competing directly against NVIDIA and ATI in the discrete graphics market.

NVIDIA is also rumored to be eyeing an entry into the x86 market as well. Larrabee will be programmable in the C/C++ languages, just as NVIDIA's GPUs are via the firms CUDA architecture.



Comments     Threshold


This article is over a month old, voting and posting comments is disabled

What am I missing here?
By Motoman on 3/11/2009 2:49:10 PM , Rating: 5
...it seems to be pretty obvious that there are LOTS of computing processes that are, by laws of nature, purely serial processes - i.e. they can't be parallelized.

Intuitively it seems very clear that there is a very low ceiling, for the home user at least, on the number of cores that will help with anything. Server applications are a totally different animal...I'm thinking in terms of desktops and laptops for typical users.

What magic is going to be invented to allow parallel processing on processes that are inherently serial in nature?




RE: What am I missing here?
By TomZ on 3/11/2009 3:01:53 PM , Rating: 3
I don't think that the typical application is inherently serial. For example, most non-trivial GUI applications are inherently multi-threaded because they have at least two threads: one for processing the GUI, and another for performing the "work" of what the GUI is supposed to do. This is because you want the GUI to continue to be responsive while the "work" is being done.

For example, consider a simple e-mail client. There is makes sense to have one thread that runs the GUI and one more threads handling the communication with the server.

Even "pure" GUI apps like word processors and spreadsheets, whose only purpose is to react to user input, can benefit from additional threads. For example, Word uses background threads for saving, printing, etc.

In programming on .NET, the architects of that platform have also made multithreaded programming very easy and convenient. Launching threads is easy, there is a background worker component, and there is even a thread pool which you can easily use to dispatch little pieces of work to lots of threads.


RE: What am I missing here?
By Motoman on 3/11/2009 3:06:45 PM , Rating: 5
OK, but isn't there a limit to how many threads or processes can realistically be useful for typical things, like office suites and gaming? That's what I meant by a "ceiling" - say 4 cores might be the most that could really be useful, and if you had 16 cores the typical user wouldn't see any benefit...simply because typical desktop uses don't have that much parallel capability in them?


RE: What am I missing here?
By TomZ on 3/11/2009 3:27:16 PM , Rating: 2
Yes, I agree - there is probably a low ceiling for typical user applications.

The only application that I would think the "average user" might use more than 4 cores for would be video encoding/transcoding, e.g., "burn to DVD" type functionality in various kinds of apps. This kind of work seems to naturally scale up to a large number of cores.


RE: What am I missing here?
By Fox5 on 3/11/2009 3:38:03 PM , Rating: 5
In my experience with programming, more threads are a bad thing if you can't figure out what to do with them.
While it's not a bad idea to decouple a user interface, throwing threads at a problem without sufficient work (and hardware) for each thread to do tends to have a negative performance impact, or minimal gain.


RE: What am I missing here?
By TomZ on 3/11/2009 4:22:20 PM , Rating: 5
Not to mention that creating synchronization bugs in multi-threaded apps is very easy, and finding/fixing them can be very difficult.


RE: What am I missing here?
By acronos on 3/11/2009 3:54:18 PM , Rating: 2
GPUs benefit from as much parallel processing as you can throw at them. Video processing and compression, artificial intelligence, and speech processing do too. The very reason that GPUs are becoming a threat to the CPU is that they are massively parallel. Most of the applications of today that need significantly more speed lend themselves very well to parallel processing. I'm not saying that there are no applications that benefit exclusively from serial processing. I'm just saying that there is not some arbitrary number of processors that after which we stop benefiting.


RE: What am I missing here?
By William Gaatjes on 3/11/2009 4:04:19 PM , Rating: 2
In general, you are running a program on top of an os. The os will make sure all the programs(which usually are build up of multiple treads) get their chance to do some work when you have more cores. This will give you the smooth response you are used too already but with more features, more eyecandy and so on. When talking about massively parallel like larrabee, for games it can be a lot handier to have lot's of cores. You can read this tread on anandtech if you are interested... There are lot's of links about what is possible. And when it comes to games, better physics, more degrees of freedom. For games, to make the game more realistic, there are just not enough cores...

http://forums.anandtech.com/messageview.aspx?catid...


RE: What am I missing here?
By William Gaatjes on 3/11/2009 4:09:24 PM , Rating: 3
I quote a part of text i found :

quote:
In a neat bending of technology to an unintended use, Daniel Pohl did one really cool thing, he used the same rays that you use for graphics to do collision detection. You cast rays out from the player and everything they hit may be an object. Since the math is being done already, collision detection, one of the harder problems with 3D games, is done for you. It isn't free, but considering how many millions of pixels there are on a screen, 1600*1200 would be almost 2 million pixels, a few hundred more per object is rounding error. You can do much more accurate collisions for every bullet and bit of debris spinning around, and do it right.


This is about raytracing games and larrabee rumoured to be the next co processor for cell in the PS4.

Here is the link of the page :

http://forums.anandtech.com/messageview.aspx?catid...


RE: What am I missing here?
By melgross on 3/11/2009 4:51:31 PM , Rating: 2
On the other hand, we also use more than one program at a time. This can easily make those extra cores useful. Multitasking on single core single cpu systems never worked as well as it was claimed to, because a cpu only has so many free cycles. with multi cores, and hyperthreading, that bottleneck is eliminated. You can use Word, while rendering in the background. Word would be happy with one core most of the time, while the editor could be happily using the other 7.

Try that on a two core machine, and everything, (including the OS itself) gets bogged down.


RE: What am I missing here?
By mindless1 on 3/11/09, Rating: 0
RE: What am I missing here?
By mindless1 on 3/11/09, Rating: 0
RE: What am I missing here?
By mindless1 on 3/11/09, Rating: 0
RE: What am I missing here?
By sinful on 3/11/2009 7:47:55 PM , Rating: 5
Stop spawning multiple threads in paralell!
;)


RE: What am I missing here?
By surt on 3/11/2009 5:21:55 PM , Rating: 1
Office suites: maybe. But office tools have been essentially instantaneous response tools for a long time anyway. You don't need any more power for these whether from cores or from clock speed.

Games: no way. You can use as many cores as you want for games. Most games being put out these days could be easily written to support thousands of cores for better performance. Games are extremely parallel in nature, and not just in graphics, but in mechanics as well.


RE: What am I missing here?
By sinful on 3/11/2009 8:02:52 PM , Rating: 2
quote:
Games: no way. You can use as many cores as you want for games. Most games being put out these days could be easily written to support thousands of cores for better performance. Games are extremely parallel in nature, and not just in graphics, but in mechanics as well.


Not quite. Most games are *extremely* serial.

Think about it: most games are 100% dependent on what key you press at that moment.

In other words, there are practically an infinite number of possible moves you could do, but you have no idea which one until the user has decided.

It's not like you're blindly chugging away at 10GB of video and only worried about throughput, you're concerned with 10K worth of data that you have to act on as soon as possible. Whether you have 8 cores or 4 cores waiting for that data is pretty irrelevent - they can't do much (intelligently) until they know what you're going to do.

Now, you can *attempt* to decouple your input from your other tasks, but that's not an easy task - How exactly do you make the AI respond intelligently to moves you haven't performed yet? Just blindly compute every possible move you might make? That can be an incredible waste of CPU power (especially if you have users not on a multi-core system).


RE: What am I missing here?
By Scrogneugneu on 3/11/2009 10:06:38 PM , Rating: 4
Very, very wrong.

Suppose a game has a single-threaded AI engine. Whenever the time to render a screen comes up, that thread needs to figure out what each and every character in the scene will do in reaction to it's environment. So if you got 20 characters and need an average of 2 ms to determine the course of action per character, you use about 40 ms to compute that. That's serial processing.

Now suppose it has a multi-threaded AI engine (let's say 4 threads). Whenever the time to render a screen comes up, a bunch of threads can compute the reaction of every character simultaneously, rather than one-by-one. So if you got 20 characters and need an average of 2 ms to determine the course of action per character, you use about 10 ms to compute that (20 characters x 2 ms each / 4 threads). That's parallel processing.

In theory , the parallel engine could handle 80 characters while maintaining the same performance level of the serial engine.

Of course, the multi-threaded solution has some overhead, the numbers are simplified. And I'm not even talking about the mess you can get into if a bug sneaks his way into your data synchronization mechanism. But you should get the idea why a multi-threaded game engine has more potential than a single-threaded one.


RE: What am I missing here?
By sinful on 3/14/2009 3:58:18 AM , Rating: 2
quote:
Now suppose it has a multi-threaded AI engine (let's say 4 threads). Whenever the time to render a screen comes up, a bunch of threads can compute the reaction of every character simultaneously, rather than one-by-one. So if you got 20 characters and need an average of 2 ms to determine the course of action per character, you use about 10 ms to compute that (20 characters x 2 ms each / 4 threads). That's parallel processing.

In theory , the parallel engine could handle 80 characters while maintaining the same performance level of the serial engine.

Of course, the multi-threaded solution has some overhead, the numbers are simplified. And I'm not even talking about the mess you can get into if a bug sneaks his way into your data synchronization mechanism. But you should get the idea why a multi-threaded game engine has more potential than a single-threaded one.


But you're comparing practical *real-world* vs. *theoretical*, and no surprise, the theoretical sounds better.

In *theory*, space travel is simple. In reality, it's really complicated to actually do.
Lots and lots of cores offers amazing speedups in *theory*, but in reality it's extremely complicated to actually do.

For example, a counterpoint to your example:
Let's say the single thread can utilize the same data for each character. Instead of each additional character taking another 2ms, you might have the 1st one cost 2ms and the subsequent ones cost .5ms. Computing it serially, your 20 characters cost about 12ms.

In contrast, the multiple threads might not be completely independent - what happens when all 20 characters are in the same area? What other factors in the environment affect them? You also assume the total cost of the AI is 100% CPU bound, and not determinant upon something else - like memory speed, etc. You also assume that all 20 AI threads would execute at the same time - requiring 20 cores. In reality, you might only have 8 cores, so not all characters can be computed simultaneously. In fact, if you've got 8 cores, you're stuck waiting for at least one core to compute 3 character AI's sequentially (i.e. 20 characters/8 cores = 2.5 characters per core = at least one core computing 3 characters). Thus, 3 characters x 2ms = 6ms - without your extra thread overhead.

After all is said and done, we'll say your multi-core approach now takes 8ms. Yes, 8ms is better than 12ms.... but how much is that going to help in the real world? And how much more complicated have you made things?

Granted, multiple cores offers some improvement - but it quickly reaches limits as to how far it scales, and to how much it can improve things.
As such, it only really shines when you have huge amounts of data to process - and the data is independent.

In your example, the benefits of saving 8ms probably wouldn't be worth it (Even though it sounds great on paper!).

Now, if you're talking about 20,000 characters, then yes, it would help.

There's a HUGE difference between theory and reality.


RE: What am I missing here?
By Scrogneugneu on 3/15/2009 11:52:52 AM , Rating: 2
Do you know anything about programming?

Multiple threads can read from the same data all the same than a single thread. Concurrency problems only happen when 2 threads want to write to the same memory emplacement, reading can be infinite. The state of everything in the game can be read, but no change will happen to it until the next frame render, so each and every thread can read the same data at the same time.

This isn't mentioning that I talked about a 4 threads engine, and you picked up and went with a 20 threads engine. If you want to compute 20 characters' actions, splitting it in 4 threads requires each thread to compute 5 characters sequentially. One thread per character is very, very wasteful.

Plus, the advantage I pointed out was that you could manage more AI resources in the same time. You can go from there and add a lot of complexity to the handling of the AI, thus ending up with a much more intelligent character. Suppose we do, and the computation time goes up to 5ms per character. By taking your own numbers (supposing the data reuse you speak of saves us 1.5ms per character), we end up with 5 + (19x3.5) = 66.5ms sequentially. Using your 20 threads example, that would be 3 characters x 5ms = 15ms.

Threading isn't meant to gain tremendous speed on everything. It's meant to handle large workloads better. Nobody will implement threading on simple tasks, but the capacity to lower the additional cost per character on AI computation is huge. The same logic goes for physics.


RE: What am I missing here?
By surt on 3/12/2009 11:09:59 AM , Rating: 4
Sorry, that's not at all how well designed games actually work. They maintain a (relatively) simple game state, and update that in response to user / AI input. The game state can typically be modified in parallel, so they don't even have to force the AI to act serially, they can run AI in threads. The AI 'responds' to the change in game state as soon as you have moved and that data is committed to the shared state. Decoupled input is de rigeur in the gaming industry.

Then, also on a completely different set of threads, you have rendering, which is the process of converting the current game state to the video display. Rendering currently takes 90% of the CPU and pretty much 100% of the GPU in most titles, and rendering can easily be scaled to thousands of cores.

I worked on Diablo II. We had 9 threads there a decade ago, and could have used far more if our target audience had more cores. Things have only grown to favor multicore more in the transition to heavier and heavier 3D.


RE: What am I missing here?
By sinful on 3/14/2009 4:24:38 AM , Rating: 2
quote:
I worked on Diablo II.


Sure you did, and I taught John Carmack everything he knows about multithreading & games. LOL

quote:
We had 9 threads there a decade ago, and could have used far more if our target audience had more cores.


That said, there's a world of difference between multiple threads, and actually taking advantage of multiple cores.

Tell me, oh wise DiabloII inventor, how well does DiabloII benefit from multiple cores? If I run it on a 8 core box, am I going to see it using all those cores?
Or is it just going to peg one core at 100% while all the others idle?? Hrmmmmmm.....?


RE: What am I missing here?
By surt on 3/15/2009 2:37:55 PM , Rating: 2
Depends on your cores. Chances are you'll peg 3 cores. If you are hosting a game (and playing on the same box) you might be able to peg 8 cores. We designed the game host side code to scale to many many cpus because that's how the servers are set up (we host hundreds of games on a 64-core box).


RE: What am I missing here?
By nn on 3/12/2009 6:37:07 AM , Rating: 2
No there are a lot of things which are naturally parallelizable, even in a office suite. Of course it might not make sense to run the GUI itself on lots of threads. Although if you have a toolkit that supports it nicely, like Apple's new event loop or using a Larabee auto parallelizing render backend even that could be quite doable.

Then if you only think two threads or a fixed number of threads
you're thinking far too small. The key is data driven parallelization (that is what he meant with "tasks" I think).

But just consider the tasks which are slow. Recently I had to wait for a very long time for OpenOffice to load a large .doc document to convert it into its internal format. File conversion is something that is inherently parallelizable: there's no reason it couldn't process each page in parallel as soon as the data comes in from the disk controller. In Reindeer's terminology each page could be a "task". There's no synchronization needed there either except for finally queueing the pages into a list.

Or what takes a long time for for me is searching strings in a large PDF (which I do often). Again strings search is something that is very easily parallelizable: no significant serial Amdahl component in there.

Instead of going through the whole document one by one partition it into N chunks (N as many as I have CPU threads) and search those in parallel and display the results in order. Sure that could waste some work because I may be only interested in the first match, but there's enough CPU power available now so why not use it?


RE: What am I missing here?
By ncage on 3/11/2009 7:38:19 PM , Rating: 3
Your confusing async calls and parallizing code which are totally different things. Your talking about giving UI control back to the user rather than locking the UI up when they are doing something....say for example a long database operation. This is done with async callback delegate so that the blocked statement (database call in this case) will notify you when its finished. Your NOT increasing the efficiency or speed of whatever your trying to do. If you executed the same code but sync (only on one thread) then the UI would lock up but it wouldn't execute any faster.

Parallelizing code is another animal in itself. Say for example you return 100 records from database and you need to do the same operation on each of the 100 records and none of the operations are dependent on any of the other operations then you could create possibly 4 threads and process the records in 1/4 time (this is a perfect case senario and nothing is ever perfect). Parallelizing code is HARD. Its not even close to easy. In the above case it was easy because there was no dependencies and each of the 100 rows was not dependent on another row. In real life this usually doesn't happen. There are dependencies. There are locks....whether it be file locals, global variables, database...ect ect. This is why you get bugs will only happen once in 1,000,000,000 runs through the code and are almost impossible to find

Threads are EASY to create in .Net but paralizing code safetly and correctly is no where near easy. .Net is not thread safe and it will never be unless you want to go back in time and recreate apartment threading like VB6 had. Microsoft is doing research to try to make some paralizing easier (PLINQ (Parallel Language integrated Query)) but currently its hard and like another poster commented...there is a lot of code that i serial in nature and can't be parallelized. Only small sections will lend themself to being parallized. If intel wants people to use all the cores then they will have to produce better compilers/tools to help developers with this.


RE: What am I missing here?
By Dribble on 3/12/2009 5:51:09 AM , Rating: 2
Not strictly true - paralysing so your ui runs in one thread, and various other bits run in other threads is pretty easy as long as you have some libraries to allow you to do the communication and access data in a thread safe and efficient way.

I find the biggest limitation is memory - a lot of operations effectively require you to go up and down through memory looking for stuff and then producing a list of results. It's not particularly cpu intensive but it does require a lot of memory access (e.g. rendering once you've done the cull basically involves looking at your data set and passing a bunch of triangles to the gpu - that is memory intensive more then cpu intensive).

Hence it's not worth trying to multi-thread many of those operations as cpu processing speed is not the limitation, equally moving work to the gpu won't help - it'll just make it slower as you have to push all the data int gpu memory before you can do the operation.


RE: What am I missing here?
By gss4w on 3/13/2009 2:34:01 AM , Rating: 2
That's true, but these types of threads will typically be blocked waiting for I/O most of the time, so they don't really need a multi-core CPU. What Intel is saying is that computationally intensive work needs to be made multithreaded. But in many cases this is very hard to do.


RE: What am I missing here?
By codeThug on 3/11/2009 5:28:38 PM , Rating: 2
quote:
What magic is going to be invented to allow parallel processing on processes that are inherently serial in nature?


Pipelining, prefetch, branch prediction etc. are quasi parallel operations that can speed up serial code. Beyond that you are back to faster silicon and possible things like asynchronous clocking.

Of course you can always fold space/time to achieve the answer before you even ask the question.


RE: What am I missing here?
By Motoman on 3/12/2009 12:24:34 PM , Rating: 2
42.


RE: What am I missing here?
By rhog on 3/12/2009 2:10:50 PM , Rating: 2
It is really very simple. A task may be serial in nature but this does not mean that only this serial task should be performed at any given moment in a process. There are many tasks that can be performed simultaneously and this can best be descibed by concept of multi-threading. The more processes the more threads (or tasks) can be performed at the same time. There are cetainly going to be times when only one task should run in a process (writing data to a file that must be used by multiple threads is a good example). But then you can have another unrelated process executing at the same time that does not rely on this file data. These are crude examples but I hope this explaination helps.


RE: What am I missing here?
By kaddar on 3/12/2009 6:14:57 PM , Rating: 2
Algorithms that iterate over sets of data and perform an operation on each element in the set, where that operation is independent of the others, are very very parallelizable. These algorithms exist throughout your operating system, but nobody bothers to parallelize them because there would be serial overhead if you don't have a parallel machine, and it's more expensive to test these systems as a software development house.

Google Map-Reduce or Scheme/Lisp languages are good examples of how to parallelize things without large complexity. It is the magic you're talking about. It's not that things are serial, or that things need to be written in a super smart way, we just need to write different loops instead of for each loops when the data meets certain constraints.


Intel Parallel Studio
By poundsmack on 3/11/2009 2:07:39 PM , Rating: 3
http://software.intel.com/en-us/articles/intel-par...

been using the beta for a while, it's good stuff. Can't wait to see more dev's jump on the band wagon.




RE: Intel Parallel Studio
By az981 on 3/12/2009 9:55:10 AM , Rating: 2
both MS and Intel solution may be coming but they don't resolve the main problem with easier-to-write parallel applications. Not to mention the multiple number of restrictions which are in place in both products to conducting parallel operations.

Here is a much better solution which addresses the problems:

http://www.getsolution.net

parallel application platform that takes the normal code and executes it in parallel.


RE: Intel Parallel Studio
By TomZ on 3/12/2009 12:13:48 PM , Rating: 2
Wow, a real silver bullet to solve that problem once and for all. :o)

Color me skeptical.


RE: Intel Parallel Studio
By az981 on 3/12/2009 1:10:58 PM , Rating: 2
may be. it does solve most of the problems for now


RE: Intel Parallel Studio
By TomZ on 3/12/2009 1:53:25 PM , Rating: 2
That looks more like pipe-dream than a product. Where can I purchase it or download an evaluation from? Where can I get detailed information besides the 5-page template web site?

I'd guess you work there or own the company and are just trying to promote your business here on DT. Best of luck with that.


RE: Intel Parallel Studio
By az981 on 3/12/2009 2:17:28 PM , Rating: 2
thanks for the good description - a dream product :)

yes, I work for the company and I am trying to make the people aware that solution is possible. I know the subject is vast and can cover many hours of discussion but at least we've tried to address the problem. of course "living in a shell" is not our way - any views or suggestions are welcome.

and to your notes:

pipe-dream - nope, reality
download - yes, now. since we don't know who you are you'll get a download if you contact us via the email with some more info about yourself
purchase - not really - free of charge
detailed information - how it works, demo scenarios, installation help - certainly. via email.

best regards


RE: Intel Parallel Studio
By TomZ on 3/12/2009 2:39:26 PM , Rating: 2
This is all a conspiracy to find out the true identity of "TomZ" :o)


RE: Intel Parallel Studio
By az981 on 3/12/2009 5:51:29 PM , Rating: 2
notes taken :)
will post a public demo probably on 14/03/09


Long time coming, hurryup.
By Uncle on 3/11/2009 3:05:16 PM , Rating: 2
I like it when some truth gets quoted about software not being ready for 3 or 4 cores. It seems like he is begging for the developers to get on the turnip wagon or the Industry can't justify the quads, because if they don't, consumers will start to see the light and not put aside perfectly good equipment just to keep shareholders happy. Now for some self affirmation. It justifies my sitting back and not getting caught up with hyper marketing. Looks like my overclocked two core 3ghz opteron on a DFI Expert has lots of life left in it. I've only changed out my video card once in the last three years,I'm ready for my next video card which will go into this system. Anyone else who has done their homework over the last few years and saved a few bucks, pound or yen, a little self affirmation helps.




RE: Long time coming, hurryup.
By TomZ on 3/11/2009 3:30:53 PM , Rating: 2
Not sure about that. I just replaced a reasonably fast dual-core machine with a (quad-core) Core i7, and I think it was worth the cost of upgrade. The i7 machine is at the same time very fast and very quiet compared to the previous one. I noticed a huge speed increase especially for video transcoding, i.e., burn to DVD processing.


RE: Long time coming, hurryup.
By Spectator on 3/12/2009 4:17:30 AM , Rating: 2
I to did i7 for dvd stuffs. but best i seen is 4 threads not even maxed out.

never understood it really. there is a key frame every 3min? why not break up the encode into 20-30 3min chunks and send all 20-30 threads off for processing independantly?

that would be a good example of a parralel task done properly?


By SublimeSimplicity on 3/12/2009 10:36:56 AM , Rating: 2
I think you're right to an extent, I do believe Intel is begging, but I think it's actually for a competitive advantage.

Right now they're the only Hyper-Threading game in town (and probably that way for the foreseeable future). With memory latencies only increasing as we move from DDR2, to DDR3, to DDR93 and beyond. Hyper-threading will become a much more important competitive advantage with these increased latencies, but only if applications take a parallel task approach to development.


RE: Long time coming, hurryup.
By Spectator on 3/12/2009 11:47:21 AM , Rating: 2
Funny that. only have to swap out your vid card statement.

if I was like you and thought about longer term changes(sht im just a dumb short sighted user. :P)

you could say that the i7 is a server design cpu that just happens to own the desktop market.

next we could look at the QPI on the i7. which was designed for cpu/cpu coms.

then we could also consider your graphics changing logic.

What if intel considered this years ago. and decided on say "Larrabee". then you can also buy intel silicon for graphics AND it works best linked to QPI rather than some global pci-x bus(amd/nvid).

yes you would have to wait until i7/i5 is domminant. and also go through all hassle of making new QPI slots on motherboards(but sht pci-x will be old in a year or two yes?)

So yes you may be right. but also its fun to think ahead in a wider scope.

DISCLAMER "Info was implied in the above statement"


der
By MadMan007 on 3/11/2009 3:04:42 PM , Rating: 5
Headline - "Intel states the obvious"




RE: der
By someguy123 on 3/11/2009 9:36:27 PM , Rating: 2
in other news,

Nvidia is also on record saying that developers should program games for physics accelerators like physx in order to see benefits from the physx chip.


Dev Tools are coming...
By JavaMomma on 3/11/2009 2:42:26 PM , Rating: 3
Visual Studio 2010 - .NET 4.0, parallel extensions will help
http://channel9.msdn.com/pdc2008/TL26/

I'm looking forward to it anyways...




...
By StevoLincolnite on 3/11/2009 3:16:30 PM , Rating: 3
quote:
One of the key features of Larrabee is that it will be the heart of a line of discrete graphics cards, a market Intel has not participated in.


Not entirely accurate, Intel had the AGP i740 line of Graphics cards.




Intel betting big on The Cloud and HPC
By Shig on 3/11/2009 5:01:40 PM , Rating: 1
Intel is really putting the bulk of their R&D towards CPU architectures for the high performance computing area and the server market, because that's where market research shows most of the high end cpu's will be sold in the future. CPU's like Atom will soon dominate the home PC area with the slack being picked up with optional GPUs.

Nehalem is a server chip, it really isn't meant for the desktop environment where software is upgraded and rewritten very slowly. As opposed to a data center where the software is incredibly advanced and is specifically designed for thousands of cores. Yes the performance is amazing, but it's not even close to the performance Nehalem gets when it goes into the server area.

But then again software won't really be an issue in 5-10 years when every chip will be a system on a chip capable of doing every task well : from the most single threaded stuff, to the most highly parallized stuff. We're just not there yet and I think it's unfair for Intel to blame software engineers for not adhering to their specific architectures fast enough.




By Spectator on 3/12/2009 12:46:05 PM , Rating: 2
off topic but fun..

US/Canada is sitting on oil/gas while selling equipment that eat's shat loads of the stuff. Yes they save thier own resources while buying others.

Its totally logical and I agree with it. why be a pawn when you can manipulate others and be the boss.

lol. that sht has worked for decades over here in UK.. but Shhh. dont tell the tax payer. :P

Moral is: use your strength to gain an advantage above all else, at the bare minimum you will make some personal cash.

It may be "Wrong" but above all your better off (Stronger) than most of the others. lol

For the Older folk. Enter the Dragon(Bruce lee).."Strength makes all other values possible".. Nuff said.


Retarded comment...
By oTAL on 3/12/2009 6:38:26 AM , Rating: 3
quote:
"It's very important to make sure, if at all possible, that your program can run in a single thread with concurrency off. You shouldn't design your program so it has to have parallelism. It makes it much more difficult to debug.


The problem with programming concurrent threads in an app is that it is sometimes hard to understand all the effects introduced by having things happen in a different order and with different timings.

If you have a bug introduced by parallelism (a racing condition of sort) you will not be able to debug it by turning concurrency off - that will turn the bug off and solve nothing.

To solve such a bug you need to think harder, work harder, and/or get better tools - the tools part is where Intel should be (and is) focusing its efforts.




"Spreading the rumors, it's very easy because the people who write about Apple want that story, and you can claim its credible because you spoke to someone at Apple." -- Investment guru Jim Cramer

Related Articles
Intel Talks Details on Larrabee
August 4, 2008, 12:46 PM













botimage
Copyright 2014 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki