Talk:Stream processing

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)

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)

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)

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)

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)

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

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)

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)

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)

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)

The examples comparing "Conventional, sequential paradigm" and "Parallel SIMD paradigm, packed registers (SWAR)" are not contrasting at all. The only difference is syntax. It looks wrong, not just misleading. Marius63 (talk) 10:50, 26 August 2013 (UTC)

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)

I concur with the comment from Tibbetts2c. "Stream Processing" is becoming broadly analagous with Event Stream Processing and Complex Event processing by vendors including StreamBase, Aleri, Coral8, and others. How can this be disambiguated?

whobbib 03:56, 12 August 2007 (UTC)

The only thing I can say is that doing something is better than leaving this as it is and continue wondering how it can be done. I encurage everybody in being bold! It's your right on the wiki! I would already do that, but I feel better leaving this to somebody who knows what the other term means.
Personally I would consider a see-also entry. This name is shorter to write.
MaxDZ8 talk 12:43, 18 August 2007 (UTC)

Need to start out the first paragraph with an explanation of what we're talking about for GENERAL readers

This article obviously has a lot of problems, but one which has not been discussed yet is its incomprehensibility for general readers. Encyclopedia articles need to at least start with an explanation of the topic which is comprehensible to any reasonably intelligent general reader. That's a test this article fails. jackbrown —Preceding comment was added at 10:59, 8 November 2007 (UTC)

If the first paragraph isn't easy enough, I suppose it needs more wikilinking.
MaxDZ8 talk 08:20, 12 November 2007 (UTC)

Take a look at RISC for a good example how to organize

RISC is a great analogy of a concurrent development project which combined both a programming model (reducing op codes in this case) and hardware embodied in silicon. In other words, each started with a software view and build hardware to adapt. I propose we adopt the organizational structure of that article and build from there. I would also propose to blow away the whole section regarding Comparison to prior parallel paradigms as it is quite disjointed and include those "paradigms" by reference. If OK, I can rebuild over the weekend. 71.202.140.192 (talk) 05:35, 21 November 2007 (UTC)rickyrazz

I am unsure whatever it makes sense to do that right now, I don't think there's enough material to support a similar structure and probably will never be. Reorganizing the "comparison" section is absolutely a good idea (the whole thing needs some extra attention in general) but I don't support the idea of removing it completely.
MaxDZ8 talk 13:26, 22 November 2007 (UTC)

Rewriting comment

It happens I have a bit of time right now to have a quick glance at what happened in the last few days.

• About the 05:01, 18 December 2007 revision.

The thing that bothers me most here is the way the GPU statement has changed. I am removing the line breaks and restoring the previous statement which seemed better. Note: this was inferred from the AT&T document. I am also restoring the previous stub on G8x, the '8800' is the card name. I believe it's way better instead to cite the chip family since it's the only real component delivering the HW features in a consistent manner. Replacing a stub with another stub doesn't seem to be much useful so I'm keeping the previous one. I also strip away the note on the AMD/ATi merger. Market events don't really change the fact it isn't a valuable milestone. By the way, the double precision is very likely emulated (just as it was on 80386 when the FP unit wasn't there).
MaxDZ8 talk 13:57, 20 December 2007 (UTC)

• About the 05:09, 18 December 2007 revision.

Adding that all shading languages could be considered stream languages up to a certain degree and removing the stuff on multi-architecture compiler support (it doesn't seem so generic).
MaxDZ8 talk 13:57, 20 December 2007 (UTC)

• About the 05:37, 18 December 2007 revision.

I'm restoring part of the paragraph "The basic concept ... such as cache memories and DMA.", to the previous state. The information here was extracted from the references, which used a very specific terminology and contains very valuable contributions from a few users. Dropping all this information seems a bit too bold. ;) I'm also commenting out the example section, which needs a bit of rewording (since I'm running out of time, I'll pull discussion to another day here). Some of the things here are questionable at best.
MaxDZ8 talk 13:57, 20 December 2007 (UTC)

• About the 09:47, 20 December 2007 revision.

Ok. There's something which still scares me a bit. While all this detail on Imagine wasn't really meant to be there, I wonder if it has been just deleted or moved to another page: there doesn't seem to be any Imagine processor on the disambiguation page...
MaxDZ8 talk 13:57, 20 December 2007 (UTC)

• Revision as of 10:17, 21 December 2007

Minor edit, kept.
MaxDZ8 talk 14:05, 27 December 2007 (UTC)

• Revision as of 01:15, 25 December 2007

This seems to lose way too much detail. What it is not lost is basically a copyedit. There are multiple issues here to be discussed. For first, removing AoS VS SoA doesn't seem to be a wise move considering this is what killed CPU SIMD. Also pretending to load a "file" as "inputfile1.txt" doesn't seem to be an happy line of thinking (there's not a single architecture allowing something even remotely like it at low-level besides, maybe IBM's big iron). The resulting example doesn't seem to be better than the previous in my humble opinion. This has some nice ideas I would like to isolate here before embedding in the real page.
MaxDZ8 talk 14:05, 27 December 2007 (UTC)

• Revision as of 01:29, 25 December 2007

Minor edit, kept.
MaxDZ8 talk 14:05, 27 December 2007 (UTC)

• Revision as of 01:46, 25 December 2007

Wikilinks DSP, but was already linked previously. Also corrects a typo. NOTE: wiki style suggest to link only the first occurance of the word.
MaxDZ8 talk 14:05, 27 December 2007 (UTC)

• Revision as of 08:58, 25 December 2007 and Current revision (09:00, 25 December 2007)

Minor edit made of wikilinking... it's just easier to redo this later.
MaxDZ8 talk 14:05, 27 December 2007 (UTC)

Summing up: I'm confident we could reach an improvement on current version by discussing it here before going in the wild. Thank you!
MaxDZ8 talk 14:05, 27 December 2007 (UTC)

Another edit run

Thank you for your continued effort. I am now checking out again the edits in the last few days.

• 01:26, 29 December 2007: copyedit of various notes on the systolic array technology. Kept.
• 07:40, 8 January 2008: tries to reduce complexity and removes a few statements. Good in principle, but debatable in implementation. It is also unclear what exactly is intended to be false, how and under what assumptions. I'm keeping the previous version, I would expect to discuss this on talk page before going in the wild. Not kept.
  

  Takes away a whole paragraph because of "new information available in the last two years". Again, good in principle but to be discussed, it would be ideal to discuss at least those new infos. Not kept.
  Adds a confusing tag on the hardware in the loop issues. Those problems have been pointed out in a linked reference so it seems reasonable they should be covered here and maybe on other pages as well. The current wording isn't exactly the state of the art however. Kept.

• 08:12, 8 January 2008: this is a quite difficult to follow edit which seems to be based on compressing the previous 'applications' paragraph and then adding back detail... It has to be discussed if this is an improvement so I'm being bold as well and restoring previous version. Not kept.
• 08:14, 8 January 2008; 08:16, 8 January 2008; 08:17, 8 January 2008; 08:20, 8 January 2008: those three just reshuffle the various entries in alphabetical order. Kept.
• 15:36, 8 January 2008: adds a link. Kept.
• 02:24, 10 January 2008: fixed a typo. Kept.
• 07:50, 11 January 2008: wikilinks C, fixes a typo and removes an implicit repetition. Kept.
• 07:59, 11 January 2008: comments out various info... It has to be noted that while the jargon may be imagine-specific, this architecture applies to other processors as well by just renaming a few key components. The previous jargon were used in the references as well. Not kept.

MaxDZ8 talk 16:46, 11 January 2008 (UTC)