Re: test if there is a gain
On Wed, Mar 30, 2005 at 12:27:18PM +0200, Michael Koch wrote:
> On Wed, Mar 30, 2005 at 12:10:28PM +0200, Daniele Cruciani wrote:
> > On Tue, Mar 29, 2005 at 08:24:26PM +0200, Michael Koch wrote:
> > > On Tue, Mar 29, 2005 at 07:49:58PM +0200, Daniele Cruciani wrote:
> > > > Il giorno mar, 29-03-2005 alle 18:02 +0200, Michael Koch ha scritto:
> > > > > On Tue, Mar 29, 2005 at 05:35:55PM +0200, Daniele Cruciani wrote:
> > > > > > would it be done as
> > ....
> > > > > > hope java-gcj-compat will be in Debian asap, at least in experimental.
> > > > >
> > > > > What do you wanna gain with this? I see no real benefit in this over the
> > > > > current situation. eclipse--ecj will be in debian when eclipse gets in.
> > > >
> > > > no, no gain, it is just for testing (testing if there is a gain in using
> > > > precompiled jars).
> > > >
> > > > asap == when eclipse-ecj will be in debian && gcc-4.0 is released ...
> > >
> > > I see no reason to imidiately switch everything to eclipse-ecj and
> > > gcc-4.0 when it hits debian. We live from freedom of choice and
> > > mono cultures are bad.
> >
> > Absolutely, it is just that, another choice. I have not tried
> > free-java-sdk, but as I can read in description it make a choice in
> > tool, and it is just a package with the same aim of java-gcj-compat.
>
> No, both have different goals. java-gcj-compat provides a compatibility
> layer for GCJ to make it act like a JDK. free-java-sdk is more a general
> package that allows you to select the tools you want. The toils have to
> be JDK compatible already. It just makes the choice easier. But this
yes, it is more complex the thing due in java-gcj-compat, but
free-java-sdk Depends: jikes-sablevm, fastjar, sablevm,
classpath-tools. I read it as a special selection of tools. But (I
repeat) I did not installed this package.
> choice is bad for building debian packages (not for running them). WE
> really need defined build environment for a package. A package has to
> build with a special VM. I doesnt matter which one. It just matter that
> the build is reproducable easily on different systems in case of
> problems.
ok. It was not that the matter.
I just say that a good example on testing ahead of time compiled code
performance over interpreted bytecode is to build a debian java
package with ecj native and next with ecj over sablevm, or over kaffe
or jdk, and see if there are real gain in time and ram required for
building.
Daniele.
Reply to: