[QUOTE=Heater.;1196451 Which is kind of what we have here. [/QUOTE]
Sorry, No.
Again, this is NOT about the prop 2, or or parallax, or a criticism of Chip's efforts in anyway, or any of the other points you have covered so eloquently.
This is about a need.
The need is for many identical cores, does anyone else have this need? Specifically, does anyone have a use for 16 or 32 identical cores on a single chip? This need has been expressed by individuals in other venues. I want to see if there are any more folks on this forum that feel the same need.
So far the answer continues to be "No". So far no one feels they have grown beyond the number of cores available. This is one of the two valid answers I was looking for.
Asking a question is seldom (approaching never) a waste of time or money. Not asking a question is often (approaching always) a significant waste of time and money.
When you said "Any interest in (more than 8) cog chip" you meant "CPU cores" in general with no connection to the Prop or it's "cogs".
Sorry I was confused because, well, it's confusing:)
After all we are on a specific "Propeller 1" forum here.
OK, now in what context, servers, desktop, phone/pads, micro-controllers...?
I'm going to assume micro-controllers as that is the context of this forum.
Yes. I can see more cores being useful.
For example I have an FFT that will expand easily to fit 2, 4, 8... cores. People have often expressed an interest in having an FFT or similar algorithm on the Propeller. But such things are slow and using extra cores would help. Problem is this sort of thing eats cores and you have none left for other work. So more is better.
There are of course those who run out of COGs to implement all the devices they want. So more is better. But then the P II has threading which will help there if you really need it.
I still think more than 8 sharing HUB might not be so cool though due to HUB bandwidth usage. Perhaps one day the PII can be shrunk to fit two or four on a chip. Each with it's own HUB. Who knows? Lets's see when we get there.
As it stands we are stuck at 8 cores. The only other contender in MCU world is XMOS with 4 core devices with 8 hardware scheduled threads each. Cool. But a bit more expensive and more demanding hardware wise.
There is Green Arrays which seems to be a waste of time by all accounts, no idea really.
(these are mostly just notebook and napkin designs)
1) One of my thoughts along these lines is turning a Propeller into a giant "custom SPI device". The Prop can easily act as an SPI Master with OBEX objects and various code snippets in other languages but I haven't really seen code to allow it to act as an SPI slave. Once you have this, you can just load up a Prop as a slave with all the hardware you need attached to it and the drivers for that hardware and you've just built a custom SPI device. The master Prop can talk to this just like any other SPI device.
2) For the multi-prop setups, I've created the star and daisy chained implementations in PropForth and played with those as far as proof of concept. There still need to be PropForth infrastructure built sp you can just refer to COGs as a contiguous set of usable resources and not need to worry about specifying a Prop# and then a cog# - for example, to reference the 3rd COG on the second Propeller in the cluster, you would just need to call it COG #10 since Prop #0 has COGs 0-7 and Prop #1 has COGs 8-15 in the cluster.
3) For Spin and C, there are multiple ways to communicate between Propellers but what is missing is a common (dare I say standard) way for the next layer in the protocol to be implemented. Whether you look at it for message passing or routing messages. The SPI implementation in #1 above is one version of this. The infrastructure that needs to be built for #2 is another for of these protocol agreements.
Any of the multi-prop solutions that various forum members have come up with all implement some for of this in order to talk between chips, so there are working examples out there.
Again, this is NOT about the prop 2, or or parallax, or a criticism of Chip's efforts in anyway, or any of the other points you have covered so eloquently.
This is about a need.
The need is for many identical cores, does anyone else have this need? Specifically, does anyone have a use for 16 or 32 identical cores on a single chip? This need has been expressed by individuals in other venues. I want to see if there are any more folks on this forum that feel the same need.
So far the answer continues to be "No". So far no one feels they have grown beyond the number of cores available. This is one of the two valid answers I was looking for.
Asking a question is seldom (approaching never) a waste of time or money. Not asking a question is often (approaching always) a significant waste of time and money.
My answer is YES. I NEED more cogs, but I also NEED more hub RAM. My threaded chess program needs more cogs and memory so it can compete against other chess programs, otherwise it will just have to play against lowly humans.
Never mind a master Prop. It would give yo an easy way to connect a Prop to a Raspberry Pi so that you could have massively expanded I/O and other devices to play with from Linux.
Lots of other cheap ARM boards could use this as well.
When you said "Any interest in (more than 8) cog chip" you meant "CPU cores" in general with no connection to the Prop or it's "cogs".
Sorry I was confused because, well, it's confusing:)
After all we are on a specific "Propeller 1" forum here.
Sorry my mistake. AT the time I saw it as related to the 1 cog question. I should have put this in the general forum.
The context started very broad, and included discussion of multiple quad core CPUs in servers, and touched the Green arrays chips, and finally got to microcontrollers.
We were talking about 16 or 32 ARM cores on a chip, or the TI chips, or various other possibilities, and finally Prop cores. The current iteration of Propforth might be able to do something on such an array of cores, but we couldn't find anything that exists already to test it out. And so we guessed that nobody has come to need such a thing.
I figure if the prop community doesn't have a general need for this, its probably best left to the xmas and FPGA guys.
2) ... still need to be PropForth infrastructure built sp you can just refer to COGs as a contiguous set of usable resources and not need to worry about specifying a Prop# and then a cog# ...
This is the interesting thing about PF6 - All the threads are opportunities in a pool. The P1 has 8, the P2 should have 32. At least that's what the design is supposed to be. Whether this works or is easy enough to use remains to be seen. But it seems there are not so many folks that need this ability, so its hard to tell if the way its done lends itself to any given application.
"...refer to COGs as a contiguous set of usable resources"
I don't get the idea here. If you have some horrendous calculation to do and it can benefit from being spread over many processors then yes, who cares what core or what chip or what server a chunk of calculation happens on?
BUT if you have that problem you are not using micro-controllers.
In micro-controller land it matters very much where a chunk of code is running because the real world is connected to specific chips and the code handling that had better be in the right place.
Braino,
Propforth might be able to do something on such an array of cores, but we couldn't find anything that exists already to test it out. And so we guessed that nobody has come to need such a thing.
Just because a chip with a thousand or a million cores does not exist does not mean that no one has a need for it.
I can't imagine anyone would program such a machine in Forth than they would in assembler.
"...refer to COGs as a contiguous set of usable resources"
I don't get the idea here. If you have some horrendous calculation to do and it can benefit from being spread over many processors then yes, who cares what core or what chip or what server a chunk of calculation happens on?
Propforth has a word 'cogx'
you put a string of forth gibberish on the stack and a cog# and then execute cogx - Propforth will pass that string to the interpreter running on the specified cog
for example, if you have a word 'blink' you want to run on cog 3, you type in: " 3 ' blink ' cogx" and cog 3 runs the word blink allowing you to selectively assign work to cogs.
in a single processor implementation, all is well, you have cogs 0-7, in a multi-prop world, you have cogs 0-7 on each prop. Rather than changing cogx so you put "string prop# cog# cogx", I'd rather just have cogs 0-x so you don't need to worry about the prop#. COG# 14 then is cog#6 on the second prop (prop#1). Then your cogx is consistent regardless of the number of props you have.
@Dr_Acula, Re: For years it was a 'common bus', eg 50 ohm cable around the place running ethernet. Then everyone seemed to go to a 'star' system with cat5 cable.
Physically this may look like a star system, but electrically it is actually a bus system. A very short bus in a hub, switch, or router box with long cables that connect the bus to the device at the other end of the cable.
Comments
Sorry, No.
Again, this is NOT about the prop 2, or or parallax, or a criticism of Chip's efforts in anyway, or any of the other points you have covered so eloquently.
This is about a need.
The need is for many identical cores, does anyone else have this need? Specifically, does anyone have a use for 16 or 32 identical cores on a single chip? This need has been expressed by individuals in other venues. I want to see if there are any more folks on this forum that feel the same need.
So far the answer continues to be "No". So far no one feels they have grown beyond the number of cores available. This is one of the two valid answers I was looking for.
Asking a question is seldom (approaching never) a waste of time or money. Not asking a question is often (approaching always) a significant waste of time and money.
When you said "Any interest in (more than 8) cog chip" you meant "CPU cores" in general with no connection to the Prop or it's "cogs".
Sorry I was confused because, well, it's confusing:)
After all we are on a specific "Propeller 1" forum here.
OK, now in what context, servers, desktop, phone/pads, micro-controllers...?
I'm going to assume micro-controllers as that is the context of this forum.
Yes. I can see more cores being useful.
For example I have an FFT that will expand easily to fit 2, 4, 8... cores. People have often expressed an interest in having an FFT or similar algorithm on the Propeller. But such things are slow and using extra cores would help. Problem is this sort of thing eats cores and you have none left for other work. So more is better.
There are of course those who run out of COGs to implement all the devices they want. So more is better. But then the P II has threading which will help there if you really need it.
I still think more than 8 sharing HUB might not be so cool though due to HUB bandwidth usage. Perhaps one day the PII can be shrunk to fit two or four on a chip. Each with it's own HUB. Who knows? Lets's see when we get there.
As it stands we are stuck at 8 cores. The only other contender in MCU world is XMOS with 4 core devices with 8 hardware scheduled threads each. Cool. But a bit more expensive and more demanding hardware wise.
There is Green Arrays which seems to be a waste of time by all accounts, no idea really.
What else is out there?
1) One of my thoughts along these lines is turning a Propeller into a giant "custom SPI device". The Prop can easily act as an SPI Master with OBEX objects and various code snippets in other languages but I haven't really seen code to allow it to act as an SPI slave. Once you have this, you can just load up a Prop as a slave with all the hardware you need attached to it and the drivers for that hardware and you've just built a custom SPI device. The master Prop can talk to this just like any other SPI device.
2) For the multi-prop setups, I've created the star and daisy chained implementations in PropForth and played with those as far as proof of concept. There still need to be PropForth infrastructure built sp you can just refer to COGs as a contiguous set of usable resources and not need to worry about specifying a Prop# and then a cog# - for example, to reference the 3rd COG on the second Propeller in the cluster, you would just need to call it COG #10 since Prop #0 has COGs 0-7 and Prop #1 has COGs 8-15 in the cluster.
3) For Spin and C, there are multiple ways to communicate between Propellers but what is missing is a common (dare I say standard) way for the next layer in the protocol to be implemented. Whether you look at it for message passing or routing messages. The SPI implementation in #1 above is one version of this. The infrastructure that needs to be built for #2 is another for of these protocol agreements.
Any of the multi-prop solutions that various forum members have come up with all implement some for of this in order to talk between chips, so there are working examples out there.
Never mind a master Prop. It would give yo an easy way to connect a Prop to a Raspberry Pi so that you could have massively expanded I/O and other devices to play with from Linux.
Lots of other cheap ARM boards could use this as well.
Sorry my mistake. AT the time I saw it as related to the 1 cog question. I should have put this in the general forum.
The context started very broad, and included discussion of multiple quad core CPUs in servers, and touched the Green arrays chips, and finally got to microcontrollers.
We were talking about 16 or 32 ARM cores on a chip, or the TI chips, or various other possibilities, and finally Prop cores. The current iteration of Propforth might be able to do something on such an array of cores, but we couldn't find anything that exists already to test it out. And so we guessed that nobody has come to need such a thing.
I figure if the prop community doesn't have a general need for this, its probably best left to the xmas and FPGA guys.
This is the interesting thing about PF6 - All the threads are opportunities in a pool. The P1 has 8, the P2 should have 32. At least that's what the design is supposed to be. Whether this works or is easy enough to use remains to be seen. But it seems there are not so many folks that need this ability, so its hard to tell if the way its done lends itself to any given application.
I don't get the idea here. If you have some horrendous calculation to do and it can benefit from being spread over many processors then yes, who cares what core or what chip or what server a chunk of calculation happens on?
BUT if you have that problem you are not using micro-controllers.
In micro-controller land it matters very much where a chunk of code is running because the real world is connected to specific chips and the code handling that had better be in the right place.
Braino,
Just because a chip with a thousand or a million cores does not exist does not mean that no one has a need for it.
I can't imagine anyone would program such a machine in Forth than they would in assembler.
Propforth has a word 'cogx'
you put a string of forth gibberish on the stack and a cog# and then execute cogx - Propforth will pass that string to the interpreter running on the specified cog
for example, if you have a word 'blink' you want to run on cog 3, you type in: " 3 ' blink ' cogx" and cog 3 runs the word blink allowing you to selectively assign work to cogs.
in a single processor implementation, all is well, you have cogs 0-7, in a multi-prop world, you have cogs 0-7 on each prop. Rather than changing cogx so you put "string prop# cog# cogx", I'd rather just have cogs 0-x so you don't need to worry about the prop#. COG# 14 then is cog#6 on the second prop (prop#1). Then your cogx is consistent regardless of the number of props you have.
Physically this may look like a star system, but electrically it is actually a bus system. A very short bus in a hub, switch, or router box with long cables that connect the bus to the device at the other end of the cable.