Re: Optimizations.

From: Narvi (narvi_at_haldjas.folklore.ee)
Date: 05/15/03

  • Next message: Narvi: "Re: Crypted Disk Question" 
    Date: Fri, 16 May 2003 00:26:19 +0300 (EEST)
To: Marcel Moolenaar <marcel@xcllnt.net>

    On Thu, 15 May 2003, Marcel Moolenaar wrote:

    > On Thu, May 15, 2003 at 02:30:33PM +0200, Pawel Jakub Dawidek wrote:
    > > Hello hackers...
    > >
    > > IMHO optimization in FreeBSD's code has too low priority.
    > > Maybe is time to think about some 'optimiztion team' creation?
    >
    > I think I don't want to see this happen based on professional
    > experience. My biggest concern is that it becomes a crusade.
    > For if your focus is performance, you pretty much loose track
    > of everything else. If not, then obviously you haven't been
    > focussing.
    >

    Well, supposedly any such team would need to start by creating a set of
    tools and benchmarks that could be used to quantify perfomance, get buy-in
    from the project that these give good measures (iterate until done) and
    then set up a bunch of machines to track there are no regressions?
    Followed by then starting to work towards eliminating problems 8-)

    > Don't get me wrong. Optimizing is a good thing, when done at the
    > right time for the right reasons and in the right way. Having
    > an optimization team created out of thin air can only lead to
    > round-table discussions that boil down to "Hi, I'm Marcel. I like
    > to optimize small objects" and before you know it all hell breaks
    > loose for a barely measurable performance change.
    >
    > If you set yourself some simple goals and keep it high-level, then
    > we can all get used to the idea and we will probably find other
    > opportunities while we go. The end result can be much the same as
    > you try to achieve now, except that it has a bigger chance to be
    > integrated rather than some weird bunch on the side that plays
    > with compiler options "and shit".

    nah, don't be too hard on them. they are volunteering for a large amount
    of hard work 8-)

    >
    > Just a thought,
    >
    > --
    > Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
    >

    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

  • Next message: Narvi: "Re: Crypted Disk Question"

    Relevant Pages

    • Re: Optimizations.
      ... >> IMHO optimization in FreeBSD's code has too low priority. ... then set up a bunch of machines to track there are no regressions? ... > an optimization team created out of thin air can only lead to ... of hard work 8-) ...
      (freebsd-performance)
    • Profile Guided Optimizations on VS2005 Std
      ... After reading a bunch of articles saying that Profile Guided ... least Link Time Code Generation for improving app speed, ... -> Whole Program Optimization, ...
      (microsoft.public.vsnet.general)
    • Re: A taxonomy of types
      ... bunch of electrons crowding at p-n junctions... ... optimization problem which complexity grows as the abstraction level drops. ... Because this problem is seemingly incomputable, it is human programmers ... The compiler designers knew it much better than you. ...
      (comp.lang.misc)
    • Re: Why is bsxfun *faster* for power and hypot operations?
      ... optimization that occurred for the m-file actually ... It would be worth reporting the details to technical support. ... you run the function a bunch of times before doing the timing? ...
      (comp.soft-sys.matlab)