Re: Next GNUstep release?
Hi Gregory, I have entered the first (and most annoying) bug of Gorm on Windows XP into the bugtracker: https://savannah.gnu.org/bugs/?29762 that bug is not only somewhat show stopping but also somewhat difficult to reproduce as it doesn't appear all the time. I can't tell what circumstances make it appear and disappear, I tried at least to narrow this down a little bit. Please let me know if you can't reproduce it. During the next days I will enter some more bug which are less severe. Most of them would fall into the category "cosmetic" but are never the less important since they are clearly visible. cheers, Lars Am 01.05.2010 um 06:24 schrieb Gregory Casamento: Yes. On Friday, April 30, 2010, Lars Sonchocky-Helldorf wrote: Am 30.04.2010 um 22:39 schrieb Gregory Casamento: Fred, On Fri, Apr 30, 2010 at 2:51 AM, Fred Kiefer wrote: I think we should decide what to do with the planed GNUstep release. There hasn't been much progress over the last week. More bugs got reported than fixed over that time. We can either make a release now, with a lot of known issues, even some that weren't there a few weeks ago. Or delay the release indefinitely. Most of the newly reported bugs are for the Windows platform, which we didn't support that well on previous releases. Even with all this issues GNUstep is a lot more stable there then it used to be. Some of the problems which were reported are not new. They've been there for a while, but are now better documented. I am currently testing Gorm on Windows with the Windows UX Theme a little bit. Are you interested in bug reports on that? regards, Lars -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
More optimisation
Over the weekend, I committed a few more passes: -gnu-class-imp-cache Adds IMP caching for all message sends to classes. Roughly halves the cost of class message sends. -gnu-class-lookup-cache Avoids the class lookup in class message sends. Makes the time spent for sending 100,000,000 class messages drop from 56 seconds to 10 on my machine. -gnu-class-method-inline Attempts to inline class methods and method calls to super. If successful, eliminates the cost of a call. When combined with IMP caching makes a class or super message send cheaper than a (non-inline) C function call. This works best as a link-time optimisation. -gnu-loop-imp-cache Adds IMP caching to all message sends in loops. -gnu-nonfragile-ivar Eliminates the double-indirection of non-fragile ivars that's required for GCC compatibility if the ivar was in a class compiled with clang. Eliminates the indirect ivar lookup entirely if all of the superclasses are in this compilation unit (meaning that the ivar offset can only change if you recompile the module). This works best as a link-time optimisation. -gnu-objc-type-feedback- Objective-C type feedback for the GNU runtime. Adds profiling to all message sends (actually, to all calls to functions via pointer) recording what was actually called. -gnu-objc-feedback-driven-inline - Objective-C type feedback-driven inliner for the GNU runtime. Inlines calls based on the profiling info generated by the previous pass. This lets you speculatively inline calls to methods where the same method is called most of the time at a particular call site. It's probably too much effort to run the profile-driven pass on most code, but it might be useful for anything that's really CPU-bound. It's also possible that we could get some performance increase across the board by compiling -base with profiling enabled, run the test suite, and then recompile -base using the profiling info. It will also be used in LanguageKit soon, so Smalltalk code is run in the JIT initially with profiling enabled, then static compiled using the profiling info. LK automatically drops back to JIT mode and recompiles the static version if any frameworks have been modified, so it would be really great if we could include the bitcode for frameworks in the bundle somewhere - then LK could inline methods from there too. It would be really great to have some support in GNUstep Make for running these automatically... David -- Sent from my Difference Engine ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
