Running a toy fractal benchmark that wasn't particularly well optimized for the CPU and using that to make blanket statements that the DSP is faster is way over the top
Exophase, of course more benchmarking will need to be done. You wanted an optimization compo, so here's your chance: The DSP version of the fractal benchmark was 50% faster than MHT's optimized ARM version, all that at 80% the ARM clockrate at around 60% the power consumption of the ARM-only version. If you think I'm making "blanket statements", go ahead, make a faster ARM version and prove me wrong. I deliberately chose the fractal algorithm because I consider it quite DSP unfriendly (
not assembly optimized, lots of branches). I expect the performance advantage of DSP friendly algorithms (
"block" processing code like graphics blitters, audio filters/resamplers, ..) to be much higher -- but _that_ remains to be seen.
But you're also right of course, no need to create a hype here so in addition to my last statement I have to add that it is much less convenient/comfortable to code for the DSP since there's no symbolic debugger for it (
actually not any kind of debugger), programming it in assembly is hell (
but TI's optimizing C/C++ compiler is very good so you do not have to), you cannot do any high level things like accessing the file system, or use peripherals (
no drivers for most of them), and using it comes with a certain overhead (
see below).
@comradekingu
So that was actually a real question and you really did not know ? sorry for the sarcasm then.
As WizardStan already mentioned, the DSP really shines at stream/block processing but it can also be used as a general purpose processor. You can even run Linux on it (
yes, someone ported it once) so technically it were possible to reverse the roles and use the ARM as a coprocessor. That would not make much sense, though, since the ARM is optimized for low power consumption when idle (
the DSP has a slightly higher baseline power consumption, ~80mW from what I have measured), and the DSP MMU is very basic and can only handle 16 address ranges.
Since in the Pandora/Angstrom Linux configuration the DSP is the coprocessor, there is a certain overhead when using it.
Using interrupt based messaging, simple functions on the DSP can be called ~25000 times per second.
Using the c64_tools "fastcall" messaging protocol, the same DSP function can be called ~456000 times per second with the drawback that the DSP has to be locked for the calling ARM process during the time fastcalls can be made, and polling is used (
bad for power consumption).
Since you were mentioning audio resamplers, let's assume you have an audio stream running at 48000 stereo samples (fragments) per second, you are using that for a video game so the audio output latency should not exceed 50fps = 20ms, i.e. you will need to fill a new output buffer every (48000/50)=960 fragments, and call the DSP 50 times a second.
You would use the interrupt based messaging for that to be multiprocess/power consumption friendly, so that gives you a base DSP overhead of (1000/2*25000)=0.02 milliseconds per PAL video frame, or 20000 ARM clockcycles (assuming a 1GHz clock). I divided by 2 since for practical reasons you would start the DSP calculation, then do something else with the ARM, and when you are done with that the result will most likely already be available without further waiting.
Depending on the application, some tricks can be used though, a common one being to collect processing requests in a shared memory area and notify the DSP to process these requests at certain intervals.
Let's assume you use the DSP to "emulate" a soundchip / implement a synthesizer.
You will have the replay control code on the ARM but you will notice that "oh noes", 960 sample intervals are much too long for properly timed music playback.
So what you do is you fill a "request" shared memory buffer with commands like "process 10 samples, then change volume of channel 'x' to 'y', process another 140 samples, then stop channel 'z' and change frequency of channel 'w' to 'v'", and so on, then let the DSP parse that buffer and do the audio rendering.
The same strategy could be used for graphics rendering, of course. E.g. in an emulator you could use the fastcalls to call the DSP per scanline (or whatever makes sense), let it do the actual rendering and use the ARM only to create these "process requests" / command lists.
I don't think forcing use of DSP or other componant is important. The main point is the result.
exactly my thoughts (said sth similar on the previous page)
I think a "demo" compo would be pretty good
sure, if people here can write some nice effects, create interesting screen designs and music, and it's not just XScreensaver ports
(
personally, I never was any good at demo coding but never really tried, either. Did some intros on homecomputers back in the later 80ies, early 90ies but nothing worth to write home about. I always prefered application and game programming (i.e. interactive things). With demos back in the days, everyone knew that it was realtime since there was no other way to do it. Nowadays many do not get it and think it's just a video (and therefore compare the demo to videos which is very unfair, of course). Unfortunately, you really need a pricey gamer PC to run nowadays demos, so many ppl. just stick to watching the videos to be able to see the demos at all ..).
For a Pandora demo compo, I'd therefore suggest to make it an interactive one. Then again, I could understand if ppl. decided to make a demo-ish game with fancy abstract visuals instead 
