Yeah, very true. It does depends on so many factors, like interface standards used in this setup, what kind of data encoding used, and what kind of media (copper wires/traces or fiber optics).
Photodiodes that can receive rapidly-switching lights and convert 'em into digital electrical bursts are expensive. Figure $20 to 50 for one....
And, of course, finding the chips that handles the receiving ends is pretty hard (in some case, impossible). But, hey, trying wouldn't hurt!
Yeah, very true. It does depends on so many factors, like interface standards used in this setup, what kind of data encoding used, and what kind of media (copper wires/traces or fiber optics). Photodiodes that can receive rapidly-switching lights and convert 'em into digital electrical bursts are expensive. Figure $20 to 50 for one.... And, of course, finding the chips that handles the receiving ends is pretty hard (in some case, impossible). But, hey, trying wouldn't hurt!
There's lots of decisions to make but if you figure for parts that are too expensive, it could build up some delays in the project. Hobby parts are workable, even at slower speeds and the optoelectronic components are around $1 each or less in quantity. Do you have a starting date for this project?
If you're really intent on using fiberoptics, you may want to look at the new LightPeak standard which is (hopefully) going to put high-ish speed fiber within reach of the consumer market later this year.
Humanoido, really yes. Very good point. In my general opinion with this kind of hardware, expensive parts are only to be used for communications and content switching. That way, it's even more helpful to have something more reliable to zip the data around quickly - system-wise.
Forest, I will look into this. Thank for recommending the hardware.
LightPeak seems promising, but the biggest, mountain-sized hurdle is... It's propeitary. (Obviously, it's developed by Intel - I don't hate Intel - just a bit disappointed.)
Optical Ethernet standard is as open as a book - you can use it in anything you want.
So... I guess I will go with Fibre Optic Ethernet for a while - research it in details, before I decide to go with it or develop my own packet transfer protocol for this computer.
(I have an account on Maxim Semiconductors, Inc. so I can grab up a nice book on that technology and even some propeitary informations that could be useful to me.)
You can also find reasonably priced fiber optics kits from the science companies. You can look at some of the hobby applications for IR transmitters and receivers. A time ago, I did some work in this area and created a wireless IR system for the BS2px using two or more Penguin robots. One robot would do something like lift a leg and then tell the other robots to do the same and they would copy cat the motions. The principle is the same for direct connect fiber optics. For more information and ideas, take a look at the Parallax book about IR.
Yeah. I already thought of placing the IR VCSEL (in PLCC or 1206 package) and the PIN photodiode on the edge of the cards on both side, for local transcieving between the cards if the PCIe 1x bus isn't even enough. Two parts on each side, that's it. Just open-space communication between the cards, is really nice because I still can get screaming fast IO out of dirt-cheap hardware setup.
Fiber Optics is mostly reserved for system-wide, possibly link to the seed computer, should I ditch the PCIe bus idea.
LightPeak is out of the question... or should I say CopperPeak ?. The transceivers are the expensive part... they probably wanted something that can go down to €1... I think that the sockets/receivers and so on used in I2S are a good alternative. 1MBit/s is not bad
Yeah. They're out of question, because Intel wants something more concrete from its customers. Proprietary... No wonder.
1Mb/s is good only for the support components, since supercomputing will require huge bandwidth. With Maxim Semiconductors chips, you could be able to use your own standards. I have decided FO is probably the best way for linking to seed computer.
I may be ready to pick the Propeller P8X32A's brain clean soon... Hopefully as I don't have great salary yet...
I may be going with Ramtron's Ferroelectric RAM to hold the firmware as i will need to repeatedly overwrite it as much as it need to be, to perfect the firmware (thus picking its brain clean).
I suspect Propeller II's almost ready but I could be wrong. Otherwise right, I would not have to leave my idea on back-burner for a while. (YAY! Bummers, it ain't out yet... Maybe this Summer or Falls.)
In your current design for a Propeller based supercomputer, how fast can it run and will it make it to the top 100 list? It sounds like you are going for some incredible speed and fascinating designs!
Which top 100 list are you refering to?
I suspect any multi-prop computer will be many orders of magnetude slower than any current top 100 super computer.
I'd like to see two Propellers actually executing an algorithm on both devices in parallel, and getting something approaching 320 MIPS. I don't think that anyone has even achieved that yet. Come to that, I haven't even seen a single Propeller doing 160 MIPS with an algorithm running on all eight cores.
Any Propeller running 8 COGs at 80MHz clock rate is by definition running at 160MIPS. Now whether the COGs are doing something useful is an entirely different matter.
Some people get excited watching LED's blink (essentially what a TV does), but I think an 8 COG FFT spectrum analyzer with a TV/VGA graph and adjustable controls with a mouse controlled GUI would be a vastly more interesting demonstration of Propeller's ability.
I suppose a better question would be: does the FFT run eight times as fast on eight cogs?
Indeed it is a good question as a matter of scale. Some resources would be required for I/O though so 8 cogs could not be dedicated to FFT and actually be useful. With respect to the thread topic, one could have 7 COGs per Propeller doing FFT and one COG doing communications.
Also, could running the program on more than one Propeller result in a commensurate speed increase? If one of the proposed "Propeller supercomputers" can do that, I'd be very surprised.
Also, could running the program on more than one Propeller result in a commensurate speed increase? If one of the proposed "Propeller supercomputers" can do that, I'd be very surprised.
I agree.
A PC running a Visual C# FFT would probably be faster.
I'd like to see the results of such an FFT drag race competition.
The fft can easily be split to 8 parts that are handled at 160 mips. But then the sub results of those 8 parts must be combined, using less cogs, this lowers overall throughput a bit.
Might be better to use only 4 cogs if some IO or display is required.
Realistically you're probably looking at 80 mips top when you factor in I/O reqs and stay away from SPIN implementation that turns the Prop's performance to that of a 4mhz 68k.
But until someone puts out a PASM version of FFT, it's all a variation of fantasy football.
Realistically you're probably looking at 80 mips top when you factor in I/O reqs and stay away from SPIN implementation that turns the Prop's performance to that of a 4mhz 68k.
But until someone puts out a PASM version of FFT, it's all a variation of fantasy football.
I'd like to see the results of such an FFT drag race competition.
I don't have an FFT in C# but I do have the original FFT I wrote in C++ which was the model for the Spin version in heater_fft which was in turn the model for the final PASM version.
So how do they compare?
The PASM fft is doing 1024 point FFT in one COG including bit reversal and magnitude calculation steps in about 50ms. This depends somewhat on the input data.
The C++ version on my 2GHZ PC can do the 1024 point FFT in 1.3ms. or about 40 times faster. The equivalent of an 800MIPS Propeller.
But, the PC is doing it in floating point, not 12 bit fixed point, and the code is not at all optimized, it is C++ after all and it is using a complex number class.
I am not aiming to the Top 100s, but to make my jobs and the other Propellerheads' easier. Some software are very rough on Propeller chip all by itself, so adding more will just make sense.
And, yes, FFT can be made to be executed faster, but the only concerns remains will be how much the COGs in current Propeller I chips will handle - it has two-stages XY pipelines (which is somewhat crude,
but what the heck, we got nothing to lose...) - I may have to find out as I get the board built and have the OS kernel carefully coded up by hands (Ah, a good jolly old days of x86 assembly - I have been away from it for up to two years... At least it's in my familiar turfs.)
Mike G, I do not have any demo as of yet, I am in process of ordering up the parts (and of course, designing up the board - to handle those QFN chips, and of course, a BGA packaged SDRAM). Building great system do oftentime require great patience and the concentration on tiny details - they all counts. I don't want very small unforeseen problems/limits to break what will be the greatest project I am going to undergo. (That's the reason for prototyping...)
And, I am interested in Jazzed's SDRAM project - it will be of great helps. Thanks, Jazzed! However, when I get my hands on 180nm Propeller II and 266MHz DDR-I chips, I may be left out, to find out on my own. Argh! Oh well, we're just what we are. I really am hoping for the MAPBGA package for Propeller II as my project may demand significant real-estate board area... (And, of course, extra wee more for trace matching for Propeller II's IO between BGA-54 DDR-I chip...)
BTW, why QFN-44 Propeller chip? Heat stagnation is bad for chip (I will have to OC'd this thing to 100MHz with 6.25MHz SiTime MEMS oscillator at 16x PLL multiplier setting for 50MHz Intel486-like pipelining on SDRAM - in my experience, SDRAM like to see 47MHz as a minimum or the whole thing smokes - which is the reason why we don't see that much SDRAM-compatible 486s, they're quite rare.)
UPDATE:
I have placed an order for:
Ramtron 64 Kilobytes FRAM
ISSI 16MB BGA-54 SDRAM
Propeller P8X32A-M44
FTDI USB to Serial RS232 converter
FTDI Vinculum II USB host controller (for hard drive - to verify what the Propeller is doing by writing what's on the Propeller's RAM as of "DONE" status...)
And, of course a 3.3V 1A LDO regulator with 2.7mF Nichicon capacitor (to really eat up what's left of the low-frequency ripples - I will buy more parts later to complete my exploratory order).
If yes, that it got through, I am going to be like an orange-haired dude in Devo music video (Satisifaction - the dude who was jumping like something short-circuited) - I would barely handle myself... ^____^ Yay!
BTW, I have just started on ASM source code for the kernel - it has to be compiled first in SPIN (for bootloading then G'Bye, SPIN interpreter! I am not going to need it, I perfer squeeky clean machine codes so I won't bog the whole thing down, then it would probably lose some real meanings...) [I know it should be "squeaky" not "squeeky", but I am a strange dude sometimes, and because I just feel like it...]
Anyways, I am going to proceed with kernel writing - jazzed's SDRAM project provided me with enough information - however, I admit I am confused as in "why use two-hex signed value?"
like $FF - I am used to input direct value - without $ sign in FASM (Flat Assembler). If you can provide me some signed hex calculator or the cheatsheet, I would appreciate it - as it would help much.
BTW, Humanoido, you were so quiet... -_- I am not criticalize you, just wondering...
Comments
Photodiodes that can receive rapidly-switching lights and convert 'em into digital electrical bursts are expensive. Figure $20 to 50 for one....
And, of course, finding the chips that handles the receiving ends is pretty hard (in some case, impossible). But, hey, trying wouldn't hurt!
Forest, I will look into this. Thank for recommending the hardware.
LightPeak seems promising, but the biggest, mountain-sized hurdle is... It's propeitary. (Obviously, it's developed by Intel - I don't hate Intel - just a bit disappointed.)
Optical Ethernet standard is as open as a book - you can use it in anything you want.
So... I guess I will go with Fibre Optic Ethernet for a while - research it in details, before I decide to go with it or develop my own packet transfer protocol for this computer.
(I have an account on Maxim Semiconductors, Inc. so I can grab up a nice book on that technology and even some propeitary informations that could be useful to me.)
Fiber Optics is mostly reserved for system-wide, possibly link to the seed computer, should I ditch the PCIe bus idea.
1Mb/s is good only for the support components, since supercomputing will require huge bandwidth. With Maxim Semiconductors chips, you could be able to use your own standards. I have decided FO is probably the best way for linking to seed computer.
I may be going with Ramtron's Ferroelectric RAM to hold the firmware as i will need to repeatedly overwrite it as much as it need to be, to perfect the firmware (thus picking its brain clean).
I suspect Propeller II's almost ready but I could be wrong. Otherwise right, I would not have to leave my idea on back-burner for a while. (YAY! Bummers, it ain't out yet... Maybe this Summer or Falls.)
I suspect any multi-prop computer will be many orders of magnetude slower than any current top 100 super computer.
Well there is a challenge. I have a nice FFT routine that couldg be split over 8 cogs.
Some people get excited watching LED's blink (essentially what a TV does), but I think an 8 COG FFT spectrum analyzer with a TV/VGA graph and adjustable controls with a mouse controlled GUI would be a vastly more interesting demonstration of Propeller's ability.
A PC running a Visual C# FFT would probably be faster.
I'd like to see the results of such an FFT drag race competition.
Might be better to use only 4 cogs if some IO or display is required.
But until someone puts out a PASM version of FFT, it's all a variation of fantasy football.
Heater's FFT code are already written in PASM.
have a look at my fft it is PASM all the way through. There is a Spin version included in the same object just for illustration.
There is also another fft by Ale. No idea how they compare performance wise.
I do agree that 80mips is about the best we can expect.
I don't have an FFT in C# but I do have the original FFT I wrote in C++ which was the model for the Spin version in heater_fft which was in turn the model for the final PASM version.
So how do they compare?
The PASM fft is doing 1024 point FFT in one COG including bit reversal and magnitude calculation steps in about 50ms. This depends somewhat on the input data.
The C++ version on my 2GHZ PC can do the 1024 point FFT in 1.3ms. or about 40 times faster. The equivalent of an 800MIPS Propeller.
But, the PC is doing it in floating point, not 12 bit fixed point, and the code is not at all optimized, it is C++ after all and it is using a complex number class.
And, yes, FFT can be made to be executed faster, but the only concerns remains will be how much the COGs in current Propeller I chips will handle - it has two-stages XY pipelines (which is somewhat crude,
but what the heck, we got nothing to lose...) - I may have to find out as I get the board built and have the OS kernel carefully coded up by hands (Ah, a good jolly old days of x86 assembly - I have been away from it for up to two years... At least it's in my familiar turfs.)
Mike G, I do not have any demo as of yet, I am in process of ordering up the parts (and of course, designing up the board - to handle those QFN chips, and of course, a BGA packaged SDRAM). Building great system do oftentime require great patience and the concentration on tiny details - they all counts. I don't want very small unforeseen problems/limits to break what will be the greatest project I am going to undergo. (That's the reason for prototyping...)
And, I am interested in Jazzed's SDRAM project - it will be of great helps. Thanks, Jazzed! However, when I get my hands on 180nm Propeller II and 266MHz DDR-I chips, I may be left out, to find out on my own. Argh! Oh well, we're just what we are. I really am hoping for the MAPBGA package for Propeller II as my project may demand significant real-estate board area... (And, of course, extra wee more for trace matching for Propeller II's IO between BGA-54 DDR-I chip...)
BTW, why QFN-44 Propeller chip? Heat stagnation is bad for chip (I will have to OC'd this thing to 100MHz with 6.25MHz SiTime MEMS oscillator at 16x PLL multiplier setting for 50MHz Intel486-like pipelining on SDRAM - in my experience, SDRAM like to see 47MHz as a minimum or the whole thing smokes - which is the reason why we don't see that much SDRAM-compatible 486s, they're quite rare.)
I have placed an order for:
Ramtron 64 Kilobytes FRAM
ISSI 16MB BGA-54 SDRAM
Propeller P8X32A-M44
FTDI USB to Serial RS232 converter
FTDI Vinculum II USB host controller (for hard drive - to verify what the Propeller is doing by writing what's on the Propeller's RAM as of "DONE" status...)
And, of course a 3.3V 1A LDO regulator with 2.7mF Nichicon capacitor (to really eat up what's left of the low-frequency ripples - I will buy more parts later to complete my exploratory order).
If yes, that it got through, I am going to be like an orange-haired dude in Devo music video (Satisifaction - the dude who was jumping like something short-circuited) - I would barely handle myself... ^____^ Yay!
BTW, I have just started on ASM source code for the kernel - it has to be compiled first in SPIN (for bootloading then G'Bye, SPIN interpreter! I am not going to need it, I perfer squeeky clean machine codes so I won't bog the whole thing down, then it would probably lose some real meanings...) [I know it should be "squeaky" not "squeeky", but I am a strange dude sometimes, and because I just feel like it...]
like $FF - I am used to input direct value - without $ sign in FASM (Flat Assembler). If you can provide me some signed hex calculator or the cheatsheet, I would appreciate it - as it would help much.
BTW, Humanoido, you were so quiet... -_- I am not criticalize you, just wondering...