Re: GCC 4.1: Buildable on GHz machines only?
I have to agree with Richard's assessment, gcc is currently on the verge of being unusable in many instances. If you have a lot of software to build and have to do complete rebuilds it's painful, the binutils guys have a 3x speedup patch coming up, but every time there is a speedup it gets eaten up. gcc seem's to be moving more and more data around and does more and more temporary allocations of huge chunks of memory. Sometimes a concearn pop's up and some 5 to 10 percent is gained only to be lost again. My opinion on the point is that if there was a 100% speedup of gcc it would be very good but not enough since it has slowed down so much mainly from memory usage. I used to do kernel compiles in an hour or two on a pentium laptop, and now I can forget it since it's memory is soon exhausted and it goes into swap. I have never done any 'memory profiling' but I think it might be time to give it a shot, does anybody have any hints on how to go about something like this ? It should be enough to have a look at the places where were searching for information that we already have had, or to make any kind of search more efficient if possible. Perhaps it's possible to graft some kind of indexing scheme on the worst offenders, so that some O(n^2) can get to O(1 ) or something. The main problem seem's to be that almost any efforts to point out a single scapegoat have not been very successful. / regards, Lars Segerlund. On Thu, 28 Apr 2005 14:24:11 +0100 Richard Earnshaw <[EMAIL PROTECTED]> wrote: > On Wed, 2005-04-27 at 20:57, Steven Bosscher wrote: > > On Wednesday 27 April 2005 17:45, Matt Thomas wrote: > > > > The features under discussion are new, they didn't exist before. > > > > > > And because they never existed before, their cost for older platforms > > > may not have been correctly assessed. > > > > If someone had cared about them, it would have been noticed earlier. > > But since _nobody_ has complained before you, I guess we can conclude > > that by far the majority if GCC users are quite happy with the cost > > assesments that were made. > > This is false. I've been complaining (at various levels of volume) ever > since we switched to using the garbage collector.[1] > > R. > > [1] I don't think the Garbage Collector is the only source of slowdown. > It was just the change that tipped the balance from not-very good to > insane. Unfortunately, things have continued to go down-hill from > there.
Re: GCC 4.1: Buildable on GHz machines only?
I think Zack summarises very well here, the general consensus is that gcc is slow, now if gcc was faster, it would perhaps not be so bad to build java ? If we do a reasonable comparison of compile times against the intel compiler or the portland group or something similar we consistenly find that gcc is slower by a couple of times 1x - 3x, ( this is only my impression, not backed up by hard data but should be in the ballpark ). The real killer seems to be large memory usage, and I have a hard time believing that if you compile fx. 1 meg of source the compiler 'have' to use some 800 megs or something as working memory. ( When speaking of the real killer here I mean for old systems ). With all the discussions on cache hit rate and similar criterions lately we can't forget that less data higher means hit rate. So I am of the opinion that we have to be aware of the problem, and the gcc list has a reputation for really ticking of people complaining on the slowness, look at the archives, this is something that comes up every two months and the it gets even slower. The regular arguments are: 1. No it's not , ( slow that is ). 2. It's your hardware/program 3. All modern computers have a gig or RAM and then it's fast. 4. I have a fast computer and am not interested. 5. gcc does so much and and is so good that it's not strange that it takes time. 6 . and so on ... please correlate to the whining on the mailing list archives. Anyhow, gcc need's to get faster, and it needs to use less memory, perhaps it shouldn't be a goal in itself, but it must be desirable, and 'on' the radar. The above are my opinions, feel free to disagree, / regards, Lars Segerlund. On Wed, 27 Apr 2005 16:40:29 -0700 Zack Weinberg <[EMAIL PROTECTED]> wrote: > Daniel Berlin <[EMAIL PROTECTED]> writes: > > > On Wed, 2005-04-27 at 15:13 -0700, Stan Shebs wrote: > >> Steven Bosscher wrote: > >> >If someone had cared about them, it would have been noticed > >> >earlier. But since _nobody_ has complained before you, I guess we > >> >can conclude that by far the majority if GCC users are quite happy > >> >with the cost assesments that were made. > >> > > >> No, there have been plenty of complaints, but the GCC mailing lists > >> have, shall we say, a "reputation", and a great many users will not > >> post to them, > > > > I've never in my life heard this from another mailing list, and i > > contribute to a *great* many open source projects. > > I have seen such complaints. Not about bootstrap times, no, that only > affects people who compile the compiler; but the more general case of > 'gcc takes forever to compile this program' does appear on a regular > basis. > > I do also think that the amount of ridicule heaped on people who come > to the gcc lists is, in general, too high. People should not be > ridiculed for complaining that the compiler is slow, even if they are > insisting on using vintage hardware. It is slow, even on fast > hardware; it's just easier to see that on slow hardware. Rather more > importantly, people should not be ridiculed for submitting bug > reports, even if they are wrong. I suspect the bad public image that > Stan refers to, has more to do with this than anything else. To be > fair, it can be hard to explain that someone is wrong without > belittling them; but it is important to make the effort, particularly > when the reason they are wrong is esoteric (e.g. any of the legion of > counterintuitive things in the C standard). > > Some people are worthy of ridicule; those who are trolling, or those > who are persistently and wilfully clueless. However, ridicule is > *not* an effective way of making these people shut up and go away, > which is the appropriate goal when dealing with them. It can be fun > to argue with them, but long argument threads are a drag on the > mailing list, so we should not make a habit of it. This is not > alt.flame. > > > The only person i see ridiculing people frequently happens to be > > from @apple.com. > > I can think of four people who regularly ridicule posters. Only two > of them are Apple employees. > > zw
Re: [gomp] OpenMP IL design notes
Okie, I will try to look it over, right now I am very busy, and I don't know when I can get back. I have to remarks so far, the first is that we have to extend the gfortran internal representation also, and the second is that perhaps we don't have to have a 1 to 1 mapping of OMP to IL, ( thins of variables and such, I might be wrong but I think we perhaps can do the same thing a bit easier ). / regards, Lars Segerlund. On Tue, 3 May 2005 16:42:47 -0400 Diego Novillo <[EMAIL PROTECTED]> wrote: > I have started working on connecting Dmitry's OpenMP parser to > the middle-end so that we can start generating the basic runtime > calls, which Richard should be posting soon. With any luck, we > should have some basic functionality in a few weeks. > > Initially, we will be outlining parallel sections into their own > functions. This is mostly for implementation convenience. > However, long term we are better off incorporating parallel > markers into the IL so that we can do a better job analyzing and > optimizing. > > It may be marginally quicker to be able to launch threads that > execute the same body of code because it avoids the argument > passing overhead for shared stuff and the memory indirection in > the launched functions. But mostly, I'm interested in the IL > elements for optimization and analysis. Launching multiple > threads on the same function body may give us more headaches than > it's worth ATM. > > Essentially, we will have an IL expression for every OpenMP > pragma. These expressions are GENERIC and the gimplifier work is > mostly in the bodies. With few exceptions, the controlling > predicates and clauses are required to be in more or less GIMPLE > form by the standard already. > > The lowering will, for now, just create a new function and > replace the block of code along the lines of tree-nested.c. > However, in the future, the parallel sections will be > single-entry single-exit regions in the CFG with the controlling > GOMP_PARALLEL_... expression as the entry block and a latch-like > exit block. The parallel region building can be modeled after > the loop structure, but there isn't as much nesting, so it > shouldn't be too complex. As an aside, we do need CFG region > building and the ability to have the optimizers work on > sub-regions (currently being worked on, as I understand). > > In fact, even if we don't end up launching threads on the same > function body, we can keep the parallel region inside the > function throughout the optimizers and outline it at a later > point (before RTL, perhaps). > > Some runtime library calls (synchronization mostly), ought to be > recognizable as such by the optimizers. I am not sure whether to > define them as builtins, provide an attribute or make them IL > expressions. Any suggestions/ideas? > > The IL constructs mostly mirror their #pragma counterparts. Take > these as a design draft, I have only started working on the > implementation, so I expect the design to evolve as I implement > things. There may also be several hidden assumptions that I > expect to become embarrassingly obvious in a few weeks. Names > prefixed with "g_" below mean "the gimplified form of ...". > > > Parallel regions > > > #pragma omp parallel [clause1 ... clauseN] > -- > > GENERIC > GOMP_PARALLEL > > GIMPLE > GOMP_PARALLEL > L1: > g_body > L2: > > > #pragma omp for [clause1 ... clauseN] > - > > GENERIC > GOMP_FOR body> > > GIMPLE > GOMP_FOR incr-expr, L1, L2> > L1: > g_body > L2: > > Both INIT-EXPR and INCR-EXPR are required to be in GIMPLE > form by the standard already, so there's little that need > to be done there. Keeping them in the header itself > makes it easy to reference later when we're generating > code. > > > #pragma omp sections [clause1 ... clauseN] > -- > > GENERIC > GOMP_SECTIONS > > GIMPLE > GOMP_SECTIONS > L1: > g_body > L2: > > > > #pragma omp section > --- > > GENERIC > GOMP_SECTION > > GIMPLE > GOMP_SECTION > L1: > g_body > L2: > > > > #pragma omp single [clause1 ... clauseN] > > > GENERIC > GOMP_SINGLE > > GIMPLE > GOMP_SINGLE > L1: >
Re: Details for svn test repository
Are you just I'll informed or plain . ? ( Sorry if it comes off a bit rough ). Subversion have been self hosting since a year or more, and as for significant other projects apache is one :-) ... You could have googled a bit before blurting out obviously false statements. A good place to start would be www.tigris.org where svn is hosted, ( and also contains all the other information you talk about ), the query on google was 'subversion homepage'. The main complaint on svn seem's to be a slow blame command, which is being worked on and has some improvement in the next release, ( from the mailinglist ). / regards, Lars Segerlund. On Thu, 10 Feb 2005 22:32:18 -0500 Paul Schlie <[EMAIL PROTECTED]> wrote: > Out of curiosity, although svn certainly seems attractive, are there any > concerns observing that: > > - ironically it seems that the svn isn't itself under svn control but cvs? > Has svn ever been relied upon for a significant open source project? > > - there doesn't seem to be an analogous svn web-based viewer? Is one > planned to be available in the timeframe being considered for gcc use? > > - would the intend be to pull the entire unified tree (i.e. binutils, etc.) > under svn? If not, might that create some potential complications? > > - is the svn client sw known to be cleanly build-able, reasonably robust. > and secure on all likely significant client platforms? > > (just curious, as it wasn't obvious after some basic research?) > > >
Re: New C parser to be committed
btw. what Wiki ?? / Lars Segerlund On Fri, 25 Feb 2005 11:22:11 + (UTC) "Joseph S. Myers" <[EMAIL PROTECTED]> wrote: > I intend to commit my new C parser to mainline today once it is confirmed > that the 4.0 branch has been created and after final testing against > today's mainline on x86_64-unknown-linux-gnu, powerpc64-unknown-linux-gnu > and ia64-hp-hpux11.23. > > The version to be committed is version 8 > <http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00339.html> with no further > changes. For references to the previous versions and their associated > discussion threads, see the project proposal on the Wiki. > > -- > Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ > [EMAIL PROTECTED] (personal mail) > [EMAIL PROTECTED] (CodeSourcery mail) > [EMAIL PROTECTED] (Bugzilla assignments and CCs)
