On 7/29/11 3:23 AM, Gilles Sadowski wrote:
> Hello.
>
>>> [...]
>>>
>>> The idea is to have "interleaved" calls to the candidate
>>> implementations, so
>>> that (hopefully) they will be penalized (or benefit) in the same
>>> way
>>> by what
>>> the JVM is doing (GC
Hello.
> >
> > [...]
> >
> > The idea is to have "interleaved" calls to the candidate
> > implementations, so
> > that (hopefully) they will be penalized (or benefit) in the same
> > way
> > by what
> > the JVM is doing (GC or JIT compilation or ...) while the
> >>>
On 7/26/11 3:52 AM, Gilles Sadowski wrote:
> Hello.
>
> [...]
>
> The idea is to have "interleaved" calls to the candidate
> implementations, so
> that (hopefully) they will be penalized (or benefit) in the same
> way
> by what
> the JVM is doing (GC or JIT compilati
Hi.
> >>I'm willing to help on this if you want.
> >What do you propose?
> You mentioned the need for people to review/try the piece of code
> you've posted. I haven't done yet, but I'm happy to.
Yes, please try it, and report unexpected results. Thank you!
[I'll send you the Java file in a separ
Le 27/07/11 12:05, Gilles Sadowski a écrit :
Hello.
I'm willing to help on this if you want.
What do you propose?
You mentioned the need for people to review/try the piece of code you've
posted. I haven't done yet, but I'm happy to.
As for japex being too heavy. I agree, I didn't realize it n
Hello.
> I'm willing to help on this if you want.
What do you propose?
> Meanwhile, have you had a
> look to existing frameworks, such as japex (http://japex.java.net/)?
> [...]
I hadn't; I have now. It looks nice. I didn't think of something as
elaborate (charts, etc.) but rather a small utili
Hi,
I'm willing to help on this if you want. Meanwhile, have you had a look
to existing frameworks, such as japex (http://japex.java.net/)?
Also, there is some interesting stuff on the web
http://www.ibm.com/developerworks/java/library/j-benchmark1/index.html
I have other electronic papers, I'll
Hello.
> > > > [...]
> > > >
> > > > The idea is to have "interleaved" calls to the candidate
> > > > implementations, so
> > > > that (hopefully) they will be penalized (or benefit) in the same
> > > > way
> > > > by what
> > > > the JVM is doing (GC or JIT compilation or ...) while the
> > > >
Hi Gilles,
- Mail original -
> Hello.
>
> > > [...]
> > >
> > > The idea is to have "interleaved" calls to the candidate
> > > implementations, so
> > > that (hopefully) they will be penalized (or benefit) in the same
> > > way
> > > by what
> > > the JVM is doing (GC or JIT compilation
Hello.
> > [...]
> >
> > The idea is to have "interleaved" calls to the candidate
> > implementations, so
> > that (hopefully) they will be penalized (or benefit) in the same way
> > by what
> > the JVM is doing (GC or JIT compilation or ...) while the benchmark
> > is
> > running.
> >
> > Does
- Mail original -
> Hello.
Hi Gilles,
>
> Finding myself repeatedly writing the same few lines when trying to
> figure
> out which of several implementations of some functionality was
> running
> faster, I wonder wether it would be interesting to add a little
> utility in
> the "test"
Hello.
Finding myself repeatedly writing the same few lines when trying to figure
out which of several implementations of some functionality was running
faster, I wonder wether it would be interesting to add a little utility in
the "test" section of the source tree. Something like the following:
-
12 matches
Mail list logo
