Scary -floop-parallelize-all option doesn't actually do anything except annoy package developers

Bug #1251488 reported by Tim Starling on 2013-11-15
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libmemcached
Medium
Brian Aker

Bug Description

One might think, reading the description of -floop-parallelize-all in the gcc manual, that -floop-parallelize-all will cause automatic parallelization of all loops by enabling a rarely-used, alpha-quality automatic parallelization feature called Graphite. However, this scary prospect is averted because -floop-parallelize-all doesn't actually generate parallel code unless you also specify -ftree-parallelize-loops=N where N is the thread count (that's right, it's fixed at compile time). This is explained at http://gcc.gnu.org/wiki/Graphite/Parallelization

So all -floop-parallelize-all does is cause the build to fail if libcloog is missing (i.e. bug #1232551), and increase compile time somewhat. I suggest that it be removed.

Related branches

Tim Starling (tstarling) wrote :

Note that according to http://gcc.gnu.org/wiki/Graphite/Parallelization and the linked document

http://gcc.gnu.org/wiki/AutoparRelated?action=AttachFile&do=get&target=autopar_performance_testresults.pdf

...auto-parallelization is extremely stupid, in that it will add a synchronisation overhead to every execution of every inner loop, even if the loop would complete on a single core in much less time than it takes to do the synchronisation. So there is a good chance that enabling it would actually slow down the application.

Brian Aker (brianaker) on 2014-02-01
Changed in libmemcached:
milestone: none → 1.0.18
assignee: nobody → Brian Aker (brianaker)
importance: Undecided → Medium
status: New → In Progress
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers