[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Mon, 23 Feb 2015, Tom wrote:
Most of the things I'm interested in will run faster - I tend do do things that need lots of cpu - flash from the uni of chicago does stellar explosions amongst other things and the number of cpu's available is used in building the models.
As long as it's built using threads in a sensible way.
Most of the music stuff I want the pi for benefit from multicore compilation.
Compilation is different from running. My BASIC compiles almost 9 times faster but runs at the same speed because it doesn't use and threaded code (actually not strictly true, it does and there is a speed-up - about 0.1% faster)
I'm trying to find some way of analysing what's good and what's bad. I now see that the -j is not passed on to the finished job in all cases - some build code uses it to optimise the code (or at least I think that's what's going on - some of the build processes are larger and more complicated than the programs themselves these days.
It's hard to analyse existing stuff unless you wrote it. Even then it's still hard. -j is a flag to make. If you want your own programs to utilise multi-cores then you need to write them to do that. Or you can call existing libraries that do it for you - if they exist.
Many moons ago I worked for a Bristol based supercomputer company... A frequent question we were asked was along the lines of: "I have this 30 year old FORTRAN program - make it faster"... A complete re-write for the target architecture was the ultimate solution, but not always fesable so the next best solution was to make their code use standard libraries then re-write the libraries to utilise the parallel architecture.
There are some clever compilers now though - some of them will paralellise code but it's never "free".
And writing parallel running code in the first place is tricky and not always obvious.
Also, stuff you learned and did 25 years ago might not be applicable today. e.g. converting from u-law to a-law audio - it's a 256-byte lookup table - or is it? It's now may be faster to do the calculation in a loop in cache than to take the cache-hit of looking up the table in main memory for every byte. (depending on the architecture)
I often wonder if we are reaching some kind of plateau where things are just so complicated you cant get round to understanding them fully....
We reached that after the BBC Micro. Gordon -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq