About caching: modern Linuxes, apart from having access to kernel sources and making your
own changes, IIRC allow for certain multiprocessing parameters to be influenced, such a
locking memory ranges to threads/cores/processes.
Not overly discipline thoughts about such semi pro project (I suppose), but the raspberry
isn't a OC, and for those who have interest, if you connect up a dynamic memory like DDR3
to something that can read and write to it, like an FPGA or a PC processor or a ARM
processor like on the Raspbury, regardless of cache settings of processors, you will in
pretty much all cases get the full memory bandwidth that is a result of the clock speed
and data width of you memory at your disposal. For PC memory banks, it might be hard to
predict the actual processor and memory clock speed at any given moment, including the
settings of the cache, but except for hard to predict clock alignment issues (which cause
only minimal timing difference, normally) the whole digital machinery is strictly
deterministic, and can be predicted when you know the settings of all parameters (which a
decent kernel does).
So say you connect up a memory with a bandwidth of 100 Mega Bytes per second, and you
factor in the time it takes to do RAS/CAS equivalent addressing modes, you can know
exactly what latency and bandwidth you have available. Of course caches can increase the
perceived average memory bandwidth over some time, and you could want to make use of fast
cache memory for critical program parts, and of course you could want to make sure those
program and data elements stay in cache level 1 while you want it. Actual and simulated
multiprocessing as in Unix since the 70s at least (and I recall HP real time Unix from the
80s which was cool) do not really directly dictate what caching, memory paging (and
potential swapping), memory bank choice and data structures are going to be used, and how
the cache of let's say the processor in a windows PC is going to respond to that. So if
(like on Linux) you do not have the opportunity to bind a process to a core, and a piece
of memory, and assign certain communication resources (like the Zynq can) via the kernel
and the operating system to your program, you're going to get some response times on
average that depend on contention for memory space and cache use of other processes, and
the complete load of the machine, with a lot of seeming randomness.
A PC running very far from real time OS can better do more than a few samples audio
buffering to realistically put it's cores to work on DSP computations (sometimes I run
Linux sound programs with 4k (!) buffers and hundreds of plugins at 192kHz with hundreds
of connection over Jack, which makes that process run quite stable and usable, except with
a little delay, of course). PCs aren't really modeled after small microprocessors, but
rather after some elements of supercomputers from the past, which requires a whole
different programming style to actually get some of the real potential in terms of
MIPS/Flops and such going, and raise the temperature of the I7 (or what have you)
significantly to know it's number crunching. Of course if you know how to use your cache
entries (and keep write throughs from slowing you down) there's a lot more power in a PC
than easily is harnessed for DSP for instance memory tests on my very fast PC say I can
have cahce access for level 1..3 of 136GByte/s to 40MB/s in sizes from 32k to 122Mega
byte, which is a quite little more than the suggestion in this thread. So it may well be
worth hooking up an OS where all cache can be used for programs and data, and maybe paging
control information that allows a programmer to use that for where it is handy, and have
faith in the repeatability of the memory setup.
The ARMs in the RP have smaller cache and the ARMs are more of a Risc than a Cisc
architecture, so they are more suitable to do embedded control tasks with short turnaround
times.
Oh and just as a practical side remark: prefer to use Jack and a stable sample clock over
Alsa, which is more fiddly and may be not stable and might even try to re-sample and such
misery (for what I suppose is your purpose here).
T.V.
_______________________________________________
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp
