Re: My current idea for improving libgomp
Hey Sho, > I totally agree with this point. > Currently, I'm planning to implement tied task using breath-first > scheduler wrote in > section 3.1 of "Evaluation of OpenMP Task Scheduling Strategies" by Nanos > Group. > http://www.sarc-ip.org/files/null/Workshop/1234128788173__TSchedStrat-iwomp08.pdf > > That is: > * A team has one team queue which contains tasks. > * A team has some (user-level) threads. > * A thread can have one running task. > * A thread has private queue which contains tasks. > * When a task is created, it is queued in team queue. > * Each thread steals tasks from the team queue and inserts it in the > private queue. > * Once tied task is executed in a thread, it is queued only in the > private queue in the thread > when it encounters `taskwait'. > * Each thread runs a task from its private queue. > > But I'm not sure how to achieve good load-balancing and what kind of > cutoff strategy to take. > As for load-balancing, I'll read Nanos4 implementations and ask Nanos > Group for it. > (Of course your advice will do :-) ) > > As for cutoff, basically I can choose `max-tasks' strategy or > `max-levels' strategy. > When number of tasks or recursion levels exceed this value, the > scheduler stops its work > and execute each task as sentences in sequential programs. > But "Evaluation of OpenMP Task Scheduling Strategies" says better > cutoff strategy is different > from application to application. Right, start with distributing the queues and then think about load balancing. I would say don't worry too much about cut-offs at this point. Finding a good cut-off strategy that works without drawbacks is pretty much an open research problem. Just spawn the tasks and focus on efficient task creation and scheduling. In my experience, going from a centralized to a distributed task pool already makes a huge difference. To get a better overview of other implementations, which you can compare to libgomp, I recommend a couple of papers. For example: - OpenMP Tasks in IBM XL Compilers, X. Teruel et al. - Support for OpenMP Tasks in Nanos v4, X. Teruel et al. - OpenMP 3.0 Tasking Implementation in OpenUH, C. Addison et al. - A Runtime Implementation of OpenMP Tasks, J. LaGrone et al. You should be able to find copies online. If not, let me know. -Andreas
How to tell reload to properly store a register?
My target needs a scratch register to store a register in one register class and it needs to use memory to copy from one register class to another. I have store and reload_out patterns for those registers. When reload tries to copy data from one register class to another, it just stores the register without using the proper reload_out pattern which has a scratch register. How can I tell reload to always use a scratch register when storing a register? Thanks. -- H.J.
Re: How to tell reload to properly store a register?
H.J. Lu schrieb: My target needs a scratch register to store a register in one register class and it needs to use memory to copy from one register class to another. I have store and reload_out patterns for those registers. When reload tries to copy data from one register class to another, it just stores the register without using the proper reload_out pattern which has a scratch register. How can I tell reload to always use a scratch register when storing a register? Did you define the TARGET_SECONDARY_RELOAD hook? Thanks.
Re: How to tell reload to properly store a register?
On Sat, Apr 30, 2011 at 6:18 AM, Georg-Johann Lay wrote:
> H.J. Lu schrieb:
>>
>> My target needs a scratch register to store a register in one register
>> class
>> and it needs to use memory to copy from one register class to another.
>> I have store and reload_out patterns for those registers. When reload
>> tries to copy data from one register class to another, it just stores the
>> register without using the proper reload_out pattern which has a scratch
>> register.
>>
>> How can I tell reload to always use a scratch register when storing a
>> register?
>
> Did you define the TARGET_SECONDARY_RELOAD hook?
>
I did. I have
if (!in_p && MEM_P (x))
{
sri->icode = direct_optab_handler (reload_out_optab, mode);
return NO_REGS;
}
Somehow, it isn't used when reloading
set (regclass1:SF) (regclass2:SF)
Reload just calls emit_move_insn directly to store regclass2.
--
H.J.
Re: My current idea for improving libgomp
Hello again Andreas, (I just forgot to Cc to GCC ML, so resending this email) > Right, start with distributing the queues and then think about load > balancing. OK. > I would say don't worry too much about cut-offs at this point. Finding a > good cut-off strategy that works without drawbacks is pretty much an > open research problem. Just spawn the tasks and focus on efficient task > creation and scheduling. In my experience, going from a centralized to a > distributed task pool already makes a huge difference. As you say, deciding cut-off strategy sounds pretty difficult. I read "Evaluating OpenMP 3.0 Run Time Systems on Unbalanced Task Graphs" and learned a litt about Adaptive Task Cutoff, in which good cutoff is found by profiling data collected early in the programs' execution. I guess it's almost impossible to implement it in the GSoC term but I'm interested in challenging it in the future. > To get a better overview of other implementations, which you can compare > to libgomp, I recommend a couple of papers. For example: > > - OpenMP Tasks in IBM XL Compilers, X. Teruel et al. > - Support for OpenMP Tasks in Nanos v4, X. Teruel et al. > - OpenMP 3.0 Tasking Implementation in OpenUH, C. Addison et al. > - A Runtime Implementation of OpenMP Tasks, J. LaGrone et al. Thanks. I'll read all of them ;-) -- Sho Nakatani
gcc-4.7-20110430 is now available
Snapshot gcc-4.7-20110430 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20110430/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 173224 You'll find: gcc-4.7-20110430.tar.bz2 Complete GCC (includes all of below) MD5=41c2876dcf67d51f320f6c534de72989 SHA1=ff8ad7690268c6aea4f5a04be51cd0b4e84ae8a6 gcc-core-4.7-20110430.tar.bz2C front end and core compiler MD5=1abe8f5b650f632c2abc21872d49c0a2 SHA1=bf4bb7a2b84e458cb55b61be51fa78645d47b481 gcc-ada-4.7-20110430.tar.bz2 Ada front end and runtime MD5=8004abbe15e742f989cf99ea96bfb8be SHA1=d9859b7c68bd543be1016a7c95d7e5acf6aea356 gcc-fortran-4.7-20110430.tar.bz2 Fortran front end and runtime MD5=e6971c770199c5a50087c6e868d9b956 SHA1=659e69d78b38f9bd79b4ef134d7427c79902de75 gcc-g++-4.7-20110430.tar.bz2 C++ front end and runtime MD5=2f1fe13e25f3bf11634760c16dcb6ea6 SHA1=e57ba36d975f57b1c9c9d1880aa45fa8550fc049 gcc-go-4.7-20110430.tar.bz2 Go front end and runtime MD5=0520547c5fc456c1a694b0b6503ab910 SHA1=e74f17666f9a513d663d53d592e1091c1f1d75cf gcc-java-4.7-20110430.tar.bz2Java front end and runtime MD5=7984b84c4f3ada0049ba2ad6350f1ab6 SHA1=8099c8064f5a2af78b98047e25bcd781df1d4e1a gcc-objc-4.7-20110430.tar.bz2Objective-C front end and runtime MD5=429d7770a4030fdc53c84745c065b5c2 SHA1=1333dcdc7cdd682ef00aa2bf9ec92863adce987d gcc-testsuite-4.7-20110430.tar.bz2 The GCC testsuite MD5=61e82c89782d1edc456c772bbf87de99 SHA1=4ccdfb7270f83b628d21b57c5166e724f59843ce Diffs from 4.7-20110423 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
GCC Release Management
The GCC Steering Committee appointed me to the role of GCC Release Manager on March 22, 2000, as part of the GCC 3.0 release cycle. Eleven years and umpteen releases later, it's time for me to relinquish that position. I am just as interested in GCC as ever, but I simply no longer have the time to contribute to GCC on a day-to-day basis. Fortunately, in 2008, the GCC SC added three co-RMs: Jakub Jelinek, Joseph Myers, and Richard Guenther. The three of them have shouldered the majority of the load over the past couple of years. The SC collectively and I personally have every confidence in their ability to do continue onwards. In fact, I have no doubt that they will do a better job together of managing future releases than I did. During my tenure as RM, I received the support, kind words, and constructive criticism of many, many people -- far too many to name. I am very grateful for all of that and, more generally, for having had the opportunity to be involved in such an important open-source project. Thank you, -- Mark Mitchell CodeSourcery / Mentor Graphics m...@codesourcery.com (650) 331-3385 x713
