Agree. Just don't want this to lead to the conclusion we *shouldn't*
somehow help recommend good JVM settings or compile-time optimization.
And I don't think, in the end, anyone is saying that.
On Sat, Sep 5, 2009 at 12:28 AM, Ted Dunning wrote:
> I am sure that our Sparse Vector stuff is at least
I am sure that our Sparse Vector stuff is at least twice as slow as it
should be.
My preliminary experiments indicate that we should be able to get within
about a factor of 2 of the speed of a DenseVector (ish). I am pretty sure
our current SparseVector is a long ways from there. Shashi's experi
-server is the default on "server" class machines. But as you point
out, even "non-server" machines are pretty powerful. The server
defaults are appropriate so I think it is right to explicitly select
it, regardless.
I agree it's hard to figure out the right GC settings. That is all the
more reaso
If it were just a few seconds. In my experience, really exploring
optimization settings takes hours of scanning the parameter space.
That same amount of time could easily double the speed of our sparse
vectors.
On Fri, Sep 4, 2009 at 11:31 AM, Sean Owen wrote:
> 10% is certainly nothing to
> s
On Sep 4, 2009, at 1:31 PM, Sean Owen wrote:
(just to make sure everyone's on the same page, given the title of
this thread -- these are not javac optimizations)
I do think it's worth cataloging recommended JVM flags for runtime
use. My current recommendations are:
-server
-da -dsa (I think t
(just to make sure everyone's on the same page, given the title of
this thread -- these are not javac optimizations)
I do think it's worth cataloging recommended JVM flags for runtime
use. My current recommendations are:
-server
-da -dsa (I think these are redundant since assertions are off by
de
In java 1.6 (recent releases) the AggressiveOpts flag does some escape
analysis and other optimizations that could help some kinds of code.
See
http://java.sun.com/performance/reference/whitepapers/tuning.html#section4.2.4
My own feeling is that changes less than 2x in performance are not very
ex
On Sep 4, 2009, at 6:03 AM, Sean Owen wrote:
Yeah I tried a load test with and without and saw virtually zero
difference in run time.
Returning briefly to the issue of optimization -- would still somehow
like to work in ProGuard. Certainly a subset of its optimizations
would not even interfere
Yeah I tried a load test with and without and saw virtually zero
difference in run time.
Returning briefly to the issue of optimization -- would still somehow
like to work in ProGuard. Certainly a subset of its optimizations
would not even interfere with debugging symbols. For instance, if
you're
Yeah it definitely interferes. Debug symbols don't work. You wouldn't
use it in development, only in your 'bug-free' production release.
Stack traces still 'work' though you might find some surprises due to inlining.
On Fri, Sep 4, 2009 at 12:17 PM, Shalin Shekhar
Mangar wrote:
> Wouldn't that mes
On Fri, Sep 4, 2009 at 4:39 PM, Sean Owen wrote:
> This flag actually has no effect in javac other than letting the
> compiler inline constants. (It's JIT in the JVM at runtime that does
> most of the optimization.) I'm actually surprised it had any
> observable effect here, and wonder if this is
On Fri, Sep 4, 2009 at 4:39 PM, Sean Owen wrote:
>
> Real byte-code optimization comes from ProGuard. I use it constantly
> but had to remove it from our build because I don't think Maven plays
> nice with it and maybe there are license issues. It's a real shame to
> lose performance because of s
No it's definitely still there, and does have some tiny effects.
On Fri, Sep 4, 2009 at 12:15 PM, Shalin Shekhar
Mangar wrote:
> I thought Sun had removed that flag?
>
> Anyways, most of the useful optimization is done by the JVM at runtime.
> There's a reason it is called a "Hotspot" VM.
On Fri, Sep 4, 2009 at 4:30 PM, Robin Anil wrote:
> I saw that the maven compile:compile plugin didnt have the optimize=true
> enabled for mahout
> so i ran an experiment. Forget about the machine specs. Its run on the same
> system
>
> Before enabling optimize:
> Compile Time
> Core : 50 secs
>
This flag actually has no effect in javac other than letting the
compiler inline constants. (It's JIT in the JVM at runtime that does
most of the optimization.) I'm actually surprised it had any
observable effect here, and wonder if this is consistently
reproducible?
I certainly favor setting this
I saw that the maven compile:compile plugin didnt have the optimize=true
enabled for mahout
so i ran an experiment. Forget about the machine specs. Its run on the same
system
Before enabling optimize:
Compile Time
Core : 50 secs
Examples 10 secs
FPGrowth 50K transactions with minSupport 20%
Time
16 matches
Mail list logo
