Seems to me that the biggest factor to differentiate the prop is it's parallelism. However, the only common use of this seems to be 'no interrupts'.
While there are many examples of things occurring asynchronously in several cores, I haven't noticed many that take advantage of coordinated, distributed parallel processing.
I imagine that this is because most folks have only done sequential processing, and aren't familiar with parallel processing (like me).
So that doesn't seem to be anything that points out (to non prop users) how have eight cores is all that much better than having eight separate uC, and most applications don't need eight separate uC anyway. Folks just don't know how to use that kind of a tool.
Perhaps an app that shows the effectiveness of parallel processing over sequential processing might attract engineers to investigate the prop?
Is anybody else playing with parallel processing?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There are 10 types of people in the world: those who understand binary, and those who don't
When the transputer first appeared, I remember David May mentioning that hardware engineers took to the parallel-processing paradigm much more readily than software people. That probably applies to Propeller users today.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
prof_braino said...
Seems to me that the biggest factor to differentiate the prop is it's parallelism. However, the only common use of this seems to be 'no interrupts'.
Even if that were the only advantage, it would be a huge one. Prioritizing is gone. Making sure your ISR can handle all the interrupts that come in and dispatch them in a timely fashion: also gone. Interrupt structures were designed into computers to simulate parallelism. But, with the Propeller, you have the real deal; and it's so much easier to program that way. Hence, design time is slashed, and changes are easier to incorporate without tugging at a house of cards, since event handlers are isolated from each other.
The transputer was quite successful, ST continued using the core deeply embedded in high-performance devices for the video market for many years. I made a lot of money developing and selling transputer systems at the time. One of them with 16 modules was used by Plessey Roke Manor for a unique fault-tolerant system - customers were told to pull out two or three boards at random, and the system would carry on running with only slightly reduced performance. Firewire actually uses the same technology that Inmos used in their transputer links, 24 years ago. Many of the concepts pioneered by Inmos are used today in the XMOS chips.
I don't see why David May's statement about hardware engineers understanding parallel processing shouldn't be just as applicable today. Hardware is inherently parallel, unlike conventional software.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Because its just nonsense, that's why. Are you next going to claim that women "inherently" understand parallelism better than men? My wife is always telling me that men are lousy at multi-tasking. Surely this would mean women make better engineers?
Ross.
P.S. This is soooo off-topic. I should know better than to rise to the bait - apologies to Cluso99!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Carpe Ducktum" "seize the tape!!" peterthethinker.com/tesla/Venom/Venom.html
Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway. —Tanenbaum, Andrew S.
LOL
Because its just nonsense, that's why. Are you next going to claim that women "inherently" understand parallelism better than men? My wife is always telling me that men are lousy at multi-tasking. Surely this would mean women make better engineers?
Ross.
P.S. This is soooo off-topic. I should know better than to rise to the bait - apologies to Cluso99!
I think that David would have known who was best equipped to apply parallel processing techniques, with his having taught many hardware and software engineers the subject over the years:
I'm sure David May is a truly fantastic person and a talented hardware designer - but even you would have to acknowledge that the Transputer was an unmitigated commercial disaster, and as a computer language Occam is not doing so well these days either (this is not my opinion - check the the TIOBE index. Occam ranks behind even such things as MSDOS batch scripting).
So I think I'm fairly justified in claiming that David May's opinions on issues outside his specialist domain of hardware design would have to be regarded at the very least as a little suspect.
Leon, we all know your particular obsession with [noparse][[/noparse]the company that dared not speak its name]. I just hadn't realized it extends to their personel as well as their silicon.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Actually I get the idea David May is more of a software guy. What with designing/implementing languages and such. He's just always wanted to get hardware to do what he wants efficiently. Down to designing the instruction sets of the machines.
Yep, the Transputer was a commercial flop. Like so many other developments from my home island. I've said it here before but launching the Transputer with Occam as the primary language was something of a bad idea. As we have discussed endlessly here about the need for C on the Prop. C is what the world want's good or bad. Occam was just too much to deal with.
David himself has talked about his learning from that experience and that is why the new chips-that-cannot-be-mentioned have C and C++ from the get go along with a variant of C built for parallelism
Occam is doing very well thank you. Did you know that you can now run Occam programs on AVR's now a days. Yep you can run Occam on Arduimo and Lego MindStorms via the "transterpreter" virtual machine. Thanks to the ongoing work of the guys at my old university. projects.cs.kent.ac.uk/projects/kroc/trac/wiki
As for the regard in which we should hold David May's opinions, they are up there with those of Linus Torvals, Richard Stallman, Donald Knuth, and all the other heroes of the computer world in our time.
Well, any CEO of a company like that who has the time to chat with me on the forum over the Christmas break get's my attention and us Brits have to wave our little flags sometimes[noparse]:)[/noparse]
There are a lot of parallels (pun intended) between Parallax/Chip Gracey/Propeller and XMOS/David May/Xcore in this context, going out on a limb to do something different, doing things the way they want to do it, not just what every one else is doing.
I say they both deserve listening to. Nothing "suspect" at all.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, he's more of a software person. He is also a very good hardware engineer, though.
Parallel versions of C and Fortran were available for the transputer. Occam had the advantage that programs could be shown to be correct, in a mathematical sense. A version of it was used for designing the transputer hardware. The chip worked first time, which was rather unusual in those days. It's probably unusual today.
Having been at Kent you must know Peter Welch. He was heavily involved with the transputer. I had a chat with him at a seminar for the-chip-that-must-not-be-named a couple of years ago.
I don't know David but I've helped one of his sons out with a hardware interface problem, and made a little PCB for him.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
RossH said...
So I think I'm fairly justified in claiming that David May's opinions on issues outside his specialist domain of hardware design would have to be regarded at the very least as a little suspect.
Actually that quote really stings. No, you are not justified at all. No, his specialist domain is not the point and no, there is nothing "suspect" about his opinions.
Here's why:
In David May's mind there is no distinction between software and hardware. When it comes down to the pure logic of whatever you are trying to do software and hardware are equivalent. I'm sure you will agree with that. Having a dumb CPU and memory and a program as we have now a days is one way to implement a solution to any given problem. Having an huge infinitely configurable amount of logic available would be another way to build a solution to the same logical problem. No "program" as we know it required, just a configuration of logic circuits.
Anyone can see this when you think of performing floating point in software, like on a Prop, or in hardware like in your PC's processor. One is a program the other is a bunch of gates.
As it happens we don't have that hardware capability except in some limited sense in FPGA's and such.
That "software specialization" as mostly know today is just a way of dealing with the limited Von Newman style hardware we have. It is a subset of the world where David May and the CSP guys have been living for thirty years.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Leon, I came out of the University of Kent at Canterbury in 1977, before there was a Transputer. As I was studying Physics I did not mix with the computer guys so much. Well except when the admin guys would reprimand me for hogging the the pen plotter on the ICL 2960 for so long with my ALGOL 68 experiments[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I bow to your superior knowledge of David May and his various achievements. That still doesn't make his opinion (as conveyed by Leon) that hardware engineers understand parallelism better than software engineers any more sensible. It certainly can't be justified based on the evidence of the Transputer or Occam. In fact, all the anecdotal evidence you quoted would seem to indicate just the opposite.
It is tenable to argue that hardware engineers have more affinity to the Occam approach to parallelism than software engineers. Given it's hardware origins, there's nothing surprising in that. It's just that (outside a few niche applications) this particular approach hasn't turned out to be a great deal of use - it still has some utility at the theoretic and academic level (which is mainly where it survives) but not much at the application level. On the other hand, purely software approaches to parallelism have had a great deal of success - as evidenced by the number of operating systems and languages that add concurrency entirely at the software level, and then proceed to do useful things with it.
I certainly wouldn't claim on this basis that software engineers have a better understanding of parallelism than hardware engineers - but I would be at least as justified in doing so as Leon (or David May) is in claiming the contrary.
However, I do agree that David May's current approach - using a variant of C on the chip-that-dares-not-speak-its-name has a far higher likelihood of success.
Ross.
P.S. Apologies again for getting so OT - I just can't let such nonsense go unchallenged
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
David May's statement is similar to one a boss of mine made to me once, he said that all his best software engineers had a hardware background. They were both speaking from many years of experience.
Occam doesn't have any hardware origins, it's based on Tony Hoare's CSP:
I normally shy away from these speculative marketing threads, but I couldn't resist any longer.· If I were to select a part for an engineering project·that fits within the Prop's·product niche, it would have the following requirements:
- Optimized C compiler
- Video generator
- Support 1024x768 24-bit graphics
- Support 1080p
- HDMI input and output
- DMA
- High-speed instruction and data cacheing
- Serial port
- SD card interface
- Single cycle multiply
- Glueless interface to DDR memory
- Low cost
The Prop I support·5 of these items.· The Prop II will support 7 of these items.
I can quote wikipedia too. Your continual appeals to increasingly higher authority (en.wikipedia.org/wiki/Argument_from_authority) just shows how groundless your original assertion was. Are you going to claim divine inspiration next?
I could just as easily say that in my many years of software experience some of the worst software I've ever had to deal with was written by hardware engineers - it was. But I stop short of making silly assertions such as "this obviously means hardware engineers are inherently worse at software than software engineers".
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
jazzed said...
>> Is anybody else playing with parallel processing? Almost anyone who uses video with Propeller is experiencing parallel processing. Now, if you mean symmetric multi-processing, that has not been fully exploited. --Steve
Sorry, I meant is anyone investigating symmetric multiprocessing and/or coordinated, distributed parallel processing aside from humanoido?
@RossH:
Leon said...
...David May mentioning that hardware engineers took to the parallel-processing paradigm much more readily than software people...
RossH said...
@Leon,
Because its just nonsense, that's why. Are you next going to claim that women "inherently" understand parallelism better than men? My wife is always telling me that men are lousy at multi-tasking. Surely this would mean women make better engineers?
Ross.
P.S. This is soooo off-topic. I should know better than to rise to the bait - apologies to Cluso99!
Are you saying that the system-view hardware engineers take when designing hardware versus the linear sequential programming view that software engineers tend to use is somehow related to biological differences between male and female? This sounds like trolling, normally you have very useful and informative posts. Don't we confirm May's statement by observation when we look at current software?
This should NOT be categorically dismissed as off-topic. Symmetric multiprocessing / coordinated, distributed parallel processing is the future. The only question is when this future be the present? I postulate the prop can play a factor in making it sooner.
Some folks look at the short term, and some look at the long term. One does not invalidate the other. Consider an open mind when one discusses the different approach. The academic research of today may have been a commercial disaster yesterday, but it leads to the kitchen appliance of tomorrow.
Sorry to go on, but I really think this point should at least be discussed. The existing spec of parallel processing within a single chip can be a enticing factor if shown to be useful in an engineering design. Symmetric multiprocessing / coordinated, distributed parallel processing has not been widely developed as a general technique for the prop, and is potential equally useful as parallel asynchronous function. AND its just plain cool.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There are 10 types of people in the world: those who understand binary, and those who don't
Post Edited (prof_braino) : 7/20/2010 5:28:09 PM GMT
prof_braino said...
Sorry, I meant is anyone investigating symmetric multiprocessing and/or coordinated, distributed parallel processing aside from humanoido?
On the test forum????
So you mean chip to chip interface? Anyone can buy chips/boards and stack 'em up.
Several methods of software interface between chips have been implemented by forum members.
RossH: you seem to really seperate hardware engineer and software engineer, but really, how different are they? The tools are different, the medium is different, but the methods of implimenting are very similar...
Maybe if you picked a "software engineer" that only did VisualBasic or Javascript (I would argue that they are not engineers, but anyway), and a hardware engineer that just worked in analog circuits...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
I think we should leave David May out of this. It's not his fault and he's not here to confirm or refute anything.
Just for fun I'd like to apply some anecdotal logic[noparse]:)[/noparse]
Anecdote:
Back in the depths of time when Heater was young and hot he had an old flame (get it "Heater", "flame" [noparse]:)[/noparse]). She was a student of English Literature, French and Drama. Sadly it would seem she was not much good at any of that, failed the relevant examinations twice and end up working in a Pizza factory for a year or so.
One day she found she found the young Heater, soldering iron in hand, putting together a SBC with a 6809 microprocessor on it. Curiously she asked "what on earth is that?". For even most geeks had never seen a micro-processor at that time.
Patiently, over many weeks, Heater explained to her about, binary numbers, hexadecimal, bits, bytes, words, memory, instructions, programs. In Hex, the young Heater had no assembler or any machine to run one on. She was enthralled.
Inspired, the flame quit the Pizza factory, and started studying maths, economics and computer studies at the local tech college. Subsequently earned a degree in Mathematics and on graduating became a star software engineer for a start up company in Germany.
The young Heater was heart broken as he was left all alone in England[noparse]:([/noparse]
Conclusion:
By applying the well known "proof by anecdote" method we can see that the best software engineers are:
a) Female.
b) Failed Humanities students.
and further that:
c) You should NEVER let your girlfriends near your micro-computers.
[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
prof_braino said...
Sorry, I meant is anyone investigating symmetric multiprocessing and/or coordinated, distributed parallel processing aside from humanoido?
jazzed said...
On the test forum????
The parallel machine is a work in progress - being tested. What better place to post than the test forum. [noparse]:)[/noparse]
Actually it was a new avatar test but one thing led to another. When the parallel machine has completed schematics and code in final form, it can be transferred to the completed project section. But this is an ongoing project so we will see what happens. So jazzed, do you always read the test forum? [noparse];)[/noparse]
Roy Eltham said...
Dave Hein: Prop II will do 1080p, Chip mentioned this at UPEW. It could also do 1024x768x24bit graphics with external memory.
That will be great if the Prop II can do 1080p.· Clearly, both 1080p and 1024x768x24bits will require external memory.· My understanding is that the Prop II will have a glueless DDR memory interface.· I don't know any details about memory interface, but it would need to be driven by the video generator, and it would have to have a bandwidth of at least·186 Mbytes/second for 1080p30.· It would need twice that bandwidth for 1080p60.· That's assuming RGB.· If it does·4:2:2 YCrCb the rate would be two-thirds of that.
Conventional software is limited by what we can do with CPU's and memory at this time.
Basically it is an exercise in getting the best out of a Von Neumann architecture. That is: a single dinky CPU, a huge area of RAM and a tiny little hole through which the CPU can access the memory. The famous "Von Neumann bottleneck".
Pretty much all of common computing is predicated on working in with that constraint. It's like spending years studying how to paint the inside of a huge auditorium with a paint brush stuck through the key hole in the front door.
With the few CPUs that we have in multi-core or other parallel systems we have today the landscape does not change much.
On a normal computer to day, many processes fight for the use of a single or few CPU's and they fight for a slice of memory as well. So a process written in C might grab a megabyte or a gigabyte of RAM with a simple call to "malloc". Then it can do whatever it likes with that RAM and call "free" when it no longer needs it. Then another process uses that same RAM again.
How would it me if we had computers with thousands, millions, gigas of CPUs?
How would we Program that?. I'd love to see a "palloc(1000000)" that would get me a million processors out of the pool which I could then set on whatever code I like.
Having got them, I don't want to have to worry about how to route messages to them. It will have to be "message through channel" based as no way are millions of processors going to share the same RAM. Hardware should take care of that routing from processor to processor as it does routing data from CPU to memory and peripherals without me having to know about it in the machines of today.
That is the future the CSP fraternity have been contemplating for many decades now. And that is why CSP seems to be only an "academic" exercise.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
While there are many examples of things occurring asynchronously in several cores, I haven't noticed many that take advantage of coordinated, distributed parallel processing.
I imagine that this is because most folks have only done sequential processing, and aren't familiar with parallel processing (like me).
So that doesn't seem to be anything that points out (to non prop users) how have eight cores is all that much better than having eight separate uC, and most applications don't need eight separate uC anyway. Folks just don't know how to use that kind of a tool.
Perhaps an app that shows the effectiveness of parallel processing over sequential processing might attract engineers to investigate the prop?
Is anybody else playing with parallel processing?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There are 10 types of people in the world: those who understand binary, and those who don't
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Yes, that explains why the Transputer was so successful.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
-Phil
I don't see why David May's statement about hardware engineers understanding parallel processing shouldn't be just as applicable today. Hardware is inherently parallel, unlike conventional software.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 7/20/2010 1:43:00 AM GMT
Because its just nonsense, that's why. Are you next going to claim that women "inherently" understand parallelism better than men? My wife is always telling me that men are lousy at multi-tasking. Surely this would mean women make better engineers?
Ross.
P.S. This is soooo off-topic. I should know better than to rise to the bait - apologies to Cluso99!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Aww I love the Icon .
Peter KG6LSE
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Carpe Ducktum" "seize the tape!!"
peterthethinker.com/tesla/Venom/Venom.html
Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway. —Tanenbaum, Andrew S.
LOL
Almost anyone who uses video with Propeller is experiencing parallel processing.
Now, if you mean symmetric multi-processing, that has not been fully exploited.
Cheers.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Green Cheese Inside - will definitely entice design engineers to investigate the prop.
Is anybody else playing with parallel processing?
Yes.
http://forums.parallax.com/showthread.php?p=921524
I think that David would have known who was best equipped to apply parallel processing techniques, with his having taught many hardware and software engineers the subject over the years:
en.wikipedia.org/wiki/David_May_%28computer_scientist%29
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 7/20/2010 8:27:19 AM GMT
I'm sure David May is a truly fantastic person and a talented hardware designer - but even you would have to acknowledge that the Transputer was an unmitigated commercial disaster, and as a computer language Occam is not doing so well these days either (this is not my opinion - check the the TIOBE index. Occam ranks behind even such things as MSDOS batch scripting).
So I think I'm fairly justified in claiming that David May's opinions on issues outside his specialist domain of hardware design would have to be regarded at the very least as a little suspect.
Leon, we all know your particular obsession with [noparse][[/noparse]the company that dared not speak its name]. I just hadn't realized it extends to their personel as well as their silicon.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Actually I get the idea David May is more of a software guy. What with designing/implementing languages and such. He's just always wanted to get hardware to do what he wants efficiently. Down to designing the instruction sets of the machines.
Yep, the Transputer was a commercial flop. Like so many other developments from my home island. I've said it here before but launching the Transputer with Occam as the primary language was something of a bad idea. As we have discussed endlessly here about the need for C on the Prop. C is what the world want's good or bad. Occam was just too much to deal with.
David himself has talked about his learning from that experience and that is why the new chips-that-cannot-be-mentioned have C and C++ from the get go along with a variant of C built for parallelism
Occam is doing very well thank you. Did you know that you can now run Occam programs on AVR's now a days. Yep you can run Occam on Arduimo and Lego MindStorms via the "transterpreter" virtual machine. Thanks to the ongoing work of the guys at my old university. projects.cs.kent.ac.uk/projects/kroc/trac/wiki
As for the regard in which we should hold David May's opinions, they are up there with those of Linus Torvals, Richard Stallman, Donald Knuth, and all the other heroes of the computer world in our time.
Well, any CEO of a company like that who has the time to chat with me on the forum over the Christmas break get's my attention and us Brits have to wave our little flags sometimes[noparse]:)[/noparse]
There are a lot of parallels (pun intended) between Parallax/Chip Gracey/Propeller and XMOS/David May/Xcore in this context, going out on a limb to do something different, doing things the way they want to do it, not just what every one else is doing.
I say they both deserve listening to. Nothing "suspect" at all.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Parallel versions of C and Fortran were available for the transputer. Occam had the advantage that programs could be shown to be correct, in a mathematical sense. A version of it was used for designing the transputer hardware. The chip worked first time, which was rather unusual in those days. It's probably unusual today.
Having been at Kent you must know Peter Welch. He was heavily involved with the transputer. I had a chat with him at a seminar for the-chip-that-must-not-be-named a couple of years ago.
I don't know David but I've helped one of his sons out with a hardware interface problem, and made a little PCB for him.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 7/20/2010 11:27:01 AM GMT
Actually that quote really stings. No, you are not justified at all. No, his specialist domain is not the point and no, there is nothing "suspect" about his opinions.
Here's why:
In David May's mind there is no distinction between software and hardware. When it comes down to the pure logic of whatever you are trying to do software and hardware are equivalent. I'm sure you will agree with that. Having a dumb CPU and memory and a program as we have now a days is one way to implement a solution to any given problem. Having an huge infinitely configurable amount of logic available would be another way to build a solution to the same logical problem. No "program" as we know it required, just a configuration of logic circuits.
Anyone can see this when you think of performing floating point in software, like on a Prop, or in hardware like in your PC's processor. One is a program the other is a bunch of gates.
As it happens we don't have that hardware capability except in some limited sense in FPGA's and such.
That "software specialization" as mostly know today is just a way of dealing with the limited Von Newman style hardware we have. It is a subset of the world where David May and the CSP guys have been living for thirty years.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I bow to your superior knowledge of David May and his various achievements. That still doesn't make his opinion (as conveyed by Leon) that hardware engineers understand parallelism better than software engineers any more sensible. It certainly can't be justified based on the evidence of the Transputer or Occam. In fact, all the anecdotal evidence you quoted would seem to indicate just the opposite.
It is tenable to argue that hardware engineers have more affinity to the Occam approach to parallelism than software engineers. Given it's hardware origins, there's nothing surprising in that. It's just that (outside a few niche applications) this particular approach hasn't turned out to be a great deal of use - it still has some utility at the theoretic and academic level (which is mainly where it survives) but not much at the application level. On the other hand, purely software approaches to parallelism have had a great deal of success - as evidenced by the number of operating systems and languages that add concurrency entirely at the software level, and then proceed to do useful things with it.
I certainly wouldn't claim on this basis that software engineers have a better understanding of parallelism than hardware engineers - but I would be at least as justified in doing so as Leon (or David May) is in claiming the contrary.
However, I do agree that David May's current approach - using a variant of C on the chip-that-dares-not-speak-its-name has a far higher likelihood of success.
Ross.
P.S. Apologies again for getting so OT - I just can't let such nonsense go unchallenged
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Occam doesn't have any hardware origins, it's based on Tony Hoare's CSP:
en.wikipedia.org/wiki/C._A._R._Hoare
I see that should be Sir Tony, he's been knighted.
Occam was designed first, and the transputer was designed to execute it it as efficiently as possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 7/20/2010 1:06:46 PM GMT
- Optimized C compiler
- Video generator
- Support 1024x768 24-bit graphics
- Support 1080p
- HDMI input and output
- DMA
- High-speed instruction and data cacheing
- Serial port
- SD card interface
- Single cycle multiply
- Glueless interface to DDR memory
- Low cost
The Prop I support·5 of these items.· The Prop II will support 7 of these items.
Dave
I can quote wikipedia too. Your continual appeals to increasingly higher authority (en.wikipedia.org/wiki/Argument_from_authority) just shows how groundless your original assertion was. Are you going to claim divine inspiration next?
I could just as easily say that in my many years of software experience some of the worst software I've ever had to deal with was written by hardware engineers - it was. But I stop short of making silly assertions such as "this obviously means hardware engineers are inherently worse at software than software engineers".
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Which five and which seven? You really need a matrix.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
- Optimized C compiler
- Video generator
- DMA
- Serial port
- SD card interface
Prop II
- Optimized C compiler
- Video generator
- DMA
- Serial port
- SD card interface
- Single cycle multiply
- Glueless interface to DDR memory
Missing features
- Support 1024x768 24-bit graphics
- Support 1080p
- HDMI input and output
- High-speed instruction and data cacheing
- Low cost
Sorry, I meant is anyone investigating symmetric multiprocessing and/or coordinated, distributed parallel processing aside from humanoido?
@RossH:
Are you saying that the system-view hardware engineers take when designing hardware versus the linear sequential programming view that software engineers tend to use is somehow related to biological differences between male and female? This sounds like trolling, normally you have very useful and informative posts. Don't we confirm May's statement by observation when we look at current software?
This should NOT be categorically dismissed as off-topic. Symmetric multiprocessing / coordinated, distributed parallel processing is the future. The only question is when this future be the present? I postulate the prop can play a factor in making it sooner.
Some folks look at the short term, and some look at the long term. One does not invalidate the other. Consider an open mind when one discusses the different approach. The academic research of today may have been a commercial disaster yesterday, but it leads to the kitchen appliance of tomorrow.
Sorry to go on, but I really think this point should at least be discussed. The existing spec of parallel processing within a single chip can be a enticing factor if shown to be useful in an engineering design. Symmetric multiprocessing / coordinated, distributed parallel processing has not been widely developed as a general technique for the prop, and is potential equally useful as parallel asynchronous function. AND its just plain cool.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There are 10 types of people in the world: those who understand binary, and those who don't
Post Edited (prof_braino) : 7/20/2010 5:28:09 PM GMT
So you mean chip to chip interface? Anyone can buy chips/boards and stack 'em up.
Several methods of software interface between chips have been implemented by forum members.
Cheers.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Maybe if you picked a "software engineer" that only did VisualBasic or Javascript (I would argue that they are not engineers, but anyway), and a hardware engineer that just worked in analog circuits...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Just for fun I'd like to apply some anecdotal logic[noparse]:)[/noparse]
Anecdote:
Back in the depths of time when Heater was young and hot he had an old flame (get it "Heater", "flame" [noparse]:)[/noparse]). She was a student of English Literature, French and Drama. Sadly it would seem she was not much good at any of that, failed the relevant examinations twice and end up working in a Pizza factory for a year or so.
One day she found she found the young Heater, soldering iron in hand, putting together a SBC with a 6809 microprocessor on it. Curiously she asked "what on earth is that?". For even most geeks had never seen a micro-processor at that time.
Patiently, over many weeks, Heater explained to her about, binary numbers, hexadecimal, bits, bytes, words, memory, instructions, programs. In Hex, the young Heater had no assembler or any machine to run one on. She was enthralled.
Inspired, the flame quit the Pizza factory, and started studying maths, economics and computer studies at the local tech college. Subsequently earned a degree in Mathematics and on graduating became a star software engineer for a start up company in Germany.
The young Heater was heart broken as he was left all alone in England[noparse]:([/noparse]
Conclusion:
By applying the well known "proof by anecdote" method we can see that the best software engineers are:
a) Female.
b) Failed Humanities students.
and further that:
c) You should NEVER let your girlfriends near your micro-computers.
[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 7/20/2010 6:30:20 PM GMT
Sorry, I meant is anyone investigating symmetric multiprocessing and/or coordinated, distributed parallel processing aside from humanoido?
jazzed said...
On the test forum????
The parallel machine is a work in progress - being tested. What better place to post than the test forum. [noparse]:)[/noparse]
Actually it was a new avatar test but one thing led to another. When the parallel machine has completed schematics and code in final form, it can be transferred to the completed project section. But this is an ongoing project so we will see what happens. So jazzed, do you always read the test forum? [noparse];)[/noparse]
humanoido
Dave
.... Hardware is inherently parallel, unlike conventional software.
Niklaus Wirth pretty much holds the same view and he's a software guy.
Link:
http://www.inf.ethz.ch/personal/wirth/Articles/Miscellaneous/CounterShifter.pdf
Go to the last page on that document.
Basically it is an exercise in getting the best out of a Von Neumann architecture. That is: a single dinky CPU, a huge area of RAM and a tiny little hole through which the CPU can access the memory. The famous "Von Neumann bottleneck".
Pretty much all of common computing is predicated on working in with that constraint. It's like spending years studying how to paint the inside of a huge auditorium with a paint brush stuck through the key hole in the front door.
With the few CPUs that we have in multi-core or other parallel systems we have today the landscape does not change much.
On a normal computer to day, many processes fight for the use of a single or few CPU's and they fight for a slice of memory as well. So a process written in C might grab a megabyte or a gigabyte of RAM with a simple call to "malloc". Then it can do whatever it likes with that RAM and call "free" when it no longer needs it. Then another process uses that same RAM again.
How would it me if we had computers with thousands, millions, gigas of CPUs?
How would we Program that?. I'd love to see a "palloc(1000000)" that would get me a million processors out of the pool which I could then set on whatever code I like.
Having got them, I don't want to have to worry about how to route messages to them. It will have to be "message through channel" based as no way are millions of processors going to share the same RAM. Hardware should take care of that routing from processor to processor as it does routing data from CPU to memory and peripherals without me having to know about it in the machines of today.
That is the future the CSP fraternity have been contemplating for many decades now. And that is why CSP seems to be only an "academic" exercise.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.