[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 23/02/15 11:24, Gordon Henderson wrote: > On Mon, 23 Feb 2015, Tom wrote: >> 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. Well said Gordon. make -j runs multiple build steps in parallel, and that is all. This is a good thing if the steps are processor-intensive, and there are spare processor cycles. If the compilation step is mostly I/O then make -j won't make it faster. If the processor cores are all already at 100% then make -j won't make it faster. The final program only runs faster on multicore/multiprocessor systems requires if it is designed to do so. The build system cannot do anything about that. Designing programs for parallel processing is hard. You need to ensure that everything is correctly synchronized, but that the synchronization doesn't make things slower. You need to think about what can run concurrently, and what can't. Paul McKenney from IBM, who works on the Linux kernel, maintains a book online: "Is Parallel Programming Hard, And, If So, What Can You Do About It?" ( https://www.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.2015.01.31a.pdf ) that covers much of the issues rather nicely. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++11 thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
Attachment:
signature.asc
Description: OpenPGP digital signature
-- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq