[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] Building Axiom twice
From: |
Waldek Hebisch |
Subject: |
Re: [Axiom-developer] Building Axiom twice |
Date: |
Thu, 23 Nov 2006 14:06:38 +0100 (CET) |
root wrote:
> axiom could be so much faster if we got the gcl_collectfn mechanism
> fully re-implemented. the lisp type optimization code can eliminate
> hundreds of intructions per function call and axiom lives and breathes
> by function calling. however to fully take advantage of that you
> either need to do multiple passes or cache the type information
> from previous builds. doing this in parallel makes my hair hurt.
>
Will this accelerate Spad compiler or is it only usefull to algebra?
> parallel builds cause the make to go marginally faster but my
> feeling is that the time-to-build is not important for two reasons.
>
> first, a properly done make tree need only rebuild changed files
> and their dependent files. when builds used to take 3 weeks from
> scratch i was able to build changes to the system in 1/2 hour or so
> for small changes using the current makefile structure. that is the
> whole reason to use make in the first place. otherwise it just makes
> sense to have a linear script.
>
> second, only developers care about build time. the end user should
> never see it (or maybe see it once). i'd rather spend a whole day
> doing a build and get a highly optimized algebra system than spend
> 1 hour and get a slow algebra system. and that's saying a lot because
> all i ever do is build and rebuild the damn thing.
>
> fast algebra is much more important than fast builds.
>
I feel that you are misallocating resources. For most of users Axiom
is "fast enough". OTOH if you compare polynomial factorization in
Axiom with NTL you will notice that Axiom is slower and the gap get
wider on bigger inputs. NTL is written in C++, but this gives only
little gain. The main reason is that NTL uses algorithm with better
asymptitic complexity. So, Axiom also needs faster algorithms
and here build time matters very much.
I would say that if re-making takes more than 1 second then it is
worth working on shortening build time -- while you time saving
from 1 second re-make compared to say 15 seconds is negligible
longer re-make distracts developers attension, causing much bigger
indirect loss.
Also, good practice requires full build before commiting a patch,
so time of full build matters too. And do not forget about testing
-- we should test freshly build system.
Do not get me wrong: it is nice to have fast algebra. But you need
developers to make algebra faster, and fast build are necessary to
effectively use developers time (and to get them in the first place).
--
Waldek Hebisch
address@hidden
- Re: [Axiom-developer] Building Axiom twice, (continued)
- Re: [Axiom-developer] Building Axiom twice, Waldek Hebisch, 2006/11/22
- Re: [Axiom-developer] Building Axiom twice, root, 2006/11/22
- Re: [Axiom-developer] Building Axiom twice, Gabriel Dos Reis, 2006/11/22
- Re: [Axiom-developer] Building Axiom twice, Waldek Hebisch, 2006/11/22
- Re: [Axiom-developer] Building Axiom twice, Gabriel Dos Reis, 2006/11/22
- Re: [Axiom-developer] Building Axiom twice, root, 2006/11/22
- Re: [Axiom-developer] Building Axiom twice, Gabriel Dos Reis, 2006/11/22
- Re: [Axiom-developer] Building Axiom twice, Gabriel Dos Reis, 2006/11/22
- Re: [Axiom-developer] Building Axiom twice,
Waldek Hebisch <=
- Re: [Axiom-developer] Building Axiom twice, Martin Rubey, 2006/11/25
- Re: [Axiom-developer] Building Axiom twice, Waldek Hebisch, 2006/11/22
- Re: [Axiom-developer] Building Axiom twice, Gabriel Dos Reis, 2006/11/22
- Re: [Axiom-developer] Building Axiom twice, Waldek Hebisch, 2006/11/24
- Re: [Axiom-developer] Building Axiom twice, Waldek Hebisch, 2006/11/24