Hi, "Mikael Djurfeldt" <[EMAIL PROTECTED]> writes:
> Certainly. It's just that Guile has, to some extent, and with the > exception of a recent restructuring of the GC, had this tradition of > sacrificing performance for all kinds of "idealistic" goals with the > promise of increased future efficiency, getting more and more sluggish > all the time. (It was quite efficient originally.) I know, and that has been a real concern for me. Interestingly, porting Guile to BGC has been one of these "idealistic" goals for a number of years. :-) > If BGC holds the promise of efficiency, it might be nice to achieve > this before throwing out the current GC which is, btw, not > unreasonably unmaintainable or unportable. Note: this is an _experiment_, whose purpose is precisely to get a better understanding of the feasibility of the migration, of the gains from a user perspective, and of the performance implications. Personally, I'm inclined to move to GBGC, _if_ the performance overhead is acceptable, that is, if the maintainability and robustness gains overweight the performance cost. But (i) this is only my personal opinion, and (ii) I don't have serious performance results at this time. This clearly needs to be evaluated before we can consider BGC as an option. Also, when discussing performance, one has to keep in mind that it is very unlikely that anybody will ever improve the performance of Guile's GC (I did try, had to gave, and got motivated by BGC ;-)). On the contrary, GBGC is constantly being improved, and performance seems to be the main focus of Hans currently. BTW, I did not mean to be insulting about the current GC, but a GC written in C (be it Guile's or Boehm's) is _not_ something easily maintainable. > The only point I would like to make is that it is silly to care too > much of the amount of thinking which has gone into BGC and its broad > usage if, in fact, it doesn't add anything of real value to Guile. My feeling is that it does add value, but we need to weight the pros and cons. >> The fact that Bigloo uses BGC also tends to reassure >> me: if Guile can someday perform as bad as Bigloo compiled code (or >> simply, as bad as its interpreter), then I'll be very happy. ;-) > > But current sluggishness is not mainly due to the current GC. In > fact, for a scheme interpreter there might be advantages of using a > customized solution. One thing which would boost performance > tremendously would be to integrate Keisuke's guile-wm code, or > something a la QScheme. Exactly, that's the point I was trying to make. If, for instance, Bigloo's interpreter outperforms GBGC, then this means that there is room for optimization in Guile's interpreter. More generally, Guile-VM (or some other form of compilation) is the way to go if we want to noticeably improve performance. Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
