> Doing Google searches on Java vs C++ performance I found some Wikipedia
> etc pages, that I don't trust much. There were a few subjective
> sounding statements in there, and some comments talked about the new JIT
> that might speed Java up. The only comments I almost trust were Java
> probably
I'v been avoiding this thread because I know that as much as I know I
know about optimisation and the JIT I know there is probably more that
I don't know.
1. regardless of how fast the fasterReadInt32 method works on a
particular JVM, what is the ratio of this to the time spent operating
on that d
On Jul 27, 11:56 pm, Alan Kent wrote:
> Upon reflection of course it will be faster. The first function has to
> update the field 'i' per increment in case there is an index out of
> bounds exception. The second only updates the field once.
One quick thing: Variable i should not be a field, it
Complex? Actually Java is a pretty simple language. Ruby/Python/
Scala/Groovy all have many more features and richer syntax than Java.
The APIs are overly complex. And these APIs set a precedent for
creating over-engineered super abstract solutions which unfortunately
most people followed. I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It sounds as in a week my Droid will receive the Froyo upgrade:
http://androidspin.com/2010/07/26/froyo-to-roll-out-on-3-devices-next-week/
Now, I'm fine with it, I'm not worried about regressions etc, but my
apps will get faster. Now I'm using my
Lots of phones, tons of phones.
Someone pointed me to www.deviceanywhere.com. I haven't tried it, but it
sounds like it could be a money saver if you need to test on a lot of
devices.
On Wed, Jul 28, 2010 at 11:32 AM, Fabrizio Giudici <
fabrizio.giud...@tidalwave.it> wrote:
>
> -BEGIN PGP SI
On 28 July 2010 23:31, phil.swen...@gmail.com wrote:
> Complex? Actually Java is a pretty simple language. Ruby/Python/
> Scala/Groovy all have many more features and richer syntax than Java.
>
> The APIs are overly complex. And these APIs set a precedent for
> creating over-engineered super ab
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/28/10 17:36 , Robert Casto wrote:
> Lots of phones, tons of phones.
>
> Someone pointed me to www.deviceanywhere.com
I know it too - from the old times of JME. Indeed, I don't want to
reason in the old JME terms, that you basically needed to tes
In theory that sounds great.
But the reality is vastly different.
Each manufacturer has different hardware and software that runs on top of
it. They will build to the Android spec of course, but each implementation
is going to be different. I only know of one phone where the hardware and
software
Regarding point 2, saw a reference to the following article on Slashdot today
claiming java.io to be faster than java.nio:
http://developers.slashdot.org/story/10/07/27/1925209/Java-IO-Faster-Than-NIO
Don't have much experience with NIO and I've never been in a position of having
to optimize e
Have you tried inlining those methods in your benchmark (no field references,
as
was mentioned -- just local variables).
Alexey
2001 Honda CBR600F4i (CCS)
2002 Suzuki Bandit 1200S
1992 Kawasaki EX500
http://azinger.blogspot.com
http://bsheet.sourceforge.net
http://wcollage.sourceforge.net
Going on the size of the language spec, and the number of "special cases",
or the number of defined keywords, Java is actually *more* complex than
Ruby/Python/Scala/Groovy
Comparing Java and Scala
Scala:
everything is an object (no primitives)
any method can be us
> XML is not a scripting language!
Amen.
Moandji
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegro
On Jul 28, 2010, at 6:28 PM, Alexey Zinger wrote:
> Have you tried inlining those methods in your benchmark (no field references,
> as was mentioned -- just local variables).
hotspot aggressively inlines. No need to inline but you must warmup the bench.
Variables will be cached regardless of s
As clearly demonstrated by apache-commons' jelly (
http://commons.apache.org/jelly/faq.html)
(popularised in Maven1)
On 28 July 2010 17:45, Moandji Ezana wrote:
> > XML is not a scripting language!
>
>
> Amen.
>
> Moandji
>
> --
> You received this message because you are subscribed to the Googl
Replies inline. TL;DR: These features either (A) suck, (B) are coming
in java 7 anyway, (C) aren't elegant, or (D) are nice, but not even
remotely close to nice enough to accept the lack of tool support.
I lve me some new JVM languages in the vein of java itself, but so
far everyone and their
How is that an oxymoron? Stab seems to be following the same path as
Fantom: A (faulty) conclusion that java's lack of certain "simple"
features (mistake #1: Adding those features while remaining compatible
with java code that's already out there is not simple, even if you
think it is) can be easil
Ah, *JAVAC*. But that's not *java*, which was claimed. Java source
files are easy to compile in a multi-threaded environment, and very
fast to boot.
For every file, you need to do:
1. Build an AST. This is 100% independent of other source files, and
thus can be multicored trivially.
2. Extract a
This is not a valid performance analysis.
You didn't mention "and that's when the hotspot compiler kicked in"
even once, for example.
On Jul 28, 6:56 am, Alan Kent wrote:
> In case anyone cares, did a bit of testing and found:
>
> (1) Running in Eclipse using "Run" was about 3 times slower than
> I was looking into array bounds checks, and what I found via Google
> indicated that hotspot leaves in array bounds checks as there was only a
> minor performance improvement found in practice. This lead me to wonder
> if there is a faster way to do the code since I would be doing lots of
> arra
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/28/10 20:02 , Casper Bang wrote:
>
> It's hard to know without your benchmarking suite, but it strikes
> me that the above, though unsafe, has a good chance of mapping to
> efficient native code.
BTW - if I'm not wrong, a few months ago Kohsuke b
On Jul 29, 2010, at 2:12, Fabrizio Giudici > wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/28/10 20:02 , Casper Bang wrote:
It's hard to know without your benchmarking suite, but it strikes
me that the above, though unsafe, has a good chance of mapping to
efficient native code.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/28/10 21:37 , Stuart McCulloch wrote:
>>
> http://weblogs.java.net/blog/kohsuke/archive/2008/03/deep_dive_into.html
That's
>
it.
PS My sense of time is getting completely distorted. I believed it was
only a few months ago, and it was more than
This is my primary objection to Fantom:
"The primary reason we created Fantom is to write software that can
seamlessly run on both the Java VM and the .NET CLR"
I have zero interest in writing source code that can be moved back and
forth between JVM and .NET CLR runtime. Given JVM is very well
su
Not to mention that there's already the IKVM project. When I was in the C#
world about 4 years ago and had a pressing need to have some Java and .NET
interoperability, I was able to use IKVM as a library. I could code in each
language's native tool chains, performance was satisfactory, and it
Two points:
First, I'm just getting a second Nexus One although it may end up
being locked to Vodafone UK (my first came direct from Google). I am
also seriously considering picking up a couple of older phones
specifically for testing on earlier platforms and less powerful
hardware.
Second, this
> Perhaps I should put it differently: Other than for folks who are
> intricately familiar with C#'s syntax, why would I get any more
> excited about stab than I would about Fantom? What does stab do that's
> leaps better than Fantom?
I don't know, just wanted to point out a flaw in your logic/sen
Replace the stock recovery image with Nandroid or use ROM manager or
so, that way you can easily flash and roll back Android versions.
There are also utilities which allows you to under- and over-clock the
device. In CyanogenMod 6.0 (AOSP/Froyo) you also get a setting for
enabling/disabling the tra
ok, play then :)
haven't used either, just scanned them.
but perhaps roo made OSGi more manageable. I say just use spring and
enforce the spring modules in your build and you get 80% of the
advantages of OSGi w/o all the pain.
On Jul 28, 10:01 am, Stuart McCulloch wrote:
> On 28 July 2010 23:
Not sure I agree with that...
The big benefit of OSGi is that module loading is dynamic, services can be
hotswapped and can register/unregister at runtime
Modularity is almost just a pre-requisite so that it can all be done sanely
:)
Interestingly though, spring does have support for some of this
+1.
Clearly, the complexity in real life Java projects is in the libraries/
frameworks/APIs.
No one has a hard time writing a for loop or inheriting a class in
Java.
I've never gotten frustrated writing new code (be it C, Java, C#,
Python, Perl, x86, etc). It's always, why is some library or fra
On Jul 28, 2:43 pm, Casper Bang wrote:
> 1) See that what I don't follow. Who cares what runtime is underneath?
> Very very few people should care about this, what they should care
> more about is having flexibility and choice i.e. it's nice to see
> Dalvik come in to save the day for mobile "Java
Unless you are writing hello world for living then I believe for most
project complexity are in
the business logic. If framework stands on your way, you should replace it.
Language is not a magic wand. I can write shitty code regardless where I
write it
and what language I write it in.
On Wed,
Link just seems to take me to his frontpage for me.
This is a good start, though: the -XX:-PrintCompilation option will
print the name of each method as it gets jit-compiled. It doesn't
actually show what native code is produced, but at least you can work
on your benchmark a little bit more.
That
On 29/07/2010 3:05 PM, Reinier Zwitserloot wrote:
That's not to say what you're doing is at all useful, really. You
can't microbenchmark code for the JVM. End of discussion. Stop doing
it.
Agreed completely. Microbenchmarks are interesting, but dangerous to
rely on. It was a loop run 100
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/29/10 07:47 , Alan Kent wrote:
> On 29/07/2010 3:05 PM, Reinier Zwitserloot wrote:
>> That's not to say what you're doing is at all useful, really.
>> You can't microbenchmark code for the JVM. End of discussion.
>> Stop doing it.
>>
>
> Agreed c
Microbenchmarks are as useful as any other type of benchmarking. The problem
is, they are very very very difficult to get right. You need to do a lot of
work to validate the results you get from any benchmark, large or small. I've
missed the beginning of the conversation so I never saw all of th
37 matches
Mail list logo
