Walter Bright escribió:
> "Dave" <Dave_member@pathlink.com> wrote in message news:dvkbvk$2hn5$1@digitaldaemon.com...
>> IIRC, there was some argument a while back that they weren't running the tests
>> long-enough to take advantage of Hotspot. Since then they've increased the
>> length of the tests to account for that (and startup time is subtracted from
>> those results as well, I believe).
> 
> I attended a seminar at SDWest which talked about the "myth" of slow Java. Turns out, the code is interpreted for a while, then it gets compiled, then certain things can *invalidate the compiled code* so it goes back to interpreting it, then compiling it again, etc.
> 
> Is it invalid to include all these compile times, even if they occur well into the execution, as part of the benchmark time? I don't think so. At the end of the day, the time the user is sitting their waiting is what matters, and that will include all the startup, interpretation, compilation and recompilation times.

I agree 100%. Users in the end, can and will note many of these background "moves" of the VM. The benchmark for testing Java vs. other languages in terms of perceivable speed should be: start the timer just before running the app and stop the timer when terminating it (of course, taking all the cares that are needed to be fair).

> The presenter confidently predicted that in 10 years, Java will outperform C in the general case. Color me skeptical. 

Amen! (this is truly unbelievable)

In article <dvkklp$2pl$1@digitaldaemon.com>, Walter Bright says...
>
>"Dave" <Dave_member@pathlink.com> wrote in message news:dvkbvk$2hn5$1@digitaldaemon.com...
>> IIRC, there was some argument a while back that they weren't running the
>> tests
>> long-enough to take advantage of Hotspot. Since then they've increased the
>> length of the tests to account for that (and startup time is subtracted
>> from
>> those results as well, I believe).
>
>I attended a seminar at SDWest which talked about the "myth" of slow Java. Turns out, the code is interpreted for a while, then it gets compiled, then certain things can *invalidate the compiled code* so it goes back to interpreting it, then compiling it again, etc.

That explains a lot... I had read somewhere a while back that some parts of earlier VM's had to be 'detuned' because optimizations based on real-time info. were often counter-productive and/or causing bugs in apps. I guess in some cases they decided to invalidate cached code rather than 'detune' it.

>
>Is it invalid to include all these compile times, even if they occur well into the execution, as part of the benchmark time? I don't think so. At the end of the day, the time the user is sitting their waiting is what matters, and that will include all the startup, interpretation, compilation and recompilation times.
>
>The presenter confidently predicted that in 10 years, Java will outperform C in the general case. Color me skeptical.
>

It's funny, but I've read predictions like that every year for the last 10 <g> And for many things I think the original JIT's were still the best.

From what I gather, there has been huge amounts of R & D into the problem from all kinds of organizations - I figure by now if they haven't figured it out there are reasons other than for trying. A manager I know likes to call stuff like that "polishing the turd" <g>

Thomas Kuehne wrote:
> One huge advantage of VMs is their design:
> * lot's of prior experiences with all sorts of architectures and
> libs

Well, this might only be a matter of time.

> 
> * a clean sheet, thus no cludges for supporting applications from the parent architecture
> 

Actually D is doing very well here too. A normal end-user application coder doesn't need to care about all the low level stuff.

> * a strong seperation between normal applications and the used hardware(including the CPU) -> "smart" phone applications

True.

> * most important: the potential to design according to todays
> requirements and available technology instead of those from
> the 70th and 80th
> (the C99 standart only specifies how to access files but not
> how to list directories?!)

D is able to fix most of these issues without any VMs. Even though you have a decent VM today, tomorrow someone will invent a new thingie that suddenly everybody needs. Updating an existing VM/language isn't that painless. Java has a huge load of deprecated junk for backwards compatibility.

> 
> There are domains where VMs make sence, but you are right
> a secure modular kernel could be used in most places where
> Java and .NET are currently used. One nice point about
> the Java and .NET runtimes are the large amount of
> OS/architecture agnostic tools/objects/functions.
> 

Certainly there are domains where a VM'ed language suits better than bare metal access alternative but unfortunately this "managed code" is often used excessively.

If I recall correctly, some vendors even use C# in basic end-user GUI-based configurators for device drivers. These programs usually require you to reboot, when you change something. I cannot see, why a VM written in C + a wrapper library using C/C++ GUI-bindings + a byte code program performs any better than a modular kernel + script interpreter and GUI libraries written in D + a high level configurator script. The latter one starts up much faster, eats only a small fraction of memory compared to the bloaty VM-version and is actually more light-weight in terms of LOC.

-- 
Jari-Matti

Walter Bright wrote:
> "Dave" <Dave_member@pathlink.com> wrote in message news:dvkbvk$2hn5$1@digitaldaemon.com...
>> IIRC, there was some argument a while back that they weren't running the tests
>> long-enough to take advantage of Hotspot. Since then they've increased the
>> length of the tests to account for that (and startup time is subtracted from
>> those results as well, I believe).
> 
> I attended a seminar at SDWest which talked about the "myth" of slow Java. Turns out, the code is interpreted for a while, then it gets compiled, then certain things can *invalidate the compiled code* so it goes back to interpreting it, then compiling it again, etc.
> 
> Is it invalid to include all these compile times, even if they occur well into the execution, as part of the benchmark time?

Not at all.  In fact, a similar issue came up during the C++/C#/Java template comparison that Herb Sutter did.  Someone said they'd heard C# was faster than C++, and Herb felt honor bound to respond.  The gist of Herb's response was this: he said that C++ was heavily optimized at compile time and since C++ has been around for quite a while, we've gotten quite good at optimizing it.  C#, on the other hand, is hardly optimized at all at compile time, and since the JIT process needs to be near instantaneous to avoid run-time stutter, almost no optimizations take place during run-time compilation as well.  Assuming that Java is similar to C# in this respect (which seems quite likely), I would be skeptical of any claims that Java could out-perform C++, as they have similar semantics and C++ is far more heavily optimized.  If Java could make one performance claim over C++ it would be that manipulating references could be more efficient than passing copies, but D could make the same claim... and can also take advantage of the optimizations that contribute the performance of C++.


Sean

"Dave" <Dave_member@pathlink.com> wrote in message news:dvksli$ihh$1@digitaldaemon.com...
> From what I gather, there has been huge amounts of R & D into the problem
> from
> all kinds of organizations - I figure by now if they haven't figured it
> out
> there are reasons other than for trying. A manager I know likes to call
> stuff
> like that "polishing the turd" <g>

Certainly, Sun has poured enormous resources into research trying to find ways to make it faster. At some point, though, a point of diminishing returns will be reached.

In article <dvhohr$asa$1@digitaldaemon.com>, Walter Bright says...
>
>I'm no expert on Java programming, but I get this question a lot: "What compelling reason does D have that would entice a Java programmer to switch to D?"

Very few, I think.
I've thought about it, and in the end I think Java has some good points that
can't  be beaten so esily:

- Compile once and run everywhere. I write, compile and test my program with my Windows PC, then download it in a Linux-based CN, a VxWorks-based terminal and a WinCE one (last two with an ARM processor). The application works the same on the 4 platform, the user doesn't notice. You only have to care for a few things, like case sensitiveness for file names, or not using the latest whistles & bells not present in that particularily old VM.

- Swing. Once you get used to it, you think you can't work without it. It's extremely flexible, making possible to write a 5-lines GUI for a quick hack, or a big application with custom appearence. And it can scale down to little targets, as a StrongArm 133MHz with 32 MB of RAM, with some effort.

- The library. You can make almost everything with the base standard library. It's big, but it works. Here in Italy we say: "non capita, ma se capita..." ("it won't happen, but if it happens..."), so from a programmer's point of view, more is better.

Java is slower, but who cares? My customers don't know I use Java, they don't notice the 30 ms delay in menu showing. CPU intensive parts are JIT compiled, so the overall overhead of the VM results in an impercettible delay in GUI responsiveness. My GUIs are still faster than their users.

Something that D can do and Java don't is system programming. Pointers,
assembler, the full C api, and so on are something the system programmer would
keep handy.
What D has, that Java don't, is a better language. More complex, but more
powerful. Something I miss in Java:

- the version{} construct
- properties
- switch-case with strings
- RAII
- array slices
- the 'ditto' keyword in javadoc
- true typedefs (if only they worked in D...)
- I think in the long period I will use contracts
- maybe I'll use opApply() with foreach

D templates are better than Java generics (and than C++ templates), but I don't write Java generics everyday (nor C++ templates), I mostly use them. Their use is similar, so I don't think it will add something to D.

Ciao

---
http://www.mariottini.net/roberto/

In article <dvkklp$2pl$1@digitaldaemon.com>, Walter Bright says...
>
>Is it invalid to include all these compile times, even if they occur well into the execution, as part of the benchmark time? I don't think so. At the

No doubt it is valid to include that. Not only user time but time it takes from other processes on a heavly used system.

It's hard to measure how much overhead this incurs in a real-life program. Sun has -Xprof which can give some info. but I've not seen this used on production programs.

>end of the day, the time the user is sitting their waiting is what matters, and that will include all the startup, interpretation, compilation and recompilation times.
>

On one 80 line program I have here that takes 1.5 secs to run, the profiler says compilation is 1% of the total, and that doesn't seem to include the time to do the runtime profiling for the optimizer. That's one small program that has one main loop calling one function. On large real-world programs with many loops, functions, selective finalization and all kinds of references floating around and being moved by the GC, the reprofiling/recompilation probably happens a lot more.

Since they've been perfecting this stuff for years, IMO there's pretty compelling evidence that there may be intractable problems with this type of approach.

>I agree. The job of the operating system is to sandbox processes so that when one dies, it is isolated from all the others, which it does a reasonably good job doing (but it could do better). The CPU hardware certainly is set up to support this. You can even run Windows entirely in a virtual machine!
>

The real test of a language/technology is "eating your own dogfood". And its interesting to note that MS seem to be pulling back abit from putting the clr very deep into the os. Rather .net classes are just wrappers for c++. A much better approach is D plus DMDScript.

Will DMDScript implement the forthcoming ECMAScript v4 spec which hopefully will make it a decent all round scripting language. It seems like scripting languages are converging on a certain set of semantics.

In article <dvld6m$1f37$1@digitaldaemon.com>, Sean Kelly says...
>
>similar semantics and C++ is far more heavily optimized.  If Java could make one performance claim over C++ it would be that manipulating references could be more efficient than passing copies, but D could make the same claim... and can also take advantage of the optimizations that contribute the performance of C++.
>

But C++ can also pass (and return) by reference if needed (obviating the need to
call copy ctors), correct? And it can allocate class objects on the stack, which
is an option Java doesn't have.

>Sean

Walter Bright wrote:

> "Jari-Matti Mäkelä" <jmjmak@utu.fi.invalid> wrote in message news:dvk2v1$1rf1$1@digitaldaemon.com...
> 
>>Using VMs is not a solution, it's a terribly perverted workaround. The
>>real problem is that current operating systems are far too monolithic
>>and hang/corrupt the whole machine when one unfortunate process
>>dies/does something bad.
> 
> 
> I agree. The job of the operating system is to sandbox processes so that when one dies, it is isolated from all the others, which it does a reasonably good job doing (but it could do better). The CPU hardware certainly is set up to support this. You can even run Windows entirely in a virtual machine! 
> 
> 
Taking this a step further, look at the massively scalar CELL processor.

Which do you think could harness that power better?
A VM or a compiled language? (Note that not every VM needs to be as complicated as the JVM).

Obviously the choice of language itself matters a great deal, but the VM approach certainly has a step up in this reguard.

This is not to impugn D, just to point out the larger picture...

-DavidM