Talk:Stream processing

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the Stream processing article. This is not a forum for general discussion about the article's subject.
Please sign and date your posts by typing four tildes (~~~~). Put new text under old text. Click here to start a new topic. New to Wikipedia? Welcome! Ask questions, get answers.	Be polite Assume good faith No personal attacks Be welcoming	Article policies No original research Neutral point of view Verifiability

Contents 1 Future todos 2 Comments 3 More comments 4 cleanup required 5 Acronyms 6 Discussion note 7 Definition of uniform streaming 8 Merging with GPGPU 9 AMD introduced a stream processor 10 Merge with "stream programming"? 11 Misleading Comparisons 12 Disambiguate with Event Stream Processing?

[edit] Future todos

1. I would have added this myself but I'm quite busy at the moment and I admit it's a difficult read for me. I am speaking about a paper on conditional streams. I'll post more detail in the future.
2. Anyone ever used StreamC or Brook (two streaming languages)? I did not so I cannot write about this but I am the first in being interested with this.

MaxDZ8 09:47, 27 October 2005 (UTC)

Update: there are also some nVIDIA papers speaking about Brook for GPUs and pointing of a site which I don't remember just now. MaxDZ8 13:29, 6 December 2005 (UTC)

[edit] Comments

It seems pretty clear that AMD/ATI are trying to brand 'Stream Processing' as part of their GPU initiative. With all respect to their technology in the graphics world, the approach of stream processing is applicable to any problem that may be:

• Compute intensive (e.g. a 20:1 compute to memory access ratio)
• Data parallel to a large degree (same operation on lots of data)
• Exhibits data locality

This includes graphics engines, DSPs, IBM's cell (to a certain extent) as well a future processors in development. There is no basis to merge Stream Processing with a single class of applications. GPUs can stand on their own. Let's let this thread grow in it's own direction without commercial influence.

In C, a star combined with a data type means a pointer of that type, not an array as this article claims. The kicker is that in C, arrays are simulated via pointers, but it is disingenuous to say that the latter is the former. -FWIW.

The article exactly reads as:

For readers not experienced with C, the '*' before each identifier means 'array'. For Java programmers, this is roughly equivalent to "[]".

Your comment is undoubtly true but this would have opened a can of worms since pointers are considered black magic by a lot of people. Even Java programmers wants to avoid them like the plague. The over-simplification I used was pointed towards easier reading, moreover, streams are really arrays most of the time so this isn't exactly wrong.

C/C++ programmers, really know that * is not [] and I believe they won't be upset for this.

MaxDZ8 talk 19:29, 31 May 2006 (UTC)

There's definitely a can of worms to be opened with pointers, so I guess it's not a bad idea to avoid mentioning them. Thanks for clearing that up. -FWIW

I'm glad you agree with this. MaxDZ8 talk 09:11, 1 June 2006 (UTC)

I disagree with the initial characterization of stream processing as MIMD. Imagine is a SIMD machine; the fragment processing pipelines of GPUs are also SIMD. Certainly it's MD, but by no means is it MI.

Well, I believe you have your rights in saying this. My point is that having multiple execution units would effectively allow to execute different instructions. I also believe I've read this on some papers so I've reported this. I admit however I am not really used to MIMD so if you want to change the page feel free to do it. MaxDZ8 07:42, 17 November 2005 (UTC)

Update: the more I think at it, the more I don't understand why this is not MIMD. A computer cluster is by sure means MIMD. This means there are different instructions in flight and different data sets. Suppose the following scenario: pipeline0 is processing a lenghty loop while pipeline1 is not (say it breaked it for some reason). There will be multiple instructions in flight. Maybe you're speaking about the paradigm itself? This may be true but it still "allow Multiple Instruction Multiple Data (MIMD) data processing" (quote from article). MaxDZ8 17:09, 26 November 2005 (UTC)

Last edits are really interesting! Thank you! MaxDZ8 20:34, 4 January 2006 (UTC)

[edit] More comments

I think the claims of this article ought to be toned down. Conceptually stream processing is somewhat similiar to vector processing. Some of the Imagine folks are at a startup company named Stream Processors Inc. trying to build (you guessed it!), a commercially viable stream processor. Dyl 08:11, 28 January 2006 (UTC)

I agree with you, maybe I've exagerated the thing a bit. Although it's really a branch of vector processing, I believe there are some differences - but I'm not really used to supercomputers and stuff. MaxDZ8 15:51, 28 January 2006 (UTC)

[edit] cleanup required

The claim that the Cell processor is not a true streaming processor tipped me off that something was not right with the world. I skimmed backward trying to find a definition of "true streaming" against which to measure this claim. AFAICT this article never fully defines "streaming", and then it rambles along throwing out no end of potentially useful material without ever coming to any definite conclusions. Portions I skimmed were not accurate, either. Details such as 12V raised immediate alarms (that one I attempted to fix). In this case, I can only sigh and move on, because I've got three Cell articles of my own going right now locked down for major edits. MaxEnt 10:21, 10 June 2006 (UTC)

I originally classified Cell as "half stream". Another user however, in a very useful and detailed major edit wrote this is not true. Watching at the other additions he made, I am confident he's very intimate with the technology and I respect its definition. Take a look at edits User:67.155.108.10: I don't feel confident enough to wrote them another way (I am more from a GPU background).

This article does not striclty define "streaming" because it's inferred from a bunch of references (listed and not listed) I have read - they didn't define "streaming" either. To a certain degree, they were also contradictory since for example, AT&T recognizes GPUs as "stream processors" while others do not. Another article says all processors are "stream processors" to a certain degree. The error about voltage is another artifact of the references. Trying to condensate everything, I admit I probably got wrong. Thank you for fixing that.

I personally believe The Cell is stream (being able to route data between the SPEs seems quite like a GPU pipeline to me) but I never searched proof of it.

I understand the update stuff applies to The Cell. I don't think I'm the best to update it. What should be noted?

Are there other points I did not touch in my reply?

Anyway, I mark this in my todo list.

MaxDZ8 talk 07:18, 12 June 2006 (UTC)

[edit] Acronyms

Can someone create the proper wikilinks for DMA and DSP? I'm not sure what the article is talking about. ··gracefool |☺ 03:16, 2 October 2006 (UTC)

Done. Note that both DMA and DSP are being using slightly differently than expected. DMA means the CPU can access (usually by mapping) memory somewhere not in RAM. The term is also used to say "asincronously move data", which happens thuru the 'DMA puller'. "DSP" is used to identify chips used for DSP.
MaxDZ8 talk 07:03, 13 October 2006 (UTC)

[edit] Discussion note

Note for discussion on User:WipEout! additions: this is being discussed on my talk page.
MaxDZ8 talk 07:03, 13 October 2006 (UTC)

[edit] Definition of uniform streaming

The term "uniform streaming" is used early in the article but never formally defined. Are there non-uniform models of streaming? Seems like this is a pretty fundamental issue. /KS

[edit] Merging with GPGPU

The entries for "Stream Processor" and "GPGPU" should remain distinct. These two entries are related and should have links to one another. However, there is enough distinct material in each entry to make merging them a bad idea. There are many stream processors, including the original Imagine Stream Processor, that are not GPUs. Also, while a "Stream Processor" is a device, "GPGPU" refers not to a device (the GPU) but rather to a use of the device - for applications other than polygon rendering. While modern GPUs use "stream processors" for their shaders, they also have a considerable amount of specialized logic for textures and compositing - hence these GPUs use stream processors, but are not themselves stream processors. BillDally 18:13, 20 November 2006 (UTC)

I concur. —Disavian (^talk/_contribs) 20:30, 20 November 2006 (UTC)

I agree there is not enugh inforamtion for the 2 to be merged. I sugest keeping them seprate.Tokyo Michael 18:18, 15 December 2006 (UTC)

Conditionally Endorse/Modify merge strategy. The original intent behind the merge was not to reduce or remove the distinction between GPGPU and Stream processing, but to eliminate a duplication in the pedia. The title of this article is not "stream processor" but "stream processing" - which is a technique by which SIMD/Vector/MIMD datasets are executed extremely rapidly (as compared with a more conventional FPU). GPGPU is an application of an existing technology - not a completely new one. The application of GPGPU as it refers to GPU's is a concept, but one that clearly, I believe, falls under the purview of this article or GPU. The technical aspects of GPGPU, I believe fall predominantly under the scope of Stream Processing, whereas the apllication (conceptually) falls under the scope of GPU. While GPGPU is a complicated and interesting article, I do not believe the "beauty" of a thing should immediately require its salvation of merge/modify/delete. Good discussion. Sahrin 02:11, 24 November 2006 (UTC)

[edit] AMD introduced a stream processor

See [1]. maybe this new stream processor should be mentioned in the article. -80.108.234.164 02:26, 2 December 2006 (UTC)

I'm not sure. It's rumored to be a beefed up R5xx. The fact it comes from the "graphics group" (ATi) is in fact confirming this...
MaxDZ8 talk 18:10, 2 December 2006 (UTC)

[edit] Merge with "stream programming"?

I started an article on "stream programming" because I could not find an appropriate place to put the information in the "stream processing" article. If an editor more familiar with the latter article knows of a good location, feel free to copy the information over. But please, if nothing else, have "stream programming" redirect to "stream processing" as there are number of Google searches for the former. Hpcanswers 07:53, 18 January 2007 (UTC)

[edit] Misleading Comparisons

I find all of the comparisons between general purpose CPU's and the streaming processors to be EXTREMELY misleading. One of the greatest challenges of general purpose processors is trying to find parallelism while enduring unknown program flow. On average a given program will execute a branch once every 5 instructions (20%). The point of a streaming processor is that there IS NO program flow issues, so it can dedicate all of its hardware to executing back to back instructions as quickly as possible. Comparing the number of operations a pentium can perform compared to a GPU makes no sense, since they have entirely different purposes. A corvette can drive faster than a hummer - so what? Quanticles 02:29, 26 January 2007 (UTC)

[edit] Disambiguate with Event Stream Processing?

"Stream Processing" is a pretty general term, and it looks like multiple marketing departments are trying to coopt/create it. Along with the suggestions of merging this quite technical article about one kind of stream processing (using GPUs or other vector chips with stream-oriented algorithms), I think disambiguation is in order. In particular, this usage gets conflated with Event Stream Processing. I suggest replacing this page with a disambiguation page after merging the content.

--Tibbetts2c 21:16, 16 March 2007 (UTC)