This is the
talk page for discussing improvements to the
Stream processing article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||
|
![]() | This article may be too technical for most readers to understand.(September 2010) |
- give a lay person a general idea of the intent of the article - to better define the principles of stream processing -- Define kernel in the context of stream processing. The general article on mathematical kernels (appropriately) gives several definitions. - to include stream programming directly, rather than a separate article - to cut down on the prior paradigms (referenced instead of being explicit and taking up more than half the article) - to be more expansive regarding the implementations (while removing marketing jargon) - to give better references to technical papers. 71.202.140.192 ( talk) 07:43, 29 November 2007 (UTC)rickyrazz this is what I want for Christmas :-)
Swapped out the 'stream processing considerations' section for a structured discussion surrounding 'software' and 'hardware' considerations. Still need to address the 'prior paradigms' section but will save for another day. Cheers! Rickyrazz ( talk) 23:49, 24 December 2007 (UTC)rickyrazz |
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:
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.
For readers not experienced with C, the '*' before each identifier means 'array'. For Java programmers, this is roughly equivalent to "[]".
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.
Last edits are really interesting! Thank you! MaxDZ8 20:34, 4 January 2006 (UTC)
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)
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)
MaxDZ8 talk 07:18, 12 June 2006 (UTC)
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)
Note for discussion on
User:WipEout! additions: this is being discussed on my talk page.
MaxDZ8
talk
07:03, 13 October 2006 (UTC)
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
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 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)
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)
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)
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)
"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)
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)
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)
It happens I have a bit of time right now to have a quick glance at what happened in the last few days.
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)
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)
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)
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)
Minor edit, kept.
MaxDZ8
talk
14:05, 27 December 2007 (UTC)
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)
Minor edit, kept.
MaxDZ8
talk
14:05, 27 December 2007 (UTC)
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)
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)
Thank you for your continued effort. I am now checking out again the edits in the last few days.
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.
This is the
talk page for discussing improvements to the
Stream processing article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||
|
![]() | This article may be too technical for most readers to understand.(September 2010) |
- give a lay person a general idea of the intent of the article - to better define the principles of stream processing -- Define kernel in the context of stream processing. The general article on mathematical kernels (appropriately) gives several definitions. - to include stream programming directly, rather than a separate article - to cut down on the prior paradigms (referenced instead of being explicit and taking up more than half the article) - to be more expansive regarding the implementations (while removing marketing jargon) - to give better references to technical papers. 71.202.140.192 ( talk) 07:43, 29 November 2007 (UTC)rickyrazz this is what I want for Christmas :-)
Swapped out the 'stream processing considerations' section for a structured discussion surrounding 'software' and 'hardware' considerations. Still need to address the 'prior paradigms' section but will save for another day. Cheers! Rickyrazz ( talk) 23:49, 24 December 2007 (UTC)rickyrazz |
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:
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.
For readers not experienced with C, the '*' before each identifier means 'array'. For Java programmers, this is roughly equivalent to "[]".
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.
Last edits are really interesting! Thank you! MaxDZ8 20:34, 4 January 2006 (UTC)
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)
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)
MaxDZ8 talk 07:18, 12 June 2006 (UTC)
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)
Note for discussion on
User:WipEout! additions: this is being discussed on my talk page.
MaxDZ8
talk
07:03, 13 October 2006 (UTC)
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
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 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)
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)
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)
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)
"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)
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)
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)
It happens I have a bit of time right now to have a quick glance at what happened in the last few days.
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)
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)
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)
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)
Minor edit, kept.
MaxDZ8
talk
14:05, 27 December 2007 (UTC)
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)
Minor edit, kept.
MaxDZ8
talk
14:05, 27 December 2007 (UTC)
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)
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)
Thank you for your continued effort. I am now checking out again the edits in the last few days.
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.