www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - On C/C++ undefined behaviours

reply bearophile <bearophileHUGS lycos.com> writes:
Three good blog posts about undefined behaviour in C and C++:
http://blog.regehr.org/archives/213
http://blog.regehr.org/archives/226
http://blog.regehr.org/archives/232

In those posts (and elsewhere) the expert author gives several good bites to
the ass of most compiler writers.

Among other things in those three posts he talks about two programs as:

import std.c.stdio: printf;
void main() {
    printf("%d\n", -int.min);
}

import std.stdio: writeln;
void main() {
    enum int N = (1L).sizeof * 8;
    auto max = (1L << (N - 1)) - 1;
    writeln(max);
}

I believe that D can't be considered a step forward in system language
programming until it gives a much more serious consideration for
integer-related overflows (and integer-related undefined behaviour).

The good thing is that Java is a living example that even if you remove most
integer-related undefined behaviours your Java code is still able to run as
fast as C and sometimes faster (on normal desktops).

Bye,
bearophile
Aug 20 2010
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
What are these Java programs for the desktop that run fast? I haven't
encountered any, but maybe that's just because I didn't try them all
out. Eclipse takes at least 20 seconds to load on startup on my quad
core, that's not very fast. On the other hand, CodeBlocks which is
coded in C++ and has  a few dozen plugins installed runs in an
instant.

Just firing up a dialog in eclipse takes a good second, maybe two. So
give me the names of those fast Java applications, pls. :)

On Fri, Aug 20, 2010 at 6:38 PM, bearophile <bearophileHUGS lycos.com> wrot=
e:
 Three good blog posts about undefined behaviour in C and C++:
 http://blog.regehr.org/archives/213
 http://blog.regehr.org/archives/226
 http://blog.regehr.org/archives/232

 In those posts (and elsewhere) the expert author gives several good bites=

 Among other things in those three posts he talks about two programs as:

 import std.c.stdio: printf;
 void main() {
 =A0 =A0printf("%d\n", -int.min);
 }

 import std.stdio: writeln;
 void main() {
 =A0 =A0enum int N =3D (1L).sizeof * 8;
 =A0 =A0auto max =3D (1L << (N - 1)) - 1;
 =A0 =A0writeln(max);
 }

 I believe that D can't be considered a step forward in system language pr=

ted overflows (and integer-related undefined behaviour).
 The good thing is that Java is a living example that even if you remove m=

n as fast as C and sometimes faster (on normal desktops).
 Bye,
 bearophile

Aug 20 2010
next sibling parent reply Kagamin <spam here.lot> writes:
Andrej Mitrovic Wrote:

 What are these Java programs for the desktop that run fast? I haven't
 encountered any, but maybe that's just because I didn't try them all
 out. Eclipse takes at least 20 seconds to load on startup on my quad
 core, that's not very fast. On the other hand, CodeBlocks which is
 coded in C++ and has  a few dozen plugins installed runs in an
 instant.
 
 Just firing up a dialog in eclipse takes a good second, maybe two. So
 give me the names of those fast Java applications, pls. :)

He's talking about arithmetical tests. There're faster java applications like Vuze that are faster compared to slower java applications.
Aug 20 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Kagamin" <spam here.lot> wrote in message 
news:i4mjl0$2ucg$1 digitalmars.com...
 Andrej Mitrovic Wrote:

 What are these Java programs for the desktop that run fast? I haven't
 encountered any, but maybe that's just because I didn't try them all
 out. Eclipse takes at least 20 seconds to load on startup on my quad
 core, that's not very fast. On the other hand, CodeBlocks which is
 coded in C++ and has  a few dozen plugins installed runs in an
 instant.


For me, C::B always took somewhere around ten seconds to start up (and then it kept using 5-10% CPU even when idling with all plugins disabled - a number of other people reported the same thing). But it's been awhile since I used it though, so maybe that's all fixed now. But yea, I can't remember ever seeing a non-trivial Java app that wasn't a bit on the sluggish side.
 Just firing up a dialog in eclipse takes a good second, maybe two. So
 give me the names of those fast Java applications, pls. :)

He's talking about arithmetical tests. There're faster java applications like Vuze that are faster compared to slower java applications.

You have *got* to be kidding me. Vuze is one of the absolute biggest pieces of bloatware I've ever seen in my entire life. *Eclipse* is more responsive for me (although only just barely). There are exactly three programs I've always considered to be roughly tied for "biggest bloatware in history": - Eclipse - Vuze - JetBrains MPS And among those three, Eclipse is close to just simply being #3, right after a tie between Vuze and MPS for #1.
Aug 20 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
retard:
 quake 2 port - http://bytonic.de/html/jake2_webstart.html

Have you read some of that code? No Java programmer writes code like that. That code is the "exception that confirms the rule" (I don't know how this is normally written in English). The rule is that Java code is slow ;-) Bye, bearophile
Aug 20 2010
next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
On 22/08/10 21:31, retard wrote:
 Maybe I am not understanding what he means. To me Eclipse feels bloated
 and slow, but it doesn't tell anything about Java in general. If I buy a
 new CPU, the Java programs will run faster than C++ ones now on the
 current CPU. Why is the small performance difference that significant?

For the record, I'm on a 6 core 3.2Ghz a core box with 8GB ram and eclipse still feels bloated and slow. Same goes for OpenOffice.org :3 -- Robert http://octarineparrot.com/
Aug 22 2010
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:
 It appears that in XML parsing Java is actually 5..10 times faster than 
 D1/Phobos. Maybe D2/Phobos has finally fixed these issues.

D *enables* you to write fast code, but you have to know how to write fast code. The code won't be fast simply because you wrote it in D. This also means if you merely translate a program from Java to D, don't expect it to necessarily run faster. You're going to need to refactor/reengineer it for speed. For example, replacing classes with value types.
Aug 22 2010
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Walter Bright wrote:
 This also means if you merely translate a program from Java to D, don't 
 expect it to necessarily run faster. You're going to need to 
 refactor/reengineer it for speed. For example, replacing classes with 
 value types.

Oh, and using slicing, too.
Aug 22 2010
prev sibling next sibling parent reply Jonathan M Davis <jmdavisprog gmail.com> writes:
On Sunday 22 August 2010 14:04:24 Walter Bright wrote:
 Walter Bright wrote:
 This also means if you merely translate a program from Java to D, don't
 expect it to necessarily run faster. You're going to need to
 refactor/reengineer it for speed. For example, replacing classes with
 value types.

Oh, and using slicing, too.

Slicing has got to be one of D's coolest features - especially when combined with ranges. I was ecstatic when I realized that I could use arrays in D like SLists in Haskell - at least for processing them. It's just plain easier to write some algorithms that way. - Jonathan M Davis
Aug 22 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisprog gmail.com> wrote in message 
news:mailman.467.1282518397.13841.digitalmars-d puremagic.com...
 On Sunday 22 August 2010 14:04:24 Walter Bright wrote:
 Walter Bright wrote:
 This also means if you merely translate a program from Java to D, don't
 expect it to necessarily run faster. You're going to need to
 refactor/reengineer it for speed. For example, replacing classes with
 value types.

Oh, and using slicing, too.

Slicing has got to be one of D's coolest features

Yea, I agree. Back in my C/C++ days, I actively avoided doing any string processing whenever I could, just because it was such a PITA.
Aug 23 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:
 Yea, I agree. Back in my C/C++ days, I actively avoided doing any string 
 processing whenever I could, just because it was such a PITA. 

I've done an awful lot of C/C++ programming that involved handling strings. It was always a lot of tedious work, and I was always reinventing the wheel on that. But in looking at other "inferior" languages, like BASIC, I was eventually struck by how trivial string handling was for them. I thought D should be able to do that as well.
Aug 23 2010
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
OT: I guess that's one of the reasons why I was so appalled when I was
reading C++ Primer many years ago. The author spent almost the entire
book explaining the difference between C and C++, and half of his book
with a guide on how to create your own string processing functions in
C++. On the other hand "C" Primer, by the same author, was a very nice
C99 book. I used is as a sort of "warmup" before I got into D (I was
doing mostly Python scripts for a while..).

On Mon, Aug 23, 2010 at 10:08 PM, Nick Sabalausky <a a.a> wrote:
 "Jonathan M Davis" <jmdavisprog gmail.com> wrote in message
 news:mailman.467.1282518397.13841.digitalmars-d puremagic.com...
 On Sunday 22 August 2010 14:04:24 Walter Bright wrote:
 Walter Bright wrote:
 This also means if you merely translate a program from Java to D, don't
 expect it to necessarily run faster. You're going to need to
 refactor/reengineer it for speed. For example, replacing classes with
 value types.

Oh, and using slicing, too.

Slicing has got to be one of D's coolest features

Yea, I agree. Back in my C/C++ days, I actively avoided doing any string processing whenever I could, just because it was such a PITA.

Aug 23 2010
prev sibling next sibling parent Justin Johansson <no spam.com> writes:
On 23/08/10 06:01, retard wrote:
 I'm just asking, why software like this should be written in buggy D if
 production ready Java already executes fast enough? You must desire
 absolute hard-core super mega performance to justify the use of D.

OTOH, to be fair, why the quest for "real-time Java"*** and the myriad of commercial offerings for "real-time Java" systems if standard production ready Java suffices for latency critical applications? *** web search for "real-time Java"
Aug 22 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/22/2010 03:31 PM, retard wrote:
 I'm just asking, why software like this should be written in buggy D if
 production ready Java already executes fast enough? You must desire
 absolute hard-core super mega performance to justify the use of D.

Assuming the question is not tendentious: The decision of choosing a language has quite a few more ingredients than speed of generated code and quality of implementation.
 Another question is, why would anyone use D/Phobos for writing server
 side XML intensive applications if Java is so much faster? Fixing the
 libraries first tends to be bad for productivity. If I had to choose
 between a production ready Java XML library and something half-baked for
 D, my boss would treat me as lunatic if I told him to first wait N months
 to bring the half-baked amateur library on par with Java and only after
 that write the code in this language that no other company uses anywhere.
 I'd need to work on free time to make this a reality.

Again, speed is not the only issue. Anyway, clearly Phobos' xml library is in serious need for a revamp. Andrei
Aug 22 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:
 You don't even write much code anymore, it's just few mouse clicks here 
 and there. I feel the network effect is against D here.

Undoubtedly, people have found ways to get their work done with Java. But there's just no joy in working with it.
Aug 22 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/20/2010 04:48 PM, retard wrote:
 I've tried eclipse with the fancy stuff off, and it's still slower than
 C::B or PN2 for me.

Of course it is. You're comparing apples and oranges. The core of Eclipse is much more customizable.

I've seen a live demo by Erich Gamma in which he wrote a simple Eclipse plugin inside Eclipse and then he immediately used it. It was pretty darn impressive. Today's compiler technology still has us pay for customizability even when it's not realized, so even with all plugins turned off a pluggable program would still be slower than a monolithic one. Andrei
Aug 20 2010
next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from retard (re tard.com.invalid)'s article
 Fri, 20 Aug 2010 16:57:34 -0500, Andrei Alexandrescu wrote:
 On 08/20/2010 04:48 PM, retard wrote:
 I've tried eclipse with the fancy stuff off, and it's still slower
 than C::B or PN2 for me.

Of course it is. You're comparing apples and oranges. The core of Eclipse is much more customizable.

I've seen a live demo by Erich Gamma in which he wrote a simple Eclipse plugin inside Eclipse and then he immediately used it. It was pretty darn impressive. Today's compiler technology still has us pay for customizability even when it's not realized, so even with all plugins turned off a pluggable program would still be slower than a monolithic one.

customizability in every possible way, there can't be a single binary that suits everyone. Programs like C::B force you to choose these features on compile time. This is very typical in C/C++ applications - you have the choice, but it has to be done as early as possible. For instance, I forgot to compile in mp3 support when building ffmpeg or some other multimedia lib. Now the only choice I have is to recompile the library and possibly even all dependencies. It's the same thing in some Linux distributions - they forgot to set on the Truetype bytecode interpreter so I need to recompile some core libraries. Eclipse's philosophy seems to be completely different - some of the choices are made on launching the application, others when starting individual components. The only limitation that comes to mind is that because of SWT, Eclipse needs two distributions (32-bit and 64-bit), at least on Linux. Swing using applications don't have this limitation.

This ties into an idea I've had for awhile as a low-priority "maybe eventually" feature. Template metaprogramming is a big part of writing idiomatic D code. IMHO the emphasis on it and taking it to the Nth degree are **the** main thing that makes D special. Its biggest weakness is that it can't be done at runtime. I wonder if we could eventually do something like make the caller available from the language and allow templates to be instantiated at runtime. For example: import std.getopt; /**A function that is called multiple times with the same constant * and can only be made efficient if that constant is known at * compile time. */ double numericsFunction(int needsConstFolding)(double runtimeArgs) { // do stuff. } void main(string[] args) { int param; getopt(args, "param", &param); // runtimeInstantiate instantiates a function template at runtime, // including recursive instantiation of all templates the // function instantiates, loads it into the current address // space and returns a function pointer to it. auto fun = runtimeInstantiate!numericsFunction(param); foreach(i; 0..someHugeNumber) { fun(i); } } This could be implemented by embedding all necessary source code as a string inside the executable. For structs and classes, runtimeInstantiate would be more difficult, but might return a factory method for creating the struct/class.
Aug 20 2010
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 20/08/2010 22:57, Andrei Alexandrescu wrote:
 On 08/20/2010 04:48 PM, retard wrote:
 I've tried eclipse with the fancy stuff off, and it's still slower than
 C::B or PN2 for me.

Of course it is. You're comparing apples and oranges. The core of Eclipse is much more customizable.

I've seen a live demo by Erich Gamma in which he wrote a simple Eclipse plugin inside Eclipse and then he immediately used it. It was pretty darn impressive.

That's interesting, where was that demo? Was it at QCon? -- Bruno Medeiros - Software Engineer
Oct 01 2010
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:
 After few hours 
 of use everything should run as fast as it can.

I kinda don't really want to wait a few hours for my editor to stop lagging.
Aug 20 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:
 Fri, 20 Aug 2010 15:07:50 -0700, Walter Bright wrote:
 
 retard wrote:
 After few hours
 of use everything should run as fast as it can.

lagging.

You don't need to use it that long. I only gave a pessimistic estimate on when all JIT compilation stops. Surely the most used features get recompiled faster. The second use of any Java function should already trigger the JIT in some cases. This is a bit unfortunate for desktop applications because the first impression is that everything lags. But the thing is, if you try something TWICE or more, it's orders of magnitude faster.

I should amend that to saying I don't want to wait at all for my editor to work. I go in and out of it too often. It's why I use a small, natively compiled editor. It loads instantly. Even on DOS <g>. And frankly, it's retarded to compile the same program over and over, every time you use it. Especially when the cost of that I pay for every time I run it.
Aug 20 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
SK wrote:
 On Fri, Aug 20, 2010 at 4:16 PM, Walter Bright
 <newshound2 digitalmars.com> wrote:
 And frankly, it's retarded to compile the same program over and over, every
 time you use it.

How about IBM's TIMI? My understanding is that it's a hybrid approach that gives you machine independence with a one-time recompilation that is stored back into the executable. Or something like that.

Beats me, I've never heard of it.
Aug 20 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
SK wrote:
 Then to make this more concrete, what if D had an option to suspend
 compilation after the front-end finished?  The resulting executable
 contains the abstract RTL blobs and the compiler backend, which
 finishes the job for the specific platform on which the executable is
 launched.  The final binary is cached for subsequent launches.  You
 get good machine independence and the approach provides performance
 wins for operations like vectorizing where you don't know in advance
 what kind of SSE support you'll find.
 
 Hypothetically, why not?

It's an old idea, but I think it's pointless. Instead of caching the intermediate code, just cache the source code.
Aug 20 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
SK wrote:
 Do you mean to say:
 Instead of shipping the intermediate code, always ship source code.

Yes.
 -or-
 Instead of caching the binary, just cache the source code.
 
 Neither of those guesses make general sense so I'm afraid I miss your point.

Why doesn't it make sense?
Aug 20 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:i4nn6k$sos$2 digitalmars.com...
 SK wrote:
 Do you mean to say:
 Instead of shipping the intermediate code, always ship source code.

Yes.
 -or-
 Instead of caching the binary, just cache the source code.

 Neither of those guesses make general sense so I'm afraid I miss your 
 point.

Why doesn't it make sense?

The only possible complaints I can think of are: 1. Redoing the parsing and semantic analysis. 2. Being uncomfortable about releasing source. I'm curious what you have to say about #1. But I consider #2 to be a very poor reason because: - There's always reverse engineering. - There's always obfuscation. - IL may even provide better reverse-engineering results than machine code, depending on the IL. - All the companies sinking time and money into JS and PHP middleware don't seem to have a problem with handing out their source. - If someone's gonna steal a product and rebrand it as their own, they don't usually need the source, and having it would probably only be of fairly small help, if any. - As a customer, the idea of spending money on a product that I can't service myself if/when the company goes under or loses interest makes me nervous. Providing their source would given them a competetive advantage. - Even though providing source gets in the way of effective DRM (as if there even were such a thing), DRM itself gets in the way of sales. - Distributing in source form makes certain things possible that wouldn't otherwise be, like virtual template functions (in theory, even if not in actual D practice).
Aug 20 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:
 "Walter Bright" <newshound2 digitalmars.com> wrote in message 
 news:i4nn6k$sos$2 digitalmars.com...
 SK wrote:
 Do you mean to say:
 Instead of shipping the intermediate code, always ship source code.

 -or-
 Instead of caching the binary, just cache the source code.

 Neither of those guesses make general sense so I'm afraid I miss your 
 point.


The only possible complaints I can think of are: 1. Redoing the parsing and semantic analysis.

It's pretty darned fast.
 2. Being uncomfortable about releasing source.

You can turn java bytecodes back into reasonable source code easily enough. And nothing says you can't run the D code through a comment stripper first.
 
 I'm curious what you have to say about #1. But I consider #2 to be a very 
 poor reason because:
 
 - There's always reverse engineering.
 - There's always obfuscation.
 - IL may even provide better reverse-engineering results than machine code, 
 depending on the IL.

Yes, it can, as Java disassemblers prove.
 - All the companies sinking time and money into JS and PHP middleware don't 
 seem to have a problem with handing out their source.
 - If someone's gonna steal a product and rebrand it as their own, they don't 
 usually need the source, and having it would probably only be of fairly 
 small help, if any.
 - As a customer, the idea of spending money on a product that I can't 
 service myself if/when the company goes under or loses interest makes me 
 nervous. Providing their source would given them a competetive advantage.
 - Even though providing source gets in the way of effective DRM (as if there 
 even were such a thing), DRM itself gets in the way of sales.

Yup, no DRM on any products I've built.
 - Distributing in source form makes certain things possible that wouldn't 
 otherwise be, like virtual template functions (in theory, even if not in 
 actual D practice).

Yup again, Java can't do compile time polymorphism! BTW, I realized around 10 years ago that what you can do is lex D source and use the token stream as your "intermediate code". It should work great, be compact, and fast.
Aug 20 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:i4nqis$19fd$1 digitalmars.com...
 Nick Sabalausky wrote:

 - Distributing in source form makes certain things possible that wouldn't 
 otherwise be, like virtual template functions (in theory, even if not in 
 actual D practice).

Yup again, Java can't do compile time polymorphism!

I'm not sure whether we're talking about the same thing. I mean something like this: module A; class Base { void foo(T)(T x) { } } module B; class Derived : Base { void override foo(T)(T x) { } } I know D doesn't currently allow that. But my understanding is that if module A is available in source form, then there's no technical issue preventing it. So if a dev house wants to keep their source private, then they can't expose any API like that even if their language did normally allow such a thing. Therefore, keeping source private limits what can be done. Of course, even just exposing any old template requires at least some code to be exposed (or easily-reconstructable).
 BTW, I realized around 10 years ago that what you can do is lex D source 
 and use the token stream as your "intermediate code". It should work 
 great, be compact, and fast.

Would that be useful in any significant way? Wouldn't re-lexing be very quick too? And in my limited experience, lexing seems to be a little easer than parsing, too.
Aug 20 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:i4nrlb$1dp7$1 digitalmars.com...
 "Walter Bright" <newshound2 digitalmars.com> wrote in message 
 news:i4nqis$19fd$1 digitalmars.com...
 BTW, I realized around 10 years ago that what you can do is lex D source 
 and use the token stream as your "intermediate code". It should work 
 great, be compact, and fast.

Would that be useful in any significant way? Wouldn't re-lexing be very quick too? And in my limited experience, lexing seems to be a little easer than parsing, too.

If you ever saved it to disk or across a network, you'd have to be real careful about choosing a storage format...you could easily end up defeating the point :)
Aug 20 2010
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:
 Would that be useful in any significant way? Wouldn't re-lexing be very 
 quick too? And in my limited experience, lexing seems to be a little easer 
 than parsing, too.

It's faster and more compact, if you're going to transmit things.
Aug 20 2010
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"SK" <sk metrokings.com> wrote in message 
news:mailman.447.1282372871.13841.digitalmars-d puremagic.com...
 Hi Nick,

 On Fri, Aug 20, 2010 at 10:37 PM, Nick Sabalausky <a a.a> wrote:
 I'm curious what you have to say about #1. But I consider #2 to be a very
 poor reason because:

 - There's always reverse engineering.
 - There's always obfuscation.
 - IL may even provide better reverse-engineering results than machine 
 code,
 depending on the IL.
 - All the companies sinking time and money into JS and PHP middleware 
 don't
 seem to have a problem with handing out their source.
 - If someone's gonna steal a product and rebrand it as their own, they 
 don't
 usually need the source, and having it would probably only be of fairly
 small help, if any.
 - As a customer, the idea of spending money on a product that I can't
 service myself if/when the company goes under or loses interest makes me
 nervous. Providing their source would given them a competetive advantage.
 - Even though providing source gets in the way of effective DRM (as if 
 there
 even were such a thing), DRM itself gets in the way of sales.
 - Distributing in source form makes certain things possible that wouldn't
 otherwise be, like virtual template functions (in theory, even if not in
 actual D practice).

Yes, yes and yes - especially about not needing source to be a pirate. But your perspective is not shared by many big companies shipping software I care about. The open source movement has even turned up the contrast in this regard for closed source companies. Without conducting a thorough Fortune 500 survey, I will assert that shipping source is an emotionally burdened action at the management level, and this roadblock is avoided by "simply" running code through front end compilation. So, just do that and move on the to next problem.

Oh right, I won't deny any of that. And that sort of situation can, unfortunately, create a faulty-but-real need to supply such things. You can't educate an MBA - but you can fleece them ;)
Aug 20 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
SK wrote:
 On Fri, Aug 20, 2010 at 10:11 PM, Walter Bright
 <newshound2 digitalmars.com> wrote:
 SK wrote:
 Do you mean to say:
 Instead of shipping the intermediate code, always ship source code.

Why doesn't it make sense?

I love open source projects, but off the top of my head here are some reasons that's not a general substitute for TIMI for D: 1) What about closed source software?

Won't work anyway. Java bytecodes are trivially turned back into source.
 2) From-source builds may be more complex or resource consuming than
 could be accommodated on the machine the customer used to launch, e.g.
 a hand-held device.

I've worked on a Java VM enough to know that won't be a problem.
 3) The source may have sizable irrelevant content for a particular
 product instantiation, compile time conditionals, etc

You can run it through a comment stripper first.
Aug 20 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
SK wrote:
 I've worked on a Java VM enough to know that won't be a problem.

that have nothing to do with the target platform?

Why, indeed. You can just interpret the D code.
 3) The source may have sizable irrelevant content for a particular
 product instantiation, compile time conditionals, etc


Why stop there? If you have to create some waypoint that isn't really the source and isn't the binary, why not finish off the platform independent lifting in the front end? I am getting zero admission from you that there is any goodness to be found in the TIMI thing. I don't understand that. Do you really just hate the idea through and through?

I don't hate it, I'm just not sold on its advantages.
Aug 21 2010
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
retard wrote:
 Fri, 01 Oct 2010 14:53:04 +0100, Bruno Medeiros wrote:
 
 On 20/08/2010 22:37, Nick Sabalausky wrote:
 "retard"<re tard.com.invalid>  wrote in message
 news:i4mrss$cam$1 digitalmars.com...
 Fri, 20 Aug 2010 19:04:41 +0200, Andrej Mitrovic wrote:

 What are these Java programs for the desktop that run fast? I haven't
 encountered any, but maybe that's just because I didn't try them all
 out. Eclipse takes at least 20 seconds to load on startup on my quad
 core, that's not very fast. On the other hand, CodeBlocks which is
 coded in C++ and has  a few dozen plugins installed runs in an
 instant.

written in Go is SO fast. This must prove that Go is much faster than C+ +!" I think CodeBlocks is one of the most lightweight IDEs out there. Does it even have full semantic autocompletion? Eclipse, on the other hand, comes with almost everything you can imagine. If you turn off the syntax check, Eclipse works just as fast as any native application on a modern desktop.

C::B or PN2 for me.

slow when used, etc., are really meaningless unless you tell us something about what actual plugins and features are installed and used. Unlike CodeBlocks which is "a free C++ IDE", Eclipse proper is the Eclipse Platform, which is a platform (duh) and doesn't do anything useful by itself. Particularly since there is not even a standard/single "Eclipse" download: http://www.eclipse.org/downloads/ , unlike Codeblocks. The days were JDT would be the main thing 95% of Eclipse users would use are long gone. So are you using JDT, CDT, Descent, something else? If JDT, do you have extra tools, like the J2EE Web Tools? (these add massive bloat) What about source control plugins, or plugins not provided by the Eclipse Foundation, etc? All of these are a wildcard that can affect performance. For example, I definitely note that sometimes my workspace chokes when I do certain SVN or file related operations (with Subclipse btw, not Subversive). I also noted, when Eclipse 3.6 came out, some sluggishness when working with JDT, even when just typing code (in this case it was very subtle, almost imperceptible, but I still felt it and it was quite annoying). I suspected not JDT, but Mylyn, so I uninstalled it, and now things are back to normal. (there might be a fix or workaround for that issue in Mylyn, but since I don't use it, I didn't bother) I would definitely be quite annoying if Eclipse was not responsive for the vast majority of coding tasks. As for startup time, I hardly care anything about that : http://www.digitalmars.com/d/archives/digitalmars/D/

 (except when I'm doing PDE development, but that's a different thing)

Back then the unhappy user was using a 1 GHz Pentium M notebook. I tried this again. Guess what, the latest Eclipse Helios (3.6.1) took 3.5 (!!!) seconds to start up the whole Java workspace, open few projects and fully initialize the editors etc for the most active project.

That's good news. Sounds as though they've fixed the startup performance bug. Has the original
 complainer ever used Photoshop, CorelDraw, AutoCad, Maya/3DSMax, Maple/
 MathCad/Mathematica, or some other Real World Programs (tm)? These are 
 all fucking slow. That's how it is: If you need to get the job done, you 
 must use slow programs.

That original poster was me. Yes, I've used all of those programs (though not a recent version of CorelDraw). The startup time was 80 seconds, on the most most minimal standard Eclipse setup I could find. MSVC was 3 seconds on the same system. I had expected the times to be roughly comparable. There was just something sloppy in Eclipse's startup code.
Oct 02 2010
next sibling parent reply Don <nospam nospam.com> writes:
retard wrote:
 Sat, 02 Oct 2010 18:21:53 +0200, Don wrote:
 
 retard wrote:
 Back then the unhappy user was using a 1 GHz Pentium M notebook. I
 tried this again. Guess what, the latest Eclipse Helios (3.6.1) took
 3.5 (!!!) seconds to start up the whole Java workspace, open few
 projects and fully initialize the editors etc for the most active
 project.

bug.

I meant that computers become more efficient. I've upgraded my system two times since this discussion last appeared here. If you wait 18 months, the 20 seconds becomes 10 seconds, in 36 months 5 seconds. It's the Moore's law, you know.

Sadly, software seems to be bloating at a rate which is faster than Moore's law. Part of my original post noted that it was much slower than my old 1MHz Commodore 64 took to boot my development environment from a cassette tape! So I still take it as a good sign that the rate of bloating is slower than Moore's law.
 Has the original
 complainer ever used Photoshop, CorelDraw, AutoCad, Maya/3DSMax, Maple/
 MathCad/Mathematica, or some other Real World Programs (tm)? These are
 all fucking slow. That's how it is: If you need to get the job done,
 you must use slow programs.

(though not a recent version of CorelDraw). The startup time was 80 seconds, on the most most minimal standard Eclipse setup I could find. MSVC was 3 seconds on the same system. I had expected the times to be roughly comparable.

How long does it take to start up all those programs on your notebook? 15 minutes? I don't even consider Eclipse bloated compared to *these* applications.

Don't remember. I too have upgraded since then. I can say, though, that Eclipse was the worst I experienced (the others you mentioned were I think more in the 30 second range). Mind you, I never ran Labview on it. Labview would probably have been worse.
 There was just something sloppy in Eclipse's startup code.

I don't recommend running Eclipse on any machine with less than 1 GB of RAM. It's a well known fact that Java programs require twice as much memory due to garbage collection. Also Eclipse is a rather complex framework. Luckily *all* systems, even the cheapest $100 netbooks have 1 GB of RAM!

My laptop had 1GB, so I'm not sure we can blame that. Eclipse was perfectly fine once it had loaded. It was only the startup which was slow.
Oct 02 2010
next sibling parent Justin Johansson <no spam.com> writes:
On 3/10/2010 8:21 PM, Russel Winder wrote:
 On Sat, 2010-10-02 at 21:21 +0200, Don wrote:
 retard wrote:

 I meant that computers become more efficient. I've upgraded my system two
 times since this discussion last appeared here. If you wait 18 months, the
 20 seconds becomes 10 seconds, in 36 months 5 seconds. It's the Moore's
 law, you know.

Sadly, software seems to be bloating at a rate which is faster than Moore's law. Part of my original post noted that it was much slower than my old 1MHz Commodore 64 took to boot my development environment from a cassette tape! So I still take it as a good sign that the rate of bloating is slower than Moore's law.

Faster processor speeds in the period 1950--2005 was not actually anything to do with Moore's Law per se -- Moore's Law was about the number of transistors per chip, not the speed of operation of those transistors. Since around 2005 processor speeds have stopped increasing due to inability to deal with the heat generation. Instead Moore's Law (which for the moment still applies) is leading to more and more cores per chip all running at the same speed as previously -- around 2GHz. So the ability to improve performance of code by just waiting and buying new kit is over -- at least for now. If you do not turn your serial code into parallel code there will be no mechanism for improving performance of that code. A bit sad for inherently serial algorithms.

And yes, my observation is that is is not often to be able to buy new kit (aka PC) with more MIPS and chips (CPUs) that runs the O/S and applications faster than the veteran unit, perhaps apart from graphics acceleration. Why is it that Moores Law does not seem to make for better user experience as time goes by? Conspiracy theory: Seems to me that there is a middle man on the take all the time. :-) Cheers Justin Johansson
Oct 03 2010
prev sibling next sibling parent Mafi <mafi example.org> writes:
Am 02.10.2010 21:21, schrieb Don:
 Sadly, software seems to be bloating at a rate which is faster than
 Moore's law.

Mafi
Oct 05 2010
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Russel Winder wrote:
 So the ability to improve performance of code by just waiting and buying
 new kit is over -- at least for now.  If you do not turn your serial
 code into parallel code there will be no mechanism for improving
 performance of that code.  A bit sad for inherently serial algorithms.

I'm not sad at all. I enjoy optimizing code for performance, and working on optimizers.
Oct 07 2010
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 02/10/2010 17:21, Don wrote:
 retard wrote:
 Fri, 01 Oct 2010 14:53:04 +0100, Bruno Medeiros wrote:

 On 20/08/2010 22:37, Nick Sabalausky wrote:
 "retard"<re tard.com.invalid> wrote in message
 news:i4mrss$cam$1 digitalmars.com...
 Fri, 20 Aug 2010 19:04:41 +0200, Andrej Mitrovic wrote:

 What are these Java programs for the desktop that run fast? I haven't
 encountered any, but maybe that's just because I didn't try them all
 out. Eclipse takes at least 20 seconds to load on startup on my quad
 core, that's not very fast. On the other hand, CodeBlocks which is
 coded in C++ and has a few dozen plugins installed runs in an
 instant.

written in Go is SO fast. This must prove that Go is much faster than C+ +!" I think CodeBlocks is one of the most lightweight IDEs out there. Does it even have full semantic autocompletion? Eclipse, on the other hand, comes with almost everything you can imagine. If you turn off the syntax check, Eclipse works just as fast as any native application on a modern desktop.

C::B or PN2 for me.

slow when used, etc., are really meaningless unless you tell us something about what actual plugins and features are installed and used. Unlike CodeBlocks which is "a free C++ IDE", Eclipse proper is the Eclipse Platform, which is a platform (duh) and doesn't do anything useful by itself. Particularly since there is not even a standard/single "Eclipse" download: http://www.eclipse.org/downloads/ , unlike Codeblocks. The days were JDT would be the main thing 95% of Eclipse users would use are long gone. So are you using JDT, CDT, Descent, something else? If JDT, do you have extra tools, like the J2EE Web Tools? (these add massive bloat) What about source control plugins, or plugins not provided by the Eclipse Foundation, etc? All of these are a wildcard that can affect performance. For example, I definitely note that sometimes my workspace chokes when I do certain SVN or file related operations (with Subclipse btw, not Subversive). I also noted, when Eclipse 3.6 came out, some sluggishness when working with JDT, even when just typing code (in this case it was very subtle, almost imperceptible, but I still felt it and it was quite annoying). I suspected not JDT, but Mylyn, so I uninstalled it, and now things are back to normal. (there might be a fix or workaround for that issue in Mylyn, but since I don't use it, I didn't bother) I would definitely be quite annoying if Eclipse was not responsive for the vast majority of coding tasks. As for startup time, I hardly care anything about that : http://www.digitalmars.com/d/archives/digitalmars/D/

 (except when I'm doing PDE development, but that's a different thing)

Back then the unhappy user was using a 1 GHz Pentium M notebook. I tried this again. Guess what, the latest Eclipse Helios (3.6.1) took 3.5 (!!!) seconds to start up the whole Java workspace, open few projects and fully initialize the editors etc for the most active project.

That's good news. Sounds as though they've fixed the startup performance bug.

Not necessarily. Again, you need to consider what is installed and loading in Eclipse. In retard's scenario he was loading a Java workspace (JDT) whereas your original post was a C++ one (with CDT, I'm guessing). Even disregarding the PC specs, it's comparing apples to oranges. Eclipse is not like Firefox where the main platform is 90% of the code/functionality, and the plugins are only like 5-10%.
 Has the original
 complainer ever used Photoshop, CorelDraw, AutoCad, Maya/3DSMax, Maple/
 MathCad/Mathematica, or some other Real World Programs (tm)? These are
 all fucking slow. That's how it is: If you need to get the job done,
 you must use slow programs.

That original poster was me. Yes, I've used all of those programs (though not a recent version of CorelDraw). The startup time was 80 seconds, on the most most minimal standard Eclipse setup I could find. MSVC was 3 seconds on the same system. I had expected the times to be roughly comparable. There was just something sloppy in Eclipse's startup code.

Any Eclipse IDE configuration/distribution is likely never going to start fast, at least as fast as comparable native IDEs like MS Visual Studio. Still, I do think that 80 seconds sounds excessive, even for those computer specs. But it's likely a CDT issue, not an Eclipse one. Again, this distinction has to be considered, you can't just say "There was just something sloppy in Eclipse's startup code" or "Eclipse developers don't care about performance issues _at all_". The projects that come bundled in offical Eclipse distributions are not only separate projects (JDT, CDT, WTP, PDT, Mylyn, etc.), like I mentioned in my original post, but they are made by completely separate teams, most of them from different companies (even for the more popular Eclipse projects). -- Bruno Medeiros - Software Engineer
Oct 05 2010
parent Jacob Carlborg <doob me.com> writes:
On 2010-10-05 17:04, Bruno Medeiros wrote:
 There was just something sloppy in Eclipse's startup code.

Any Eclipse IDE configuration/distribution is likely never going to start fast, at least as fast as comparable native IDEs like MS Visual Studio. Still, I do think that 80 seconds sounds excessive, even for those computer specs. But it's likely a CDT issue, not an Eclipse one. Again, this distinction has to be considered, you can't just say "There was just something sloppy in Eclipse's startup code" or "Eclipse developers don't care about performance issues _at all_". The projects that come bundled in offical Eclipse distributions are not only separate projects (JDT, CDT, WTP, PDT, Mylyn, etc.), like I mentioned in my original post, but they are made by completely separate teams, most of them from different companies (even for the more popular Eclipse projects).

I noticed quite a significant boost in the start up time for Eclipse when I updated to 3.6. I'm using Eclipse classic with the Descent plugin. -- /Jacob Carlborg
Oct 06 2010
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 02/10/2010 15:13, retard wrote:
 Fri, 01 Oct 2010 14:53:04 +0100, Bruno Medeiros wrote:

 On 20/08/2010 22:37, Nick Sabalausky wrote:
 "retard"<re tard.com.invalid>   wrote in message
 news:i4mrss$cam$1 digitalmars.com...
 Fri, 20 Aug 2010 19:04:41 +0200, Andrej Mitrovic wrote:

 What are these Java programs for the desktop that run fast? I haven't
 encountered any, but maybe that's just because I didn't try them all
 out. Eclipse takes at least 20 seconds to load on startup on my quad
 core, that's not very fast. On the other hand, CodeBlocks which is
 coded in C++ and has  a few dozen plugins installed runs in an
 instant.

Now that's a fair comparison! "Crysis runs so slowly but a hello world written in Go is SO fast. This must prove that Go is much faster than C+ +!" I think CodeBlocks is one of the most lightweight IDEs out there. Does it even have full semantic autocompletion? Eclipse, on the other hand, comes with almost everything you can imagine. If you turn off the syntax check, Eclipse works just as fast as any native application on a modern desktop.

I've tried eclipse with the fancy stuff off, and it's still slower than C::B or PN2 for me.

slow when used, etc., are really meaningless unless you tell us something about what actual plugins and features are installed and used. Unlike CodeBlocks which is "a free C++ IDE", Eclipse proper is the Eclipse Platform, which is a platform (duh) and doesn't do anything useful by itself. Particularly since there is not even a standard/single "Eclipse" download: http://www.eclipse.org/downloads/ , unlike Codeblocks. The days were JDT would be the main thing 95% of Eclipse users would use are long gone. So are you using JDT, CDT, Descent, something else? If JDT, do you have extra tools, like the J2EE Web Tools? (these add massive bloat) What about source control plugins, or plugins not provided by the Eclipse Foundation, etc? All of these are a wildcard that can affect performance. For example, I definitely note that sometimes my workspace chokes when I do certain SVN or file related operations (with Subclipse btw, not Subversive). I also noted, when Eclipse 3.6 came out, some sluggishness when working with JDT, even when just typing code (in this case it was very subtle, almost imperceptible, but I still felt it and it was quite annoying). I suspected not JDT, but Mylyn, so I uninstalled it, and now things are back to normal. (there might be a fix or workaround for that issue in Mylyn, but since I don't use it, I didn't bother) I would definitely be quite annoying if Eclipse was not responsive for the vast majority of coding tasks. As for startup time, I hardly care anything about that : http://www.digitalmars.com/d/archives/digitalmars/D/

 (except when I'm doing PDE development, but that's a different thing)

Back then the unhappy user was using a 1 GHz Pentium M notebook. I tried this again. Guess what, the latest Eclipse Helios (3.6.1) took 3.5 (!!!) seconds to start up the whole Java workspace, open few projects and fully initialize the editors etc for the most active project. Has the original complainer ever used Photoshop, CorelDraw, AutoCad, Maya/3DSMax, Maple/ MathCad/Mathematica, or some other Real World Programs (tm)? These are all fucking slow. That's how it is: If you need to get the job done, you must use slow programs.

I'm sure that the people who downright refuse to use Eclipse because it loads too slow use some other program for media development. Maybe its MS Paint (or a Linux equivalent) because it loads so fast! Or maybe its a vi/emacs plugin for image manipulation or 3D modelling. ;) -- Bruno Medeiros - Software Engineer
Oct 05 2010
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 05/10/2010 18:59, retard wrote:
 Tue, 05 Oct 2010 15:49:59 +0100, Bruno Medeiros wrote:

 On 02/10/2010 15:13, retard wrote:
 Fri, 01 Oct 2010 14:53:04 +0100, Bruno Medeiros wrote:

 On 20/08/2010 22:37, Nick Sabalausky wrote:
 "retard"<re tard.com.invalid>    wrote in message
 news:i4mrss$cam$1 digitalmars.com...
 Fri, 20 Aug 2010 19:04:41 +0200, Andrej Mitrovic wrote:

 What are these Java programs for the desktop that run fast? I
 haven't encountered any, but maybe that's just because I didn't try
 them all out. Eclipse takes at least 20 seconds to load on startup
 on my quad core, that's not very fast. On the other hand,
 CodeBlocks which is coded in C++ and has  a few dozen plugins
 installed runs in an instant.

Now that's a fair comparison! "Crysis runs so slowly but a hello world written in Go is SO fast. This must prove that Go is much faster than C+ +!" I think CodeBlocks is one of the most lightweight IDEs out there. Does it even have full semantic autocompletion? Eclipse, on the other hand, comes with almost everything you can imagine. If you turn off the syntax check, Eclipse works just as fast as any native application on a modern desktop.

I've tried eclipse with the fancy stuff off, and it's still slower than C::B or PN2 for me.

is slow when used, etc., are really meaningless unless you tell us something about what actual plugins and features are installed and used. Unlike CodeBlocks which is "a free C++ IDE", Eclipse proper is the Eclipse Platform, which is a platform (duh) and doesn't do anything useful by itself. Particularly since there is not even a standard/single "Eclipse" download: http://www.eclipse.org/downloads/ , unlike Codeblocks. The days were JDT would be the main thing 95% of Eclipse users would use are long gone. So are you using JDT, CDT, Descent, something else? If JDT, do you have extra tools, like the J2EE Web Tools? (these add massive bloat) What about source control plugins, or plugins not provided by the Eclipse Foundation, etc? All of these are a wildcard that can affect performance. For example, I definitely note that sometimes my workspace chokes when I do certain SVN or file related operations (with Subclipse btw, not Subversive). I also noted, when Eclipse 3.6 came out, some sluggishness when working with JDT, even when just typing code (in this case it was very subtle, almost imperceptible, but I still felt it and it was quite annoying). I suspected not JDT, but Mylyn, so I uninstalled it, and now things are back to normal. (there might be a fix or workaround for that issue in Mylyn, but since I don't use it, I didn't bother) I would definitely be quite annoying if Eclipse was not responsive for the vast majority of coding tasks. As for startup time, I hardly care anything about that : http://www.digitalmars.com/d/archives/digitalmars/D/



 (except when I'm doing PDE development, but that's a different thing)

Back then the unhappy user was using a 1 GHz Pentium M notebook. I tried this again. Guess what, the latest Eclipse Helios (3.6.1) took 3.5 (!!!) seconds to start up the whole Java workspace, open few projects and fully initialize the editors etc for the most active project. Has the original complainer ever used Photoshop, CorelDraw, AutoCad, Maya/3DSMax, Maple/ MathCad/Mathematica, or some other Real World Programs (tm)? These are all fucking slow. That's how it is: If you need to get the job done, you must use slow programs.

loads too slow use some other program for media development. Maybe its MS Paint (or a Linux equivalent) because it loads so fast! Or maybe its a vi/emacs plugin for image manipulation or 3D modelling. ;)

Well Don mentioned that he had used ALL of those programs and since no complaints about the slow loading times of those programs were mentioned, I assume all of them (the latest versions, of course) start in less than 3.5 seconds. I pondered this a bit and am now willing to buy Don's magic computer. I really do have need for a laptop that can launch those applications in less than 3.5 seconds.

Note: I wasn't talking about Don. Even though he mentioned those startup issues, I don't think Don is a person who "downright refuse[s] to use Eclipse because it loads too slow". One thing is complaining, the other thing is actually deciding not to use, and yes, there are some people in the later camp, people who don't want to use an IDE if it doesn't load in less than X seconds (where X is between 1-5 seconds). -- Bruno Medeiros - Software Engineer
Oct 06 2010
prev sibling next sibling parent reply Jonathan M Davis <jmdavisprog gmail.com> writes:
On Friday, August 20, 2010 10:04:41 Andrej Mitrovic wrote:
 What are these Java programs for the desktop that run fast? I haven't
 encountered any, but maybe that's just because I didn't try them all
 out. Eclipse takes at least 20 seconds to load on startup on my quad
 core, that's not very fast. On the other hand, CodeBlocks which is
 coded in C++ and has  a few dozen plugins installed runs in an
 instant.

There's plenty of Java code which runs just as fast or faster than comperable C++ code. I've seen it. However, you're generally talking about small, computation-intensive programs. When you're talking about full-blown desktop applications, there's so much more going on than math operations that the game is entirely different. I'm not sure that there are any full-blown desktop Java applications which are all that efficient in comparison to similar C++ applications. They're definitely useable, but not necessarily as efficient. Of course, the difference between Ecilpse and CodeBlocks could be entirely a design issue rather than a language one. Once you're dealing with anything that complex, accurately comparing apps can be difficult. It could just as easily be that Eclipse's design isn't as efficient - be it due to features that it has which CodeBlocks doesn't or poor design, or whatever. - Jonathan M Davis
Aug 20 2010
parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Jonathan M Davis (jmdavisprog gmail.com)'s article
 On Friday, August 20, 2010 10:04:41 Andrej Mitrovic wrote:
 What are these Java programs for the desktop that run fast? I haven't
 encountered any, but maybe that's just because I didn't try them all
 out. Eclipse takes at least 20 seconds to load on startup on my quad
 core, that's not very fast. On the other hand, CodeBlocks which is
 coded in C++ and has  a few dozen plugins installed runs in an
 instant.

C++ code. I've seen it. However, you're generally talking about small, computation-intensive programs. When you're talking about full-blown desktop applications, there's so much more going on than math operations that the game is entirely different. I'm not sure that there are any full-blown desktop Java applications which are all that efficient in comparison to similar C++ applications. They're definitely useable, but not necessarily as efficient. Of course, the difference between Ecilpse and CodeBlocks could be entirely a design issue rather than a language one. Once you're dealing with anything that complex, accurately comparing apps can be difficult. It could just as easily be that Eclipse's design isn't as efficient - be it due to features that it has which CodeBlocks doesn't or poor design, or whatever. - Jonathan M Davis

The thing about Java is that, even if equivalently written Java code is as fast as C++ code, if you really care about performance you're gonna use dirty tricks in a few key hotspots. Java makes dirty tricks hard or impossible to use. For example, Java's stock GC is very good, but when you're trying to squeeze out that last drop of performance you might want to use some kind of region- or stack-based memory management. This is unimplementable in Java. You also can't use tricks like recycling the same buffer for multiple types. Another area where dirty tricks are sometimes useful is type punning to "cheat" and speed up algorithms. I actually sped my sorting functions in dstats up by ~20% on floating point numbers by performing a single pass over the array to pun the numbers to integers and bit twiddle them such that their ordering is unaffected by this punning, sorting them as integers, and then untwiddling and casting them back. Floating point comparisons have to watch out for things like NaNs and are thus slower than integer comparisons. These sorting routines, using DMD's crappy optimizer, are now faster than STL's sorting routines, using GCC's optimizer, for sorting floating point numbers. As another example, I'm pretty sure the fast inverse square root algorithm (http://en.wikipedia.org/wiki/Fast_inverse_square_root) is unimplementable in Java.
Aug 20 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Ok maybe I missunderstood OP's post, I saw the word "desktop" and
thought he was talking about full-blown desktop apps. :)

On Fri, Aug 20, 2010 at 7:30 PM, Jonathan M Davis <jmdavisprog gmail.com> w=
rote:
 On Friday, August 20, 2010 10:04:41 Andrej Mitrovic wrote:
 What are these Java programs for the desktop that run fast? I haven't
 encountered any, but maybe that's just because I didn't try them all
 out. Eclipse takes at least 20 seconds to load on startup on my quad
 core, that's not very fast. On the other hand, CodeBlocks which is
 coded in C++ and has =A0a few dozen plugins installed runs in an
 instant.

There's plenty of Java code which runs just as fast or faster than comper=

 C++ code. I've seen it. However, you're generally talking about small,
 computation-intensive programs. When you're talking about full-blown desk=

 applications, there's so much more going on than math operations that the=

 is entirely different. I'm not sure that there are any full-blown desktop=

 applications which are all that efficient in comparison to similar C++
 applications. They're definitely useable, but not necessarily as efficien=

 course, the difference between Ecilpse and CodeBlocks could be entirely a=

 issue rather than a language one. Once you're dealing with anything that
 complex, accurately comparing apps can be difficult. It could just as eas=

 that Eclipse's design isn't as efficient =A0- be it due to features that =

 which CodeBlocks doesn't or poor design, or whatever.

 - Jonathan M Davis

Aug 20 2010
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:
 Three good blog posts about undefined behaviour in C and C++: 
 http://blog.regehr.org/archives/213 http://blog.regehr.org/archives/226 
 http://blog.regehr.org/archives/232
 
 In those posts (and elsewhere) the expert author gives several good bites to
 the ass of most compiler writers.
 
 Among other things in those three posts he talks about two programs as:
 
 import std.c.stdio: printf; void main() { printf("%d\n", -int.min); }
 
 import std.stdio: writeln; void main() { enum int N = (1L).sizeof * 8; auto
 max = (1L << (N - 1)) - 1; writeln(max); }
 
 I believe that D can't be considered a step forward in system language
 programming until it gives a much more serious consideration for
 integer-related overflows (and integer-related undefined behaviour).
 
 The good thing is that Java is a living example that even if you remove most
 integer-related undefined behaviours your Java code is still able to run as
 fast as C and sometimes faster (on normal desktops).

You're conflating two different things here - undefined behavior and behavior on overflow. The Java spec says that integer overflow is ignored, for example. In C++, overflow behavior is undefined because C++ still supports ones-complement arithmetic. Java and D specify integer arithmetic to be 2's complement. Java defined left shift to, not surprisingly, match what the x86 CPU does. This, of course, will conveniently not result in any penalty on the x86 for conforming to the spec.
Aug 20 2010
parent KennyTM~ <kennytm gmail.com> writes:
On Aug 21, 10 02:12, Walter Bright wrote:
[snip]
 You're conflating two different things here - undefined behavior and
 behavior on overflow. The Java spec says that integer overflow is
 ignored, for example.

 In C++, overflow behavior is undefined because C++ still supports
 ones-complement arithmetic. Java and D specify integer arithmetic to be
 2's complement. Java defined left shift to, not surprisingly, match what
 the x86 CPU does. This, of course, will conveniently not result in any
 penalty on the x86 for conforming to the spec.

I believe D requires signed integers be represented in 2's complement, but the specification didn't document it (grepping 'complement' in phobos/docsrc gives nothing related).
Aug 20 2010
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Fri, 20 Aug 2010 19:04:41 +0200, Andrej Mitrovic wrote:

 What are these Java programs for the desktop that run fast? I haven't
 encountered any, but maybe that's just because I didn't try them all
 out. Eclipse takes at least 20 seconds to load on startup on my quad
 core, that's not very fast. On the other hand, CodeBlocks which is coded
 in C++ and has  a few dozen plugins installed runs in an instant.

Now that's a fair comparison! "Crysis runs so slowly but a hello world written in Go is SO fast. This must prove that Go is much faster than C+ +!" I think CodeBlocks is one of the most lightweight IDEs out there. Does it even have full semantic autocompletion? Eclipse, on the other hand, comes with almost everything you can imagine. If you turn off the syntax check, Eclipse works just as fast as any native application on a modern desktop.
Aug 20 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"retard" <re tard.com.invalid> wrote in message 
news:i4mrss$cam$1 digitalmars.com...
 Fri, 20 Aug 2010 19:04:41 +0200, Andrej Mitrovic wrote:

 What are these Java programs for the desktop that run fast? I haven't
 encountered any, but maybe that's just because I didn't try them all
 out. Eclipse takes at least 20 seconds to load on startup on my quad
 core, that's not very fast. On the other hand, CodeBlocks which is coded
 in C++ and has  a few dozen plugins installed runs in an instant.

Now that's a fair comparison! "Crysis runs so slowly but a hello world written in Go is SO fast. This must prove that Go is much faster than C+ +!" I think CodeBlocks is one of the most lightweight IDEs out there. Does it even have full semantic autocompletion? Eclipse, on the other hand, comes with almost everything you can imagine. If you turn off the syntax check, Eclipse works just as fast as any native application on a modern desktop.

I've tried eclipse with the fancy stuff off, and it's still slower than C::B or PN2 for me.
Aug 20 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"retard" <re tard.com.invalid> wrote in message 
news:i4mt6o$cam$2 digitalmars.com...
 Fri, 20 Aug 2010 17:37:18 -0400, Nick Sabalausky wrote:

 "retard" <re tard.com.invalid> wrote in message
 news:i4mrss$cam$1 digitalmars.com...
 If you turn off the
 syntax check, Eclipse works just as fast as any native application on a
 modern desktop.

I've tried eclipse with the fancy stuff off, and it's still slower than C::B or PN2 for me.

Of course it is. You're comparing apples and oranges.

Fer cryin out loud, which one is it? Is Eclipse supposed to be "just as fast as any native application", or is it "of course it's slower"? First you say one, then you say the other.
Aug 20 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"retard" <re tard.com.invalid> wrote in message 
news:i4mt6o$cam$2 digitalmars.com...
 When comparing, you also need to understand how the JIT compiler works.
 Using the Sun server VM, you need to visit each menu and use each visual
 component a few times to make the VM recompile the code. After few hours
 of use everything should run as fast as it can. Upgrading the JVM might
 also help because there are more JIT optimizations available.

If I have to use a program written in Language-X for awhile before it stops being slow, then I'm going to feel perfectly justified in calling Language-X a slow language.
Aug 20 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:
 If I have to use a program written in Language-X for awhile before it stops 
 being slow, then I'm going to feel perfectly justified in calling Language-X 
 a slow language.

Also consider that Java really doesn't give you much to work with if you want to take hand-tuning past a certain point.
Aug 20 2010
parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:i4nqnk$19fd$2 digitalmars.com...
 Nick Sabalausky wrote:
 If I have to use a program written in Language-X for awhile before it 
 stops being slow, then I'm going to feel perfectly justified in calling 
 Language-X a slow language.

Also consider that Java really doesn't give you much to work with if you want to take hand-tuning past a certain point.

Absolutely. In fact, that's why I take issue with all those old Java benchmarks that would compare Java code to *equivalent* C/C++ code (allegedly for the sake of a fair apples-to-apples): The C/C++ code can be further optimized, the Java can't. With .NET, you maybe can optimize to a certain extent, just because at least it *allows* pointers (although the type system gets in the way a lot - I once tried to convert a buffer to a struct in C# (think "idiomatic-C way to load a BMP-header"), and I spent hours trying to figure out how to do it without any copying/allocation/runtime-reflection before finally concluding "If it's possible, I no longer care how". In C/C++/D, I can do it with just a simple cast).
Aug 21 2010
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 20/08/2010 22:37, Nick Sabalausky wrote:
 "retard"<re tard.com.invalid>  wrote in message
 news:i4mrss$cam$1 digitalmars.com...
 Fri, 20 Aug 2010 19:04:41 +0200, Andrej Mitrovic wrote:

 What are these Java programs for the desktop that run fast? I haven't
 encountered any, but maybe that's just because I didn't try them all
 out. Eclipse takes at least 20 seconds to load on startup on my quad
 core, that's not very fast. On the other hand, CodeBlocks which is coded
 in C++ and has  a few dozen plugins installed runs in an instant.

Now that's a fair comparison! "Crysis runs so slowly but a hello world written in Go is SO fast. This must prove that Go is much faster than C+ +!" I think CodeBlocks is one of the most lightweight IDEs out there. Does it even have full semantic autocompletion? Eclipse, on the other hand, comes with almost everything you can imagine. If you turn off the syntax check, Eclipse works just as fast as any native application on a modern desktop.

I've tried eclipse with the fancy stuff off, and it's still slower than C::B or PN2 for me.

All these comments about Eclipse takes this time to load, or Eclipse is slow when used, etc., are really meaningless unless you tell us something about what actual plugins and features are installed and used. Unlike CodeBlocks which is "a free C++ IDE", Eclipse proper is the Eclipse Platform, which is a platform (duh) and doesn't do anything useful by itself. Particularly since there is not even a standard/single "Eclipse" download: http://www.eclipse.org/downloads/ , unlike Codeblocks. The days were JDT would be the main thing 95% of Eclipse users would use are long gone. So are you using JDT, CDT, Descent, something else? If JDT, do you have extra tools, like the J2EE Web Tools? (these add massive bloat) What about source control plugins, or plugins not provided by the Eclipse Foundation, etc? All of these are a wildcard that can affect performance. For example, I definitely note that sometimes my workspace chokes when I do certain SVN or file related operations (with Subclipse btw, not Subversive). I also noted, when Eclipse 3.6 came out, some sluggishness when working with JDT, even when just typing code (in this case it was very subtle, almost imperceptible, but I still felt it and it was quite annoying). I suspected not JDT, but Mylyn, so I uninstalled it, and now things are back to normal. (there might be a fix or workaround for that issue in Mylyn, but since I don't use it, I didn't bother) I would definitely be quite annoying if Eclipse was not responsive for the vast majority of coding tasks. As for startup time, I hardly care anything about that : http://www.digitalmars.com/d/archives/digitalmars/D/Re_Eclipse_startup_time_Was_questions_on_PhanTango_merger_was_Merging_Tangobos_into_Tango_60160.html#N60346 (except when I'm doing PDE development, but that's a different thing) -- Bruno Medeiros - Software Engineer
Oct 01 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Kind of like playing Crysis with all settings on low, right? Can't see
sh*t but it still lags. :p

On Fri, Aug 20, 2010 at 11:37 PM, Nick Sabalausky <a a.a> wrote:
 "retard" <re tard.com.invalid> wrote in message
 news:i4mrss$cam$1 digitalmars.com...
 Fri, 20 Aug 2010 19:04:41 +0200, Andrej Mitrovic wrote:

 What are these Java programs for the desktop that run fast? I haven't
 encountered any, but maybe that's just because I didn't try them all
 out. Eclipse takes at least 20 seconds to load on startup on my quad
 core, that's not very fast. On the other hand, CodeBlocks which is code=



 in C++ and has =A0a few dozen plugins installed runs in an instant.

Now that's a fair comparison! "Crysis runs so slowly but a hello world written in Go is SO fast. This must prove that Go is much faster than C+ +!" I think CodeBlocks is one of the most lightweight IDEs out there. Does i=


 even have full semantic autocompletion? Eclipse, on the other hand, come=


 with almost everything you can imagine. If you turn off the syntax check=


 Eclipse works just as fast as any native application on a modern desktop=


 I've tried eclipse with the fancy stuff off, and it's still slower than C=

 or PN2 for me.

Aug 20 2010
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Fri, 20 Aug 2010 17:37:18 -0400, Nick Sabalausky wrote:

 "retard" <re tard.com.invalid> wrote in message
 news:i4mrss$cam$1 digitalmars.com...
 Fri, 20 Aug 2010 19:04:41 +0200, Andrej Mitrovic wrote:

 What are these Java programs for the desktop that run fast? I haven't
 encountered any, but maybe that's just because I didn't try them all
 out. Eclipse takes at least 20 seconds to load on startup on my quad
 core, that's not very fast. On the other hand, CodeBlocks which is
 coded in C++ and has  a few dozen plugins installed runs in an
 instant.

Now that's a fair comparison! "Crysis runs so slowly but a hello world written in Go is SO fast. This must prove that Go is much faster than C+ +!" I think CodeBlocks is one of the most lightweight IDEs out there. Does it even have full semantic autocompletion? Eclipse, on the other hand, comes with almost everything you can imagine. If you turn off the syntax check, Eclipse works just as fast as any native application on a modern desktop.

I've tried eclipse with the fancy stuff off, and it's still slower than C::B or PN2 for me.

Of course it is. You're comparing apples and oranges. The core of Eclipse is much more customizable. I haven't used C::B lately, but does it even have a plugin updater functionality yet? If you want a fair comparison, write the _same_ application in Java and in some other language. E.g. jEdit is probably a bit faster with all plugins turned off. When comparing, you also need to understand how the JIT compiler works. Using the Sun server VM, you need to visit each menu and use each visual component a few times to make the VM recompile the code. After few hours of use everything should run as fast as it can. Upgrading the JVM might also help because there are more JIT optimizations available.
Aug 20 2010
parent reply Jonathan M Davis <jmdavisprog gmail.com> writes:
On Friday 20 August 2010 22:11:30 Nick Sabalausky wrote:
 Fer cryin out loud, which one is it? Is Eclipse supposed to be "just as
 fast as any native application", or is it "of course it's slower"? First
 you say one, then you say the other.

LOL. Personally, I have to say that Eclipse is a huge achievement and in many ways is a fantastic application. It's so modular and flexible that it's practically insane. But that comes with a cost, and while I think that what they've done with it is far more doable in Java than in C++, it's bound to be less efficient because it was done in Java. As far as general application development goes, I think that Eclipse is a very bad example simply because it's so flexible. Most of its features relating to modularity and plugins and such is totally unnecessary in your typical desktop application. I expect that your typical desktop application would do far better performance-wise when written in Java than Eclipse has done. But either because Java isn't generally good enough for application development or because people think that it isn't there don't seem to be very many desktop applications which are written in Java. So, it's hard to say. - Jonathan M Davis
Aug 20 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisprog gmail.com> wrote in message 
news:mailman.444.1282368222.13841.digitalmars-d puremagic.com...
 I expect that your typical desktop application would do far better
 performance-wise when written in Java than Eclipse has done. But either 
 because
 Java isn't generally good enough for application development or because 
 people
 think that it isn't there don't seem to be very many desktop applications 
 which
 are written in Java. So, it's hard to say.

The best C/C++ <-> Java application comparison I can think of off-the-top-of-my-head would be uTorrent and Azureus (That's the actual Azureus, not Vuze - I don't care what the creators claim, Vuze is a *completely* different program.) uTorrent and Azureus are nearly-identical in purpose, features and UI. uTorrent is smooth as silk. Azureus is a bit sluggish (certainly not Eclipse sluggish, but no where near uTorrent). uTorrent is C/C++. Azureus is Java. And just overall, the majority of responsive, non-bloaty software I've used *has* been natively-compiled stuff. The majority of sluggish, bloated software I've used has been some form of interpreted code or VM, such as JVM or .NET. So even if we're comparing apples and oranges, if Farm A makes apples that are usually juicy and sweet, and Farm B makes oranges that usually aren't, I'm going to feel fairly confident in saying that Farm A kicks Farm B's ass.
Aug 20 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Jonathan M Davis (jmdavisprog gmail.com)'s article
 Hopefully D will prove to be a solution with development benefits
 on par with Java and .NET and efficiency benefits on par with C++.
 - Jonathan M Davis

If "on par" with Java and .NET is all we're aiming for, then we've really set the bar low. I think that D's metaprogramming/generic system will set the bar much higher once D gets more library and tool support. I've thought about how I would implement an API with comparable ease of use and flexibility for some libraries I've written or used in D, using Java, C# or C++. I don't think it's possible. The only other languages where I think a similarly easy to use API would be implementable are the (really slow) dynamic languages like Python and Ruby. For an example, try implementing an API comparable to std.range in flexibility and ease of use in any statically typed, efficient language besides D.
Aug 21 2010
parent Justin Johansson <no spam.com> writes:
On 22/08/10 21:01, retard wrote:
 Sat, 21 Aug 2010 18:31:16 -0700, Jonathan M Davis wrote:

 But still, being able to consistently match C++ at what it's good at and
 C# and Java at what they're good at in one language is big, and I really
 don't think that we're there yet. I don't know how efficient we are in
 comparison to C++, but I expect that there are a number of areas which
 need improvement (things like inlining, the garbage collector, etc.) if
 we want the average D program to match the average C++ program for
 efficiency. And we definitely don't match Java and C# for ease of use
 and maintainability at this point, but most of that is simply an issue
 of libraries and tools, both of which are being worked on. So, we're
 getting there, but I don't think that we're there yet. And certainly,
 once we do get there, there's no reason to stay only "on par" with them.
 We should always be looking to improve D and its libraries and tools.

Should D also look more academic than Haskell, F#, Scala, DDC, Clojure, BitC, Factor, and Ur/Web ?

No, of course not, well, uhhm, at least going by the blurp at http://www.digitalmars.com/d/index.html where it says "It [D] is not governed by a corporate agenda or any overarching theory of programming. The needs and contributions of the D programming community form the direction it goes." Where is it written that the design of a PL should be governed by an overarching theory of programming (and/or a corporate agenda)? Axioms and logic and all that formal stuff are just so anti-democratic. Ad hoc PL design by newsgroup is so much more consensual and politically correct in this modern age of equity and diversity. :-)
Aug 22 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Fri, 20 Aug 2010 16:57:34 -0500, Andrei Alexandrescu wrote:

 On 08/20/2010 04:48 PM, retard wrote:
 I've tried eclipse with the fancy stuff off, and it's still slower
 than C::B or PN2 for me.

Of course it is. You're comparing apples and oranges. The core of Eclipse is much more customizable.

I've seen a live demo by Erich Gamma in which he wrote a simple Eclipse plugin inside Eclipse and then he immediately used it. It was pretty darn impressive. Today's compiler technology still has us pay for customizability even when it's not realized, so even with all plugins turned off a pluggable program would still be slower than a monolithic one.

Indeed. But even if it (static compilation) allowed controlling the customizability in every possible way, there can't be a single binary that suits everyone. Programs like C::B force you to choose these features on compile time. This is very typical in C/C++ applications - you have the choice, but it has to be done as early as possible. For instance, I forgot to compile in mp3 support when building ffmpeg or some other multimedia lib. Now the only choice I have is to recompile the library and possibly even all dependencies. It's the same thing in some Linux distributions - they forgot to set on the Truetype bytecode interpreter so I need to recompile some core libraries. Eclipse's philosophy seems to be completely different - some of the choices are made on launching the application, others when starting individual components. The only limitation that comes to mind is that because of SWT, Eclipse needs two distributions (32-bit and 64-bit), at least on Linux. Swing using applications don't have this limitation.
Aug 20 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Fri, 20 Aug 2010 15:07:50 -0700, Walter Bright wrote:

 retard wrote:
 After few hours
 of use everything should run as fast as it can.

I kinda don't really want to wait a few hours for my editor to stop lagging.

You don't need to use it that long. I only gave a pessimistic estimate on when all JIT compilation stops. Surely the most used features get recompiled faster. The second use of any Java function should already trigger the JIT in some cases. This is a bit unfortunate for desktop applications because the first impression is that everything lags. But the thing is, if you try something TWICE or more, it's orders of magnitude faster.
Aug 20 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
The current problem with CB, afaik, is that plugins need to be
recompiled in order to work with new versions of CB. But you can
enable/disable them at will, and most plugins have their settings
appear in the options menu similar to the way Eclipse plugins work.
It's no secret Eclipse is more mature, CB only has a a limited number
of contributors (at least to my knowledge).

On Sat, Aug 21, 2010 at 12:16 AM, retard <re tard.com.invalid> wrote:
 Fri, 20 Aug 2010 16:57:34 -0500, Andrei Alexandrescu wrote:

 On 08/20/2010 04:48 PM, retard wrote:
 I've tried eclipse with the fancy stuff off, and it's still slower
 than C::B or PN2 for me.




Aug 20 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Fri, 20 Aug 2010 16:04:46 -0400, Nick Sabalausky wrote:

 "Kagamin" <spam here.lot> wrote in message
 news:i4mjl0$2ucg$1 digitalmars.com...
 Andrej Mitrovic Wrote:

 What are these Java programs for the desktop that run fast? I haven't
 encountered any, but maybe that's just because I didn't try them all
 out. Eclipse takes at least 20 seconds to load on startup on my quad
 core, that's not very fast. On the other hand, CodeBlocks which is
 coded in C++ and has  a few dozen plugins installed runs in an
 instant.


For me, C::B always took somewhere around ten seconds to start up (and then it kept using 5-10% CPU even when idling with all plugins disabled - a number of other people reported the same thing). But it's been awhile since I used it though, so maybe that's all fixed now. But yea, I can't remember ever seeing a non-trivial Java app that wasn't a bit on the sluggish side.

If you want, you could go through these applications http://java.sun.com/products/jfc/tsc/sightings/ Maybe some of them don't suck. There are also games written in Java (your Java enabled browser can run these): quake 2 port - http://bytonic.de/html/jake2_webstart.html 4 kB games - http://javaunlimited.net/games/java4k_2007.php some opengl demos - http://slick.cokeandcode.com/static.php?page=demos Our gamedevs use Java 7 ea, so you could try if it's faster (at least the webstart progress dialog is different and can be customized): http://dlc.sun.com.edgesuite.net/jdk7/binaries/index.html
Aug 20 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Fri, 20 Aug 2010 19:06:32 -0400, bearophile wrote:

 retard:
 quake 2 port - http://bytonic.de/html/jake2_webstart.html

Have you read some of that code? No Java programmer writes code like that.

Sure, so write it in more idiomatic Java way and try again? Too slow? These applications are GPU bound so how is it even possible?
 That code is the "exception that confirms the rule" (I don't know
 how this is normally written in English). The rule is that Java code is
 slow ;-)

I don't know what you're talking about. Have you ever tried writing efficient Java applications? Are these any better? http://www.jmonkeyengine.com/movies_demos.php
Aug 20 2010
prev sibling next sibling parent SK <sk metrokings.com> writes:
On Fri, Aug 20, 2010 at 4:16 PM, Walter Bright
<newshound2 digitalmars.com> wrote:
 And frankly, it's retarded to compile the same program over and over, every
 time you use it.

How about IBM's TIMI? My understanding is that it's a hybrid approach that gives you machine independence with a one-time recompilation that is stored back into the executable. Or something like that. -steve
Aug 20 2010
prev sibling next sibling parent SK <sk metrokings.com> writes:
On Fri, Aug 20, 2010 at 7:07 PM, Walter Bright
<newshound2 digitalmars.com> wrote:
 SK wrote:
 On Fri, Aug 20, 2010 at 4:16 PM, Walter Bright
 <newshound2 digitalmars.com> wrote:
 And frankly, it's retarded to compile the same program over and over,
 every
 time you use it.

How about IBM's TIMI? =A0My understanding is that it's a hybrid approach that gives you machine independence with a one-time recompilation that is stored back into the executable. =A0Or something like that.

Beats me, I've never heard of it.

Then to make this more concrete, what if D had an option to suspend compilation after the front-end finished? The resulting executable contains the abstract RTL blobs and the compiler backend, which finishes the job for the specific platform on which the executable is launched. The final binary is cached for subsequent launches. You get good machine independence and the approach provides performance wins for operations like vectorizing where you don't know in advance what kind of SSE support you'll find. Hypothetically, why not? I dug around and found this: http://www.itjungle.com/tfh/tfh082007-printer01.html
From the article.

i5/OS platform when you create applications, which explains the problem customers ran into in 1995 and which IBM wants them to avoid in 2008. A programmer writes an application in say, RPG. They run it through a compiler, either using the Original Program Model (OPM) or the Integrated Language Environment (ILE) compilers, and the code compiles so they can run it. Or, rather, that is what it looks like to the programmer. What is really happening is that this application is compiled into an intermediate stage, which some IBMers have called RPG templates (in the case of RPG applications). These templates have a property called observability, which in essence means they are compiled to the TIMI layer. These intermediate templates are then used by the TIMI layer on an actual piece of hardware with a specific processor and instruction set to compile the application to run on that specific processor. TIMI compiles these RPG templates down to actual compiled code behind the scenes the first time an application runs, and because the code was originally compiled to the TIMI layer, there is no need to change the source code. Only the object code changes, which end users never had access to anyway because only TIMI can reach down there. This is the brilliant way that IBM has preserved customers' vast investments in RPG, COBOL, and other applications over the years
Aug 20 2010
prev sibling next sibling parent SK <sk metrokings.com> writes:
On Fri, Aug 20, 2010 at 8:46 PM, Walter Bright
<newshound2 digitalmars.com> wrote:
 SK wrote:
 Then to make this more concrete, what if D had an option to suspend
 compilation after the front-end finished? =A0The resulting executable
 contains the abstract RTL blobs and the compiler backend, which
 finishes the job for the specific platform on which the executable is
 launched. =A0The final binary is cached for subsequent launches. =A0You
 get good machine independence and the approach provides performance
 wins for operations like vectorizing where you don't know in advance
 what kind of SSE support you'll find.

 Hypothetically, why not?

It's an old idea, but I think it's pointless. Instead of caching the intermediate code, just cache the source code.

Huh? Do you mean to say: Instead of shipping the intermediate code, always ship source code. -or- Instead of caching the binary, just cache the source code. Neither of those guesses make general sense so I'm afraid I miss your point= .
Aug 20 2010
prev sibling next sibling parent reply SK <sk metrokings.com> writes:
On Fri, Aug 20, 2010 at 10:11 PM, Walter Bright
<newshound2 digitalmars.com> wrote:
 SK wrote:
 Do you mean to say:
 Instead of shipping the intermediate code, always ship source code.

Yes. Why doesn't it make sense?

I love open source projects, but off the top of my head here are some reasons that's not a general substitute for TIMI for D: 1) What about closed source software? 2) From-source builds may be more complex or resource consuming than could be accommodated on the machine the customer used to launch, e.g. a hand-held device. 3) The source may have sizable irrelevant content for a particular product instantiation, compile time conditionals, etc I have no vested interest in the TIMI idea, but it feels good to me. We get platform independence, custom fit binaries, and require no change to the language. Not to mention it's proven to be a durable model at IBM.
Aug 20 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"SK" <sk metrokings.com> wrote in message 
news:mailman.445.1282371389.13841.digitalmars-d puremagic.com...
 On Fri, Aug 20, 2010 at 10:11 PM, Walter Bright
 <newshound2 digitalmars.com> wrote:
 SK wrote:
 Do you mean to say:
 Instead of shipping the intermediate code, always ship source code.

Yes. Why doesn't it make sense?

I love open source projects, but off the top of my head here are some reasons that's not a general substitute for TIMI for D:

I agree there are some benefits, but I suspect they may be smaller than they seem:
 1) What about closed source software?

True. Although IMO (see my post in another branch of this thread) closed-source is rarely, if ever, beneficial anyway, despite how it's often perceived.
 2) From-source builds may be more complex or resource consuming than
 could be accommodated on the machine the customer used to launch, e.g.
 a hand-held device.

I can't imagine it would be significantly more than something like JIT (or non-JIT interpreted code). Unless it's C++, of course.
 3) The source may have sizable irrelevant content for a particular
 product instantiation, compile time conditionals, etc

- Unless I'm just becoming a dinosaur, sizeable content is rarely code. More likely other binary assets. - Code can be huffman-compressed with significant size savings and quickly/easily unzipped on-the-fly. Even the GBA has some built-in on-the-fly unzipping ability that was often used in games (for assets though, not code). - I don't think I've ever seen a cross-platform program that had platform-specific code that made up any more than a small fraction of the total code. Of course, I'm not saying that using source as IL is universially, undeniably, better period, no matter what, or anything like that. I agree that binary IL has some nice aspects. I'm just not convinced that it's as much of an improvement over source-as-IL as it would initially seem.
Aug 20 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:
 Of course, I'm not saying that using source as IL is universially, 
 undeniably, better period, no matter what, or anything like that. I agree 
 that binary IL has some nice aspects. I'm just not convinced that it's as 
 much of an improvement over source-as-IL as it would initially seem.

If the "source code" consists of tokenized source code, I think it would compare very favorably with byte code in terms of size.
Aug 21 2010
prev sibling next sibling parent SK <sk metrokings.com> writes:
Hi Nick,

On Fri, Aug 20, 2010 at 10:37 PM, Nick Sabalausky <a a.a> wrote:
 I'm curious what you have to say about #1. But I consider #2 to be a very
 poor reason because:

 - There's always reverse engineering.
 - There's always obfuscation.
 - IL may even provide better reverse-engineering results than machine code,
 depending on the IL.
 - All the companies sinking time and money into JS and PHP middleware don't
 seem to have a problem with handing out their source.
 - If someone's gonna steal a product and rebrand it as their own, they don't
 usually need the source, and having it would probably only be of fairly
 small help, if any.
 - As a customer, the idea of spending money on a product that I can't
 service myself if/when the company goes under or loses interest makes me
 nervous. Providing their source would given them a competetive advantage.
 - Even though providing source gets in the way of effective DRM (as if there
 even were such a thing), DRM itself gets in the way of sales.
 - Distributing in source form makes certain things possible that wouldn't
 otherwise be, like virtual template functions (in theory, even if not in
 actual D practice).

Yes, yes and yes - especially about not needing source to be a pirate. But your perspective is not shared by many big companies shipping software I care about. The open source movement has even turned up the contrast in this regard for closed source companies. Without conducting a thorough Fortune 500 survey, I will assert that shipping source is an emotionally burdened action at the management level, and this roadblock is avoided by "simply" running code through front end compilation. So, just do that and move on the to next problem.
Aug 20 2010
prev sibling next sibling parent reply SK <sk metrokings.com> writes:
On Fri, Aug 20, 2010 at 11:38 PM, Walter Bright
<newshound2 digitalmars.com> wrote:
 SK wrote:
 On Fri, Aug 20, 2010 at 10:11 PM, Walter Bright
 <newshound2 digitalmars.com> wrote:
 SK wrote:
 Do you mean to say:
 Instead of shipping the intermediate code, always ship source code.

Yes. Why doesn't it make sense?

I love open source projects, but off the top of my head here are some reasons that's not a general substitute for TIMI for D: 1) What about closed source software?

Won't work anyway. Java bytecodes are trivially turned back into source.

IMO, reverse engineering technology is not the issue.
 2) From-source builds may be more complex or resource consuming than
 could be accommodated on the machine the customer used to launch, e.g.
 a hand-held device.

I've worked on a Java VM enough to know that won't be a problem.

Why waste your batteries running deep and complex front-end optimizers that have nothing to do with the target platform?
 3) The source may have sizable irrelevant content for a particular
 product instantiation, compile time conditionals, etc

You can run it through a comment stripper first.

Why stop there? If you have to create some waypoint that isn't really the source and isn't the binary, why not finish off the platform independent lifting in the front end? I am getting zero admission from you that there is any goodness to be found in the TIMI thing. I don't understand that. Do you really just hate the idea through and through?
Aug 21 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"SK" <sk metrokings.com> wrote in message 
news:mailman.448.1282374566.13841.digitalmars-d puremagic.com...
 On Fri, Aug 20, 2010 at 11:38 PM, Walter Bright
 <newshound2 digitalmars.com> wrote:
 SK wrote:
 I love open source projects, but off the top of my head here are some
 reasons that's not a general substitute for TIMI for D:
 1) What about closed source software?

Won't work anyway. Java bytecodes are trivially turned back into source.

IMO, reverse engineering technology is not the issue.

The *whole point* of closed-source is that the source isn't available. If Java bytecode is trivially turned back into meaningful source, then closed-source Java ain't closed-source anyway.
 2) From-source builds may be more complex or resource consuming than
 could be accommodated on the machine the customer used to launch, e.g.
 a hand-held device.

I've worked on a Java VM enough to know that won't be a problem.

Why waste your batteries running deep and complex front-end optimizers that have nothing to do with the target platform?

The compiler's not going to do any deep analysis of code that's versioned out for a different platform. Just lexing, maybe parsing, and that's it. AIUI, the real battery-eating processing is elsewhere, mainly in stuff that's also going to be done by any decent JIT engine. (Not that there wouldn't be at least *some* saved cycles.)
Aug 21 2010
next sibling parent Don <nospam nospam.com> writes:
Nick Sabalausky wrote:
 "SK" <sk metrokings.com> wrote in message 
 news:mailman.448.1282374566.13841.digitalmars-d puremagic.com...
 On Fri, Aug 20, 2010 at 11:38 PM, Walter Bright
 <newshound2 digitalmars.com> wrote:
 SK wrote:
 I love open source projects, but off the top of my head here are some
 reasons that's not a general substitute for TIMI for D:
 1) What about closed source software?



The *whole point* of closed-source is that the source isn't available. If Java bytecode is trivially turned back into meaningful source, then closed-source Java ain't closed-source anyway.
 2) From-source builds may be more complex or resource consuming than
 could be accommodated on the machine the customer used to launch, e.g.
 a hand-held device.


that have nothing to do with the target platform?

The compiler's not going to do any deep analysis of code that's versioned out for a different platform. Just lexing, maybe parsing, and that's it.

It should do more than that. But...
 AIUI, the real battery-eating processing is elsewhere, mainly in stuff 
 that's also going to be done by any decent JIT engine. (Not that there 
 wouldn't be at least *some* saved cycles.)

this is probably correct: it's the optimisation steps that burn the most cycles. Personally I think the most interesting platform-dependent stuff happens in the front-end. That's the only place you can change algorithms based on the platform, and algorithmic changes are where the big gains are. And most of the advocacy literature for JIT compilation seems oblivious to that fact. You can do some really nice stuff if you compile at install time.
Aug 22 2010
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 21/08/2010 08:22, Nick Sabalausky wrote:
 "SK"<sk metrokings.com>  wrote in message
 news:mailman.448.1282374566.13841.digitalmars-d puremagic.com...
 On Fri, Aug 20, 2010 at 11:38 PM, Walter Bright
 <newshound2 digitalmars.com>  wrote:
 SK wrote:
 I love open source projects, but off the top of my head here are some
 reasons that's not a general substitute for TIMI for D:
 1) What about closed source software?

Won't work anyway. Java bytecodes are trivially turned back into source.

IMO, reverse engineering technology is not the issue.

The *whole point* of closed-source is that the source isn't available. If Java bytecode is trivially turned back into meaningful source, then closed-source Java ain't closed-source anyway.

Obfuscated Java code/bytecode is definitively not turned back into meaningful source. -- Bruno Medeiros - Software Engineer
Oct 01 2010
prev sibling next sibling parent reply Jonathan M Davis <jmdavisprog gmail.com> writes:
On Friday 20 August 2010 22:52:37 Nick Sabalausky wrote:
 "Jonathan M Davis" <jmdavisprog gmail.com> wrote in message
 news:mailman.444.1282368222.13841.digitalmars-d puremagic.com...
 
 I expect that your typical desktop application would do far better
 performance-wise when written in Java than Eclipse has done. But either
 because
 Java isn't generally good enough for application development or because
 people
 think that it isn't there don't seem to be very many desktop applications
 which
 are written in Java. So, it's hard to say.

The best C/C++ <-> Java application comparison I can think of off-the-top-of-my-head would be uTorrent and Azureus (That's the actual Azureus, not Vuze - I don't care what the creators claim, Vuze is a *completely* different program.) uTorrent and Azureus are nearly-identical in purpose, features and UI. uTorrent is smooth as silk. Azureus is a bit sluggish (certainly not Eclipse sluggish, but no where near uTorrent). uTorrent is C/C++. Azureus is Java. And just overall, the majority of responsive, non-bloaty software I've used *has* been natively-compiled stuff. The majority of sluggish, bloated software I've used has been some form of interpreted code or VM, such as JVM or .NET. So even if we're comparing apples and oranges, if Farm A makes apples that are usually juicy and sweet, and Farm B makes oranges that usually aren't, I'm going to feel fairly confident in saying that Farm A kicks Farm B's ass.

Those seem to be reasonable comparisons. Of course, you don't choose Java or .NET because it gets you efficient code (though you'd probably like efficient code). You use them for reasons like fast development time and (for Java at least) portability. The gains in maintenance and development time are easily large enough to justify the loss in efficiency on many (perhaps even most) software projects. Of course, there are projects where Java and .NET don't cut it, but they often do. Hopefully D will prove to be a solution with development benefits on par with Java and .NET and efficiency benefits on par with C++. - Jonathan M Davis
Aug 21 2010
parent "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisprog gmail.com> wrote in message 
news:mailman.449.1282374676.13841.digitalmars-d puremagic.com...
 On Friday 20 August 2010 22:52:37 Nick Sabalausky wrote:
 "Jonathan M Davis" <jmdavisprog gmail.com> wrote in message
 news:mailman.444.1282368222.13841.digitalmars-d puremagic.com...

 I expect that your typical desktop application would do far better
 performance-wise when written in Java than Eclipse has done. But either
 because
 Java isn't generally good enough for application development or because
 people
 think that it isn't there don't seem to be very many desktop 
 applications
 which
 are written in Java. So, it's hard to say.

The best C/C++ <-> Java application comparison I can think of off-the-top-of-my-head would be uTorrent and Azureus (That's the actual Azureus, not Vuze - I don't care what the creators claim, Vuze is a *completely* different program.) uTorrent and Azureus are nearly-identical in purpose, features and UI. uTorrent is smooth as silk. Azureus is a bit sluggish (certainly not Eclipse sluggish, but no where near uTorrent). uTorrent is C/C++. Azureus is Java. And just overall, the majority of responsive, non-bloaty software I've used *has* been natively-compiled stuff. The majority of sluggish, bloated software I've used has been some form of interpreted code or VM, such as JVM or .NET. So even if we're comparing apples and oranges, if Farm A makes apples that are usually juicy and sweet, and Farm B makes oranges that usually aren't, I'm going to feel fairly confident in saying that Farm A kicks Farm B's ass.

Those seem to be reasonable comparisons. Of course, you don't choose Java or .NET because it gets you efficient code (though you'd probably like efficient code). You use them for reasons like fast development time and (for Java at least) portability. The gains in maintenance and development time are easily large enough to justify the loss in efficiency on many (perhaps even most) software projects. Of course, there are projects where Java and .NET don't cut it, but they often do. Hopefully D will prove to be a solution with development benefits on par with Java and .NET and efficiency benefits on par with C++.

Yup. Good points. If it weren't for D, and I had to use C or C++ for native-code apps, I wouldn't hesitate at using a .NET or JVM language for whatever projects I could.
Aug 21 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sat, 21 Aug 2010 01:11:30 -0400, Nick Sabalausky wrote:

 "retard" <re tard.com.invalid> wrote in message
 news:i4mt6o$cam$2 digitalmars.com...
 Fri, 20 Aug 2010 17:37:18 -0400, Nick Sabalausky wrote:

 "retard" <re tard.com.invalid> wrote in message
 news:i4mrss$cam$1 digitalmars.com...
 If you turn off the
 syntax check, Eclipse works just as fast as any native application on
 a modern desktop.

I've tried eclipse with the fancy stuff off, and it's still slower than C::B or PN2 for me.

Of course it is. You're comparing apples and oranges.

Fer cryin out loud, which one is it? Is Eclipse supposed to be "just as fast as any native application", or is it "of course it's slower"? First you say one, then you say the other.

I meant to say that Eclipse (perceivably) works just as fast as any (feature-wise equivalent) native application on a modern desktop. I recommended turning off some of the functionality to make it behave more like C::B and similar lightweight applications. The idea behind desktop Java applications is that since the application would run 100..100000 times faster than it needs to on a modern PC, a 2..100 times slower Java version is totally acceptable. Heck, I even use applications (with plugins) written in Ruby. Ruby has a lot worse VM that does not even do JIT compilation. To summarize: - the JIT causes horrible interactive performance right after startup (use of the client VM might help a bit. Oracle might also be working on a hybrid client/server VM) - the JIT and the GC cause noticeable delays, but only occasionally (use of the new low-latency GC and tuning the VM options might help here) - the execution performance IS worse, but the perceivable performance is often acceptable - application platforms such as Eclipse or Netbeans provide a very high level of flexibility, portability, and memory safety
Aug 21 2010
prev sibling next sibling parent =?iso-8859-2?B?VG9tZWsgU293afFza2k=?= <just ask.me> writes:
Dnia 21-08-2010 o 05:36:28 SK <sk metrokings.com> napisa=B3(a):

 Then to make this more concrete, what if D had an option to suspend
 compilation after the front-end finished?  The resulting executable
 contains the abstract RTL blobs and the compiler backend, which
 finishes the job for the specific platform on which the executable is
 launched.  The final binary is cached for subsequent launches.  You
 get good machine independence and the approach provides performance
 wins for operations like vectorizing where you don't know in advance
 what kind of SSE support you'll find.

 Hypothetically, why not?

 I dug around and found this:
 http://www.itjungle.com/tfh/tfh082007-printer01.html

 From the article.

i5/OS platform when you create applications, which explains the problem customers ran into in 1995 and which IBM wants them to avoid in 2008. A programmer writes an application in say, RPG. They run it through a compiler, either using the Original Program Model (OPM) or the Integrated Language Environment (ILE) compilers, and the code compiles so they can run it. Or, rather, that is what it looks like to=

 the programmer. What is really happening is that this application is
 compiled into an intermediate stage, which some IBMers have called RPG=

 templates (in the case of RPG applications). These templates have a
 property called observability, which in essence means they are
 compiled to the TIMI layer. These intermediate templates are then used=

 by the TIMI layer on an actual piece of hardware with a specific
 processor and instruction set to compile the application to run on
 that specific processor. TIMI compiles these RPG templates down to
 actual compiled code behind the scenes the first time an application
 runs, and because the code was originally compiled to the TIMI layer,
 there is no need to change the source code. Only the object code
 changes, which end users never had access to anyway because only TIMI
 can reach down there. This is the brilliant way that IBM has preserved=

 customers' vast investments in RPG, COBOL, and other applications over=

 the years

Interesting. Hypothesising, wouldn't it be better if compiling to metal = = happened already during installation? On the first run the compiler stil= l = has to hurry (1st impression counts), but downloading over network is so= = slow that while the user is watching the progress bar there'd be plenty = of = time for compiling the intermediate representation and expensive = optimizations without even being noticed by the user. Tomek
Aug 21 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Saturday 21 August 2010 08:03:18 dsimcha wrote:
 == Quote from Jonathan M Davis (jmdavisprog gmail.com)'s article
 
 Hopefully D will prove to be a solution with development benefits
 on par with Java and .NET and efficiency benefits on par with C++.
 - Jonathan M Davis

If "on par" with Java and .NET is all we're aiming for, then we've really set the bar low. I think that D's metaprogramming/generic system will set the bar much higher once D gets more library and tool support. I've thought about how I would implement an API with comparable ease of use and flexibility for some libraries I've written or used in D, using Java, C# or C++. I don't think it's possible. The only other languages where I think a similarly easy to use API would be implementable are the (really slow) dynamic languages like Python and Ruby. For an example, try implementing an API comparable to std.range in flexibility and ease of use in any statically typed, efficient language besides D.

I think that that it's always good to do better. However, the fact remains that generally in a language, you either get power and efficiency, or you get ease of use and speed of development. C++ tends to be powerful and efficient but not particularly easy to use and not all that fast to develop in. Java and C# are nowhere near as powerful as C++, but they avoid a lot of its problems which make them far easier to use and maintain, so development goes faster. D is looking to hit both of those camps. If it manages the efficiency of C++ and the ease and use and maintainability of C# and Java, that's a huge achievement. Howevever, I am by no means saying that we should strive to be "only" as good as C++ for efficiency or "only" as good as C# and Java for ease of use and speed of development. Any gains that we can have over them would be fantastic. In particular, if D were to be considered much better in those areas by enough people, then it would likely really catch on - not to mention, as users of D, we want it to be as good as possible. But still, being able to consistently match C++ at what it's good at and C# and Java at what they're good at in one language is big, and I really don't think that we're there yet. I don't know how efficient we are in comparison to C++, but I expect that there are a number of areas which need improvement (things like inlining, the garbage collector, etc.) if we want the average D program to match the average C++ program for efficiency. And we definitely don't match Java and C# for ease of use and maintainability at this point, but most of that is simply an issue of libraries and tools, both of which are being worked on. So, we're getting there, but I don't think that we're there yet. And certainly, once we do get there, there's no reason to stay only "on par" with them. We should always be looking to improve D and its libraries and tools. - Jonathan M Davis
Aug 21 2010
prev sibling next sibling parent SK <sk metrokings.com> writes:
2010/8/21 Tomek Sowi=C5=84ski <just ask.me>:
 Interesting. Hypothesising, wouldn't it be better if compiling to metal
 happened already during installation?

Nice idea for hand-helds for sure. In a big computing environments, the situation is trickier. For example, a network storage device may contain the intermediate code installation used by many and varied client machines. Each client may load and finish compilation differently over fast local networks. Your idea might still be a meaningful head start to the process even in that case.
Aug 22 2010
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Sat, 21 Aug 2010 18:31:16 -0700, Jonathan M Davis wrote:

 But still, being able to consistently match C++ at what it's good at and
 C# and Java at what they're good at in one language is big, and I really
 don't think that we're there yet. I don't know how efficient we are in
 comparison to C++, but I expect that there are a number of areas which
 need improvement (things like inlining, the garbage collector, etc.) if
 we want the average D program to match the average C++ program for
 efficiency. And we definitely don't match Java and C# for ease of use
 and maintainability at this point, but most of that is simply an issue
 of libraries and tools, both of which are being worked on. So, we're
 getting there, but I don't think that we're there yet. And certainly,
 once we do get there, there's no reason to stay only "on par" with them.
 We should always be looking to improve D and its libraries and tools.

Should D also look more academic than Haskell, F#, Scala, DDC, Clojure, BitC, Factor, and Ur/Web ?
Aug 22 2010
parent "Nick Sabalausky" <a a.a> writes:
"retard" <re tard.com.invalid> wrote in message 
news:i4r1pk$rm8$1 digitalmars.com...
 Sat, 21 Aug 2010 18:31:16 -0700, Jonathan M Davis wrote:

 But still, being able to consistently match C++ at what it's good at and
 C# and Java at what they're good at in one language is big, and I really
 don't think that we're there yet. I don't know how efficient we are in
 comparison to C++, but I expect that there are a number of areas which
 need improvement (things like inlining, the garbage collector, etc.) if
 we want the average D program to match the average C++ program for
 efficiency. And we definitely don't match Java and C# for ease of use
 and maintainability at this point, but most of that is simply an issue
 of libraries and tools, both of which are being worked on. So, we're
 getting there, but I don't think that we're there yet. And certainly,
 once we do get there, there's no reason to stay only "on par" with them.
 We should always be looking to improve D and its libraries and tools.

Should D also look more academic than Haskell, F#, Scala, DDC, Clojure, BitC, Factor, and Ur/Web ?

"More academic"? No, D tries to stick to goals that are actually *good* ones ;) That's kinda like asking if it should try to be more obfuscated than brainfuck, or try to have less enterprise-level library support than Logo.
Aug 22 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Fri, 20 Aug 2010 19:06:32 -0400, bearophile wrote:

 retard:
 quake 2 port - http://bytonic.de/html/jake2_webstart.html

Have you read some of that code? No Java programmer writes code like that. That code is the "exception that confirms the rule" (I don't know how this is normally written in English). The rule is that Java code is slow ;-)

I tested this game on my low-end HTPC (timedemo, map demo2). It's a Core 2 Duo with OC'd Geforce 8600. Got 850 FPS 1920x1080 with default quality settings. Does this make Java slow? I think I've heard that 30..50 fps is acceptable level in video games. It's hard to believe that idiomatic Java would be 15..30 times slower than this. I played through the whole demo. Not a single problem with the GC, the user experience was much better than with the original version 10 years ago.
Aug 22 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Quake 2 is a 13 year old game. :)

On Sun, Aug 22, 2010 at 4:57 PM, retard <re tard.com.invalid> wrote:
 Fri, 20 Aug 2010 19:06:32 -0400, bearophile wrote:

 retard:
 quake 2 port - http://bytonic.de/html/jake2_webstart.html

Have you read some of that code? No Java programmer writes code like that. That code is the "exception that confirms the rule" (I don't know how this is normally written in English). The rule is that Java code is slow ;-)

I tested this game on my low-end HTPC (timedemo, map demo2). It's a Core 2 Duo with OC'd Geforce 8600. Got 850 FPS 1920x1080 with default quality settings. Does this make Java slow? I think I've heard that 30..50 fps is acceptable level in video games. It's hard to believe that idiomatic Java would be 15..30 times slower than this. I played through the whole demo. Not a single problem with the GC, the user experience was much better than with the original version 10 years ago.

Aug 22 2010
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Sun, 22 Aug 2010 17:50:06 +0200, Andrej Mitrovic wrote:

 Quake 2 is a 13 year old game. :)
 

The original argument was that Java code is slow, no matter what you're trying to do. What kind of performance levels are you expecting? If you take a look at the browser games available today (at least Andrei probably knows them since he works at Facebook - http:// mashable.com/2009/10/16/top-facebook-games/ ), you can see that not a single one of them requires more performance than Quake 2. Top 10 indie games from 2008: http://gearcrave.com/2009-01-05/the-year-of-indie-games-2008s-ten-best- independent-games/ Again, no problem. Top 10 indie games from the last year: http://news.bigdownload.com/photos/best-indie-games-of-2009-1/ You can basically write any modern, award winning game in Java; there are absolutely no problems whatsoever. Why are we always bringing up the issues with Eclipse, Netbeans, and Vuze when discussing Java's performance? It almost seems like everyone here is trying to prove that one simply cannot write any desktop application in Java, because it's *that* slow. Even if you had a gazillion GHz CPU, a Pong or Tetris in Java would look sluggish and have 10 minute pauses because of the GC. I did even more googling and found very surprising results: http://dotnot.org/blog/archives/2008/03/10/xml-benchmarks-updated-graphs- with-rapidxml/ It appears that in XML parsing Java is actually 5..10 times faster than D1/Phobos. Maybe D2/Phobos has finally fixed these issues.
Aug 22 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"retard" <re tard.com.invalid> wrote in message 
news:i4rqp4$1egl$2 digitalmars.com...
 Sun, 22 Aug 2010 17:50:06 +0200, Andrej Mitrovic wrote:

 Quake 2 is a 13 year old game. :)

The original argument was that Java code is slow, no matter what you're trying to do. What kind of performance levels are you expecting?

Nobody said that. Java apps just tend to be slower than C/C++/D ones. Strutting out a GPU-bound game that was well-known to run blazingly fast on sub-GHz hardware in *software* rendering mode, and saying "Look it's a few hundred fps on my multi-core" doesn't really do much to disprove that.
 http://dotnot.org/blog/archives/2008/03/10/xml-benchmarks-updated-graphs-
 with-rapidxml/

 It appears that in XML parsing Java is actually 5..10 times faster than
 D1/Phobos. Maybe D2/Phobos has finally fixed these issues.

Phobos's XML is known to be half-baked. That same link indicates that D1/Tango's XML beats the snot out of Java's. Yes, part of that is due to some details of the way Tango goes about it, but it's things that D makes easy and natural. Trying to do the same techniques on Java would be a bit of an uphill battle.
Aug 22 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:i4rv1o$2fqc$1 digitalmars.com...
 "retard" <re tard.com.invalid> wrote in message 
 news:i4rqp4$1egl$2 digitalmars.com...
 Sun, 22 Aug 2010 17:50:06 +0200, Andrej Mitrovic wrote:

 Quake 2 is a 13 year old game. :)

The original argument was that Java code is slow, no matter what you're trying to do. What kind of performance levels are you expecting?

Nobody said that. Java apps just tend to be slower than C/C++/D ones. Strutting out a GPU-bound game that was well-known to run blazingly fast on sub-GHz hardware in *software* rendering mode, and saying "Look it's a few hundred fps on my multi-core" doesn't really do much to disprove that.

Speaking of that, try running the Java one in software rendering mode, and compare to the original C/C++ one with software rendering on the same map and resolution.
Aug 22 2010
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"retard" <re tard.com.invalid> wrote in message 
news:i4s1ft$2fed$1 digitalmars.com...
 Sun, 22 Aug 2010 15:50:10 -0400, Nick Sabalausky wrote:

 "retard" <re tard.com.invalid> wrote in message
 news:i4rqp4$1egl$2 digitalmars.com...
 Sun, 22 Aug 2010 17:50:06 +0200, Andrej Mitrovic wrote:

 Quake 2 is a 13 year old game. :)

trying to do. What kind of performance levels are you expecting?


In my opinion bearophile spread more or less anti-Java FUD.

Well, I tend to feel that the "Java is fast now! Honest!" that a lot of people say is pro-Java propaganda. *shrug*
 Java apps just tend to be slower than C/C++/D ones.
 Strutting out a GPU-bound game that was well-known to run blazingly fast
 on sub-GHz hardware in *software* rendering mode, and saying "Look it's
 a few hundred fps on my multi-core" doesn't really do much to disprove
 that.

(I don't think the Pentium 2/3 desktops managed to run it that quickly. These were the first games that started the GPU race. It was the original Quake that used software rendering.)

Quake 2 had both software and hardware rendering built-in. I played it in software mode a lot before I got my first 3D card. Quake 1 did have hardware mode too, although it was added as a separate "glquake" after Quake 1 was released. Quake 3 Arena was the first Quake to require hardware 3D (and was also the first id game to bore me, but that's unrelated ;) )
 Note that my low-end HTPC has 4.32 times the resolution and 17 times the
 frame rate of the high-end Pentium 2 I used to play the original game
 with). That's a 7300% speedup. According to Moore's law the hardware got
 6400..12800% faster during that period. So definitely Java is not a
 bottleneck in game development in these kinds of games.

In the decade or so since that game was released, AAA games have been using far more polys, far more textures, more rendering passes, more physics and AI processing, etc. And yes, a fair amount of that is GPU-bound but the CPU still needs to drive it, and if you plop a modern video card into, say, a Pentium 2 system, it's not going to run, say, Splinter Cell or Halo very well, and even those are close to ten years old. So the CPU performance *is* still important. (Although personally, I have zero interest in whether or not a game *looks* any better than Splinter Cell or Halo, but unforunately, I seem to be in the minority on that among gamers and game devs.)
 I'm just asking, why software like this should be written in buggy D if
 production ready Java already executes fast enough? You must desire
 absolute hard-core super mega performance to justify the use of D.

Well, for one thing, because D isn't anywhere near the enormous pain-in-the-ass that Java is. And because, like I said above, most games these days (for better or worse) require quite a bit more computational power, even on the CPU, than the Quake 2 engine did. And because id put an enormus amount of pioneering work into *getting* Quake to run that fast in the first place (a fair amount of which the Java port inherited), and devs don't like to have to put that much work into it to get good results.
 Another question is, why would anyone use D/Phobos for writing server
 side XML intensive applications if Java is so much faster?

Java is *not* faster at XML. Phobos just has a half-baked xml lib. Take any of the other xml parsers for D, even ones that haven't gotten as much time and energy put into optimization as the Java one has most likely gotten will probably still run at least comparably to Java, if not better. (And the D1/Tango xml parser makes it very clear that there's a LOT of room for improvement over the Java one).
Aug 23 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sun, 22 Aug 2010 15:50:10 -0400, Nick Sabalausky wrote:

 "retard" <re tard.com.invalid> wrote in message
 news:i4rqp4$1egl$2 digitalmars.com...
 Sun, 22 Aug 2010 17:50:06 +0200, Andrej Mitrovic wrote:

 Quake 2 is a 13 year old game. :)

trying to do. What kind of performance levels are you expecting?


In my opinion bearophile spread more or less anti-Java FUD. "That code is the "exception that confirms the rule" (I don't know how this is normally written in English). The rule is that Java code is slow ;-)" Maybe I am not understanding what he means. To me Eclipse feels bloated and slow, but it doesn't tell anything about Java in general. If I buy a new CPU, the Java programs will run faster than C++ ones now on the current CPU. Why is the small performance difference that significant?
 Java apps just tend to be slower than C/C++/D ones.
 Strutting out a GPU-bound game that was well-known to run blazingly fast
 on sub-GHz hardware in *software* rendering mode, and saying "Look it's
 a few hundred fps on my multi-core" doesn't really do much to disprove
 that.

(I don't think the Pentium 2/3 desktops managed to run it that quickly. These were the first games that started the GPU race. It was the original Quake that used software rendering.) Note that my low-end HTPC has 4.32 times the resolution and 17 times the frame rate of the high-end Pentium 2 I used to play the original game with). That's a 7300% speedup. According to Moore's law the hardware got 6400..12800% faster during that period. So definitely Java is not a bottleneck in game development in these kinds of games. I'm just asking, why software like this should be written in buggy D if production ready Java already executes fast enough? You must desire absolute hard-core super mega performance to justify the use of D. Another question is, why would anyone use D/Phobos for writing server side XML intensive applications if Java is so much faster? Fixing the libraries first tends to be bad for productivity. If I had to choose between a production ready Java XML library and something half-baked for D, my boss would treat me as lunatic if I told him to first wait N months to bring the half-baked amateur library on par with Java and only after that write the code in this language that no other company uses anywhere. I'd need to work on free time to make this a reality.
Aug 22 2010
prev sibling next sibling parent "Yao G." <nospamyao gmail.com> writes:
On Sun, 22 Aug 2010 15:40:32 -0500, Robert Clipsham  
<robert octarineparrot.com> wrote:

 For the record, I'm on a 6 core 3.2Ghz a core box with 8GB ram and  
 eclipse still feels bloated and slow. Same goes for OpenOffice.org :3

Unfortunately, you are not alone on this, bro :( -- Yao G.
Aug 22 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sun, 22 Aug 2010 16:08:41 -0500, Andrei Alexandrescu wrote:

 On 08/22/2010 03:31 PM, retard wrote:
 I'm just asking, why software like this should be written in buggy D if
 production ready Java already executes fast enough? You must desire
 absolute hard-core super mega performance to justify the use of D.

Assuming the question is not tendentious: The decision of choosing a language has quite a few more ingredients than speed of generated code and quality of implementation.

It's really not intentionally tendentious although I often have that kind of tone. We used to have a desperate need for systems programming languages in gamedev mostly because of the efficiency concerns. Some 320x200x8bit VGA game would have had 0.1 FPS on 80486 / Python! Now, given that we're not developing any AAA titles anyway, the major VM languages such as C# and Java are actually good enough. No more dangerous unsafe memory operations (pointer arithmetic, segfaults etc.). Those languages come with mature gamedev frameworks and the performance is orders of magnitude better than one could hope. E.g. XNA 4.0 and Unity3D 3.0 are very competitive despite some backwards compatibility problems. You don't even write much code anymore, it's just few mouse clicks here and there. I feel the network effect is against D here.
Aug 22 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Fri, 01 Oct 2010 14:53:04 +0100, Bruno Medeiros wrote:

 On 20/08/2010 22:37, Nick Sabalausky wrote:
 "retard"<re tard.com.invalid>  wrote in message
 news:i4mrss$cam$1 digitalmars.com...
 Fri, 20 Aug 2010 19:04:41 +0200, Andrej Mitrovic wrote:

 What are these Java programs for the desktop that run fast? I haven't
 encountered any, but maybe that's just because I didn't try them all
 out. Eclipse takes at least 20 seconds to load on startup on my quad
 core, that's not very fast. On the other hand, CodeBlocks which is
 coded in C++ and has  a few dozen plugins installed runs in an
 instant.

Now that's a fair comparison! "Crysis runs so slowly but a hello world written in Go is SO fast. This must prove that Go is much faster than C+ +!" I think CodeBlocks is one of the most lightweight IDEs out there. Does it even have full semantic autocompletion? Eclipse, on the other hand, comes with almost everything you can imagine. If you turn off the syntax check, Eclipse works just as fast as any native application on a modern desktop.

I've tried eclipse with the fancy stuff off, and it's still slower than C::B or PN2 for me.

slow when used, etc., are really meaningless unless you tell us something about what actual plugins and features are installed and used. Unlike CodeBlocks which is "a free C++ IDE", Eclipse proper is the Eclipse Platform, which is a platform (duh) and doesn't do anything useful by itself. Particularly since there is not even a standard/single "Eclipse" download: http://www.eclipse.org/downloads/ , unlike Codeblocks. The days were JDT would be the main thing 95% of Eclipse users would use are long gone. So are you using JDT, CDT, Descent, something else? If JDT, do you have extra tools, like the J2EE Web Tools? (these add massive bloat) What about source control plugins, or plugins not provided by the Eclipse Foundation, etc? All of these are a wildcard that can affect performance. For example, I definitely note that sometimes my workspace chokes when I do certain SVN or file related operations (with Subclipse btw, not Subversive). I also noted, when Eclipse 3.6 came out, some sluggishness when working with JDT, even when just typing code (in this case it was very subtle, almost imperceptible, but I still felt it and it was quite annoying). I suspected not JDT, but Mylyn, so I uninstalled it, and now things are back to normal. (there might be a fix or workaround for that issue in Mylyn, but since I don't use it, I didn't bother) I would definitely be quite annoying if Eclipse was not responsive for the vast majority of coding tasks. As for startup time, I hardly care anything about that : http://www.digitalmars.com/d/archives/digitalmars/D/

 (except when I'm doing PDE development, but that's a different thing)

Back then the unhappy user was using a 1 GHz Pentium M notebook. I tried this again. Guess what, the latest Eclipse Helios (3.6.1) took 3.5 (!!!) seconds to start up the whole Java workspace, open few projects and fully initialize the editors etc for the most active project. Has the original complainer ever used Photoshop, CorelDraw, AutoCad, Maya/3DSMax, Maple/ MathCad/Mathematica, or some other Real World Programs (tm)? These are all fucking slow. That's how it is: If you need to get the job done, you must use slow programs. My hardware specs: Core i7, 24 GB of DDR3 RAM, Sun Java 7, x86-64 Linux 2.6 (a middle range home PC with some extra memory, that is)
Oct 02 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sat, 02 Oct 2010 18:21:53 +0200, Don wrote:

 retard wrote:
 Back then the unhappy user was using a 1 GHz Pentium M notebook. I
 tried this again. Guess what, the latest Eclipse Helios (3.6.1) took
 3.5 (!!!) seconds to start up the whole Java workspace, open few
 projects and fully initialize the editors etc for the most active
 project.

That's good news. Sounds as though they've fixed the startup performance bug.

I meant that computers become more efficient. I've upgraded my system two times since this discussion last appeared here. If you wait 18 months, the 20 seconds becomes 10 seconds, in 36 months 5 seconds. It's the Moore's law, you know.
 
 Has the original
 complainer ever used Photoshop, CorelDraw, AutoCad, Maya/3DSMax, Maple/
 MathCad/Mathematica, or some other Real World Programs (tm)? These are
 all fucking slow. That's how it is: If you need to get the job done,
 you must use slow programs.

That original poster was me. Yes, I've used all of those programs (though not a recent version of CorelDraw). The startup time was 80 seconds, on the most most minimal standard Eclipse setup I could find. MSVC was 3 seconds on the same system. I had expected the times to be roughly comparable.

How long does it take to start up all those programs on your notebook? 15 minutes? I don't even consider Eclipse bloated compared to *these* applications.
 
 There was just something sloppy in Eclipse's startup code.

I don't recommend running Eclipse on any machine with less than 1 GB of RAM. It's a well known fact that Java programs require twice as much memory due to garbage collection. Also Eclipse is a rather complex framework. Luckily *all* systems, even the cheapest $100 netbooks have 1 GB of RAM!
Oct 02 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Sat, 02 Oct 2010 21:21:23 +0200, Don wrote:

 retard wrote:
 Sat, 02 Oct 2010 18:21:53 +0200, Don wrote:
 There was just something sloppy in Eclipse's startup code.

I don't recommend running Eclipse on any machine with less than 1 GB of RAM. It's a well known fact that Java programs require twice as much memory due to garbage collection. Also Eclipse is a rather complex framework. Luckily *all* systems, even the cheapest $100 netbooks have 1 GB of RAM!

My laptop had 1GB, so I'm not sure we can blame that. Eclipse was perfectly fine once it had loaded. It was only the startup which was slow.

Another thing that comes to mind is that the file system might have been badly fragmented and/or Eclipse loaded a boatload of dependencies at startup from a slow 2.5" disk. Many laptops have slow 5400 rpm disks with really bad I/O performance. For example my old IBM T23 or something like that managed to read files 8 MB/s from the C: drive. That's just terrible compared to modern SATA2 hard drives with 64 MB of cache (SSDs are even better -- a 64 GB 2.5" SSD drive costs about as much as a 3.5" SATA2 1.5 TB spinning disk). I can easily read data 90 MB/s, even when the file system is quite full. If you need to read 120 MB of data (size of the latest eclipse), there is simply no way to read it faster than in 15 seconds using the old disk.
Oct 02 2010
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 2010-10-02 at 21:21 +0200, Don wrote:
 retard wrote:

 I meant that computers become more efficient. I've upgraded my system t=


 times since this discussion last appeared here. If you wait 18 months, =


 20 seconds becomes 10 seconds, in 36 months 5 seconds. It's the Moore's=


 law, you know.

Sadly, software seems to be bloating at a rate which is faster than=20 Moore's law. Part of my original post noted that it was much slower than=20 my old 1MHz Commodore 64 took to boot my development environment from a=20 cassette tape! So I still take it as a good sign that the rate of=20 bloating is slower than Moore's law.

Faster processor speeds in the period 1950--2005 was not actually anything to do with Moore's Law per se -- Moore's Law was about the number of transistors per chip, not the speed of operation of those transistors. Since around 2005 processor speeds have stopped increasing due to inability to deal with the heat generation. Instead Moore's Law (which for the moment still applies) is leading to more and more cores per chip all running at the same speed as previously -- around 2GHz. So the ability to improve performance of code by just waiting and buying new kit is over -- at least for now. If you do not turn your serial code into parallel code there will be no mechanism for improving performance of that code. A bit sad for inherently serial algorithms. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Oct 03 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Tue, 05 Oct 2010 15:49:59 +0100, Bruno Medeiros wrote:

 On 02/10/2010 15:13, retard wrote:
 Fri, 01 Oct 2010 14:53:04 +0100, Bruno Medeiros wrote:

 On 20/08/2010 22:37, Nick Sabalausky wrote:
 "retard"<re tard.com.invalid>   wrote in message
 news:i4mrss$cam$1 digitalmars.com...
 Fri, 20 Aug 2010 19:04:41 +0200, Andrej Mitrovic wrote:

 What are these Java programs for the desktop that run fast? I
 haven't encountered any, but maybe that's just because I didn't try
 them all out. Eclipse takes at least 20 seconds to load on startup
 on my quad core, that's not very fast. On the other hand,
 CodeBlocks which is coded in C++ and has  a few dozen plugins
 installed runs in an instant.

Now that's a fair comparison! "Crysis runs so slowly but a hello world written in Go is SO fast. This must prove that Go is much faster than C+ +!" I think CodeBlocks is one of the most lightweight IDEs out there. Does it even have full semantic autocompletion? Eclipse, on the other hand, comes with almost everything you can imagine. If you turn off the syntax check, Eclipse works just as fast as any native application on a modern desktop.

I've tried eclipse with the fancy stuff off, and it's still slower than C::B or PN2 for me.

is slow when used, etc., are really meaningless unless you tell us something about what actual plugins and features are installed and used. Unlike CodeBlocks which is "a free C++ IDE", Eclipse proper is the Eclipse Platform, which is a platform (duh) and doesn't do anything useful by itself. Particularly since there is not even a standard/single "Eclipse" download: http://www.eclipse.org/downloads/ , unlike Codeblocks. The days were JDT would be the main thing 95% of Eclipse users would use are long gone. So are you using JDT, CDT, Descent, something else? If JDT, do you have extra tools, like the J2EE Web Tools? (these add massive bloat) What about source control plugins, or plugins not provided by the Eclipse Foundation, etc? All of these are a wildcard that can affect performance. For example, I definitely note that sometimes my workspace chokes when I do certain SVN or file related operations (with Subclipse btw, not Subversive). I also noted, when Eclipse 3.6 came out, some sluggishness when working with JDT, even when just typing code (in this case it was very subtle, almost imperceptible, but I still felt it and it was quite annoying). I suspected not JDT, but Mylyn, so I uninstalled it, and now things are back to normal. (there might be a fix or workaround for that issue in Mylyn, but since I don't use it, I didn't bother) I would definitely be quite annoying if Eclipse was not responsive for the vast majority of coding tasks. As for startup time, I hardly care anything about that : http://www.digitalmars.com/d/archives/digitalmars/D/



 (except when I'm doing PDE development, but that's a different thing)

Back then the unhappy user was using a 1 GHz Pentium M notebook. I tried this again. Guess what, the latest Eclipse Helios (3.6.1) took 3.5 (!!!) seconds to start up the whole Java workspace, open few projects and fully initialize the editors etc for the most active project. Has the original complainer ever used Photoshop, CorelDraw, AutoCad, Maya/3DSMax, Maple/ MathCad/Mathematica, or some other Real World Programs (tm)? These are all fucking slow. That's how it is: If you need to get the job done, you must use slow programs.

loads too slow use some other program for media development. Maybe its MS Paint (or a Linux equivalent) because it loads so fast! Or maybe its a vi/emacs plugin for image manipulation or 3D modelling. ;)

Well Don mentioned that he had used ALL of those programs and since no complaints about the slow loading times of those programs were mentioned, I assume all of them (the latest versions, of course) start in less than 3.5 seconds. I pondered this a bit and am now willing to buy Don's magic computer. I really do have need for a laptop that can launch those applications in less than 3.5 seconds.
Oct 05 2010
prev sibling next sibling parent Juanjo Alvarez <fake fakeemail.com> writes:
On Tue, 5 Oct 2010 17:59:26 +0000 (UTC), retard <re tard.com.invalid> 
wrote:
 I assume all of them (the latest versions, of course) start in less 

 3.5 seconds. I pondered this a bit and am now willing to buy Don's 

 computer. I really do have need for a laptop that can launch those 
 applications in less than 3.5 seconds.

Yes, my 2.40ghz i5 with 6gbs RAM takes about ten seconds to open Eclipse 64bits; I need to get one of those SSDs.
Oct 05 2010
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 20/08/2010 17:38, bearophile wrote:
 Three good blog posts about undefined behaviour in C and C++:
 http://blog.regehr.org/archives/213
 http://blog.regehr.org/archives/226
 http://blog.regehr.org/archives/232

 In those posts (and elsewhere) the expert author gives several good bites to
the ass of most compiler writers.

 Among other things in those three posts he talks about two programs as:

 import std.c.stdio: printf;
 void main() {
      printf("%d\n", -int.min);
 }

 import std.stdio: writeln;
 void main() {
      enum int N = (1L).sizeof * 8;
      auto max = (1L<<  (N - 1)) - 1;
      writeln(max);
 }

 I believe that D can't be considered a step forward in system language
programming until it gives a much more serious consideration for
integer-related overflows (and integer-related undefined behaviour).

 The good thing is that Java is a living example that even if you remove most
integer-related undefined behaviours your Java code is still able to run as
fast as C and sometimes faster (on normal desktops).

 Bye,
 bearophile

Interesting post. There is a important related issue here. It should be noted that, even though the article and the C FAQ say: " The C FAQ defines “undefined behavior” like this: Anything at all can happen; the Standard imposes no requirements. The program may fail to compile, or it may execute incorrectly (either crashing or silently generating incorrect results), or it may fortuitously do exactly what the programmer intended. " this definition of "undefined behavior" is not used consistently by C programmers, or even by more official sources such as books, or even the C standards. A trivial example: foo(printf("Hello"), printf("World")); Since the evaluation order of arguments in not defined in C, these two printfs can be executed in any of the two possible orders. The behavior is not specified, it is up to the implementation, to the compiler switches, etc.. Many C programmers would say that such code has/is/produces undefined behavior, however, that is clearly not “undefined behavior” as per the definition above. A correct compiler cannot cause the code above to execute incorrectly, crash, calculate PI, format you hard disk, whatever, like on the other cases. It has to do everything it is supposed to do, and the only "undefined" thing is the order of evaluation, but the code is not "invalid". I don't like this term "undefined behavior". It is an unfortunate C legacy that leads to unnecessary confusion and misunderstanding, not just in conversation, but often in coding as well. It would not be so bad if the programmers had the distinction clear at least in their minds, or in the context of their discussion. But that is often not the case. I've called before for this term to be avoided in D vocabulary, mainly because Walter often (ab)used the term as per the usual C legacy. The “undefined behavior” as per the C FAQ should be called something else, like "invalid behavior". Code that when given valid inputs causes invalid behavior should be called invalid code. (BTW, this maps directly to the concept of contract violations.) -- Bruno Medeiros - Software Engineer
Oct 06 2010
parent reply Stanislav Blinov <blinov loniir.ru> writes:
  06.10.2010 19:34, Bruno Medeiros ŠæŠøшŠµŃ‚:
 On 20/08/2010 17:38, bearophile wrote:
 Three good blog posts about undefined behaviour in C and C++:
 http://blog.regehr.org/archives/213
 http://blog.regehr.org/archives/226
 http://blog.regehr.org/archives/232

 In those posts (and elsewhere) the expert author gives several good 
 bites to the ass of most compiler writers.

 Among other things in those three posts he talks about two programs as:

 import std.c.stdio: printf;
 void main() {
 printf("%d\n", -int.min);
 }

 import std.stdio: writeln;
 void main() {
 enum int N = (1L).sizeof * 8;
 auto max = (1L<< (N - 1)) - 1;
 writeln(max);
 }

 I believe that D can't be considered a step forward in system 
 language programming until it gives a much more serious consideration 
 for integer-related overflows (and integer-related undefined behaviour).

 The good thing is that Java is a living example that even if you 
 remove most integer-related undefined behaviours your Java code is 
 still able to run as fast as C and sometimes faster (on normal 
 desktops).

 Bye,
 bearophile

Interesting post. There is a important related issue here. It should be noted that, even though the article and the C FAQ say: " The C FAQ defines ā€œundefined behaviorā€ like this: Anything at all can happen; the Standard imposes no requirements. The program may fail to compile, or it may execute incorrectly (either crashing or silently generating incorrect results), or it may fortuitously do exactly what the programmer intended. " this definition of "undefined behavior" is not used consistently by C programmers, or even by more official sources such as books, or even the C standards. A trivial example: foo(printf("Hello"), printf("World")); Since the evaluation order of arguments in not defined in C, these two printfs can be executed in any of the two possible orders. The behavior is not specified, it is up to the implementation, to the compiler switches, etc.. Many C programmers would say that such code has/is/produces undefined behavior, however, that is clearly not ā€œundefined behaviorā€ as per the definition above. A correct compiler cannot cause the code above to execute incorrectly, crash, calculate PI, format you hard disk, whatever, like on the other cases. It has to do everything it is supposed to do, and the only "undefined" thing is the order of evaluation, but the code is not "invalid". I don't like this term "undefined behavior". It is an unfortunate C legacy that leads to unnecessary confusion and misunderstanding, not just in conversation, but often in coding as well. It would not be so bad if the programmers had the distinction clear at least in their minds, or in the context of their discussion. But that is often not the case. I've called before for this term to be avoided in D vocabulary, mainly because Walter often (ab)used the term as per the usual C legacy. The ā€œundefined behaviorā€ as per the C FAQ should be called something else, like "invalid behavior". Code that when given valid inputs causes invalid behavior should be called invalid code. (BTW, this maps directly to the concept of contract violations.)

i.e. the paper that *defines* behavior of the language and states that there are cases when behavior is not defined (i.e. in terms of the specification). From this point of view the term is understandable and, uh, valid. It's just that it got abused with time, especially this abuse is notable in discussions (e.g. "Don't do that, undefined behavior will result": one can sit and guess how exactly she will get something that is not defined). I don't think that "invalid behavior" covers that sense: it means that implementation should actually do something to make code perform 'invalid' things (what should be considered invalid, by the way?), rather than have the possibility to best adapt the behavior to system (e.g. segfault) or some error handling mechanism (e.g. throw an exception).
Oct 06 2010
next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 06/10/2010 16:59, Stanislav Blinov wrote:
 06.10.2010 19:34, Bruno Medeiros ŠæŠøшŠµŃ‚:
 On 20/08/2010 17:38, bearophile wrote:
 Three good blog posts about undefined behaviour in C and C++:
 http://blog.regehr.org/archives/213
 http://blog.regehr.org/archives/226
 http://blog.regehr.org/archives/232

 In those posts (and elsewhere) the expert author gives several good
 bites to the ass of most compiler writers.

 Among other things in those three posts he talks about two programs as:

 import std.c.stdio: printf;
 void main() {
 printf("%d\n", -int.min);
 }

 import std.stdio: writeln;
 void main() {
 enum int N = (1L).sizeof * 8;
 auto max = (1L<< (N - 1)) - 1;
 writeln(max);
 }

 I believe that D can't be considered a step forward in system
 language programming until it gives a much more serious consideration
 for integer-related overflows (and integer-related undefined behaviour).

 The good thing is that Java is a living example that even if you
 remove most integer-related undefined behaviours your Java code is
 still able to run as fast as C and sometimes faster (on normal
 desktops).

 Bye,
 bearophile

Interesting post. There is a important related issue here. It should be noted that, even though the article and the C FAQ say: " The C FAQ defines ā€œundefined behaviorā€ like this: Anything at all can happen; the Standard imposes no requirements. The program may fail to compile, or it may execute incorrectly (either crashing or silently generating incorrect results), or it may fortuitously do exactly what the programmer intended. " this definition of "undefined behavior" is not used consistently by C programmers, or even by more official sources such as books, or even the C standards. A trivial example: foo(printf("Hello"), printf("World")); Since the evaluation order of arguments in not defined in C, these two printfs can be executed in any of the two possible orders. The behavior is not specified, it is up to the implementation, to the compiler switches, etc.. Many C programmers would say that such code has/is/produces undefined behavior, however, that is clearly not ā€œundefined behaviorā€ as per the definition above. A correct compiler cannot cause the code above to execute incorrectly, crash, calculate PI, format you hard disk, whatever, like on the other cases. It has to do everything it is supposed to do, and the only "undefined" thing is the order of evaluation, but the code is not "invalid". I don't like this term "undefined behavior". It is an unfortunate C legacy that leads to unnecessary confusion and misunderstanding, not just in conversation, but often in coding as well. It would not be so bad if the programmers had the distinction clear at least in their minds, or in the context of their discussion. But that is often not the case. I've called before for this term to be avoided in D vocabulary, mainly because Walter often (ab)used the term as per the usual C legacy. The ā€œundefined behaviorā€ as per the C FAQ should be called something else, like "invalid behavior". Code that when given valid inputs causes invalid behavior should be called invalid code. (BTW, this maps directly to the concept of contract violations.)

i.e. the paper that *defines* behavior of the language and states that there are cases when behavior is not defined (i.e. in terms of the specification). From this point of view the term is understandable and, uh, valid. It's just that it got abused with time, especially this abuse is notable in discussions (e.g. "Don't do that, undefined behavior will result": one can sit and guess how exactly she will get something that is not defined).

"the term itself came from language specification" -> yes that is correct. I read K&R's "The C Programming Language", second edition, and the term comes from there, at least as applied to C. But they don't define or use the term as the C FAQ above, or at least not as explicitly, if I recall correctly (im 98% sure I am). They just describe each particular language rule individually and tell you what to expect if you break the rule. Often they will say something like "this will cause undefined behavior" and it is clear that is is illegal. But other times they would say something like "X is undefined", where X could be "the order of execution", "the results of Y", "the contents of variable Z", and it is not clear whether that meant the program could exhibit undefined behavior or not. (or in other words if that was illegal or not) I don't know if this concept or related ones have actually been better formalized in newer revisions of the C standard.
 I don't think that "invalid behavior" covers that sense: it means that
 implementation should actually do something to make code perform
 'invalid' things (what should be considered invalid, by the way?),
 rather than have the possibility to best adapt the behavior to system
 (e.g. segfault) or some error handling mechanism (e.g. throw an exception).

In this case I don't know for sure what the best alternative term is, I just want to avoid confusion with "invalid behavior". I want to know when a program execution may actually be invalidated (crash, memory corruption, etc.), versus when it is just some particular and *isolated* aspect of behavior that is simply "undefined", but program execution is not invalidated. In other words, if it is illegal or not. -- Bruno Medeiros - Software Engineer
Oct 07 2010
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 07/10/2010 12:47, Stanislav Blinov wrote:
 07.10.2010 14:38, Bruno Medeiros wrote:
 On 06/10/2010 16:59, Stanislav Blinov wrote:
 I always thought that the term itself came from language specification,
 i.e. the paper that *defines* behavior of the language and states that
 there are cases when behavior is not defined (i.e. in terms of the
 specification). From this point of view the term is understandable and,
 uh, valid. It's just that it got abused with time, especially this abuse
 is notable in discussions (e.g. "Don't do that, undefined behavior will
 result": one can sit and guess how exactly she will get something that
 is not defined).

"the term itself came from language specification" -> yes that is correct. I read K&R's "The C Programming Language", second edition, and the term comes from there, at least as applied to C. But they don't define or use the term as the C FAQ above, or at least not as explicitly, if I recall correctly (im 98% sure I am).

speaker), but the need to actually define this term seems dubious to me, kind of another abuse if you please. The term means just exactly what it says: the behavior [of the code/program/compiler/system/you_name_it] is not defined, i.e. no restrictions or rules are attached to it. To me, attempts to define undefined seem like attempts on 'adding one briefcase into another' (from Win98 days).

In the context of natural language, the term means exactly what it means, yes. But in the context of a particular programming language, we often give more precise meanings to certain natural language terms, because it is very useful and important. For example "object", "contract", "exception", "thread", "valid/invalid code", and many others. Without these terms it would be very complicated to communicate. "undefined behavior" was not given a precise meaning in K&R TCPL, but it is given a much more precise and stricter meaning in the C FAQ and the original article. These meanings look similar but they are slightly and critically different. And this ambiguity percolates through the C community.
 They just describe each particular language rule individually and tell
 you what to expect if you break the rule. Often they will say
 something like "this will cause undefined behavior" and it is clear
 that is is illegal.

), being a systems language, it cannot demand strict ways of handling every situation from an implementation. Some systems may choke on integer overflow, some may not. Some build made with single compiler may get you useful data when addressing seemingly out-of-bounds data, yet some builds (made with the same compiler) would grant you access violation. (i.e. debug/release builds of MSVC). Stating that behavior in some case is not defined, the spec leaves implementation with a possibility to best handle that case (or, of course, not handle it at all), or at least adapt it to some use (e.g. for debugging), which is great for systems language, because many such 'undefined' cases can be handled very differently (in terms of results/efficiency/whatnot) on different systems. Of course, it does not imply that writing code that behaves in an 'undefined' manner is a good thing to do, but being strict with what a compiler should do in all cases is neither. Of course, replacing 'undefined behavior' with 'implementation-specific behavior' would look better, but that again puts forward a demand (restriction) rather than possibility.

No, it is illegal behavior according to what I meant by "illegal behavior". :) You thought otherwise because you likely had a slightly different idea of what I meant by "illegal". And this is precisely my point, if you don't precisely define the terms, communication is harder and misunderstandings happen.
 But other times they would say something like "X is undefined", where
 X could be "the order of execution", "the results of Y", "the contents
 of variable Z", and it is not clear whether that meant the program
 could exhibit undefined behavior or not. (or in other words if that
 was illegal or not)

rather to natural one.

Yes, there is sometimes ambiguity in the natural language. That's why we have to be thoughful in how we define our terms in the context of programming languages. We want to reduce natural language ambiguities to a minimum. -- Bruno Medeiros - Software Engineer
Oct 08 2010
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
I'm gonna summarize this up in two points:

A) We should define certain terms within the D language in a precise 
way, to help us communicate with each other more clearly, both in 
discussion as well as in documents and specifications.

B) We should strive that the way we define such terms be the best we can 
make it, in order to avoid ambiguity and confusion with other terms, and 
with natural language itself.
(just as there is good code and bad code, there could also be good and 
bad term definitions)


I googled a bit more, and actually found that D (even as far as D1) does 
indeed formally define "Undefined behavior", in an equivalent way as the 
C FAQ:

http://www.digitalmars.com/d/1.0/glossary.html
""
UB (Undefined Behavior)
     Undefined behavior happens when an illegal code construct is 
executed. Undefined behavior can include random, erratic results, 
crashes, faulting, etc.
""

And from TDPL, section 12.2.1:
""
Undefined behavior: The effect of executing a program fragment in a 
given state is not defined. This means that anything within the realm of 
physical possibility could happen.
""

This is good, it means we get (A). I don't think we have (B) though, I 
think the name of the term could be better, as I discussed in the 
previous posts.
Now that I know we have (A), I actually don't want to spent more time 
arguing (B) either, but I am gonna "police" the forums because I'm sure 
this terms has been used, and will be used again not according to the 
definition.

-- 
Bruno Medeiros - Software Engineer
Oct 08 2010
prev sibling parent BCS <none anon.com> writes:
Hello Stanislav,

 I don't think that "invalid behavior" covers that sense: it means that
 implementation should actually do something to make code perform
 'invalid' things (what should be considered invalid, by the way?),
 rather than have the possibility to best adapt the behavior to system
 (e.g. segfault) or some error handling mechanism (e.g. throw an
 exception).
 

Some where in the spec, D defines depending on order of evaluation to be invalid (placing any related bugs in your code, not the compiler, by fiat) but declines to requiter the compiler to enforce it (because it can't in many cases). Maybe some term for "invalid but un checked" should be used. -- ... <IXOYE><
Oct 07 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Wed, 06 Oct 2010 14:26:18 +0100, Bruno Medeiros wrote:

 Note: I wasn't talking about Don. Even though he mentioned those startup
 issues, I don't think Don is a person who "downright refuse[s] to use
 Eclipse because it loads too slow".
 One thing is complaining, the other thing is actually deciding not to
 use, and yes, there are some people in the later camp, people who don't
 want to use an IDE if it doesn't load in less than X seconds (where X is
 between 1-5 seconds).

Roger that. I only wanted to point out that Eclipse isn't the only "professional" tool that takes "forever" to launch. For instance all three major Java IDEs (IDEA, Netbeans, Eclipse JDT) have very similar loading times. Those audio/video/cad/math tools also feel very bloated, but I'm sure there are good reasons for that. They're just packed with a huge set of features these days.
Oct 06 2010
prev sibling next sibling parent Stanislav Blinov <blinov loniir.ru> writes:
  07.10.2010 14:38, Bruno Medeiros wrote:
 On 06/10/2010 16:59, Stanislav Blinov wrote:
 I always thought that the term itself came from language specification,
 i.e. the paper that *defines* behavior of the language and states that
 there are cases when behavior is not defined (i.e. in terms of the
 specification). From this point of view the term is understandable and,
 uh, valid. It's just that it got abused with time, especially this abuse
 is notable in discussions (e.g. "Don't do that, undefined behavior will
 result": one can sit and guess how exactly she will get something that
 is not defined).

"the term itself came from language specification" -> yes that is correct. I read K&R's "The C Programming Language", second edition, and the term comes from there, at least as applied to C. But they don't define or use the term as the C FAQ above, or at least not as explicitly, if I recall correctly (im 98% sure I am).

speaker), but the need to actually define this term seems dubious to me, kind of another abuse if you please. The term means just exactly what it says: the behavior [of the code/program/compiler/system/you_name_it] is not defined, i.e. no restrictions or rules are attached to it. To me, attempts to define undefined seem like attempts on 'adding one briefcase into another' (from Win98 days).
 They just describe each particular language rule individually and tell 
 you what to expect if you break the rule. Often they will say 
 something like "this will cause undefined behavior" and it is clear 
 that is is illegal. 

), being a systems language, it cannot demand strict ways of handling every situation from an implementation. Some systems may choke on integer overflow, some may not. Some build made with single compiler may get you useful data when addressing seemingly out-of-bounds data, yet some builds (made with the same compiler) would grant you access violation. (i.e. debug/release builds of MSVC). Stating that behavior in some case is not defined, the spec leaves implementation with a possibility to best handle that case (or, of course, not handle it at all), or at least adapt it to some use (e.g. for debugging), which is great for systems language, because many such 'undefined' cases can be handled very differently (in terms of results/efficiency/whatnot) on different systems. Of course, it does not imply that writing code that behaves in an 'undefined' manner is a good thing to do, but being strict with what a compiler should do in all cases is neither. Of course, replacing 'undefined behavior' with 'implementation-specific behavior' would look better, but that again puts forward a demand (restriction) rather than possibility.
 But other times they would say something like "X is undefined", where 
 X could be "the order of execution", "the results of Y", "the contents 
 of variable Z", and it is not clear whether that meant the program 
 could exhibit undefined behavior or not. (or in other words if that 
 was illegal or not)

rather to natural one.
 I don't know if this concept or related ones have actually been better 
 formalized in newer revisions of the C standard.

 I don't think that "invalid behavior" covers that sense: it means that
 implementation should actually do something to make code perform
 'invalid' things (what should be considered invalid, by the way?),
 rather than have the possibility to best adapt the behavior to system
 (e.g. segfault) or some error handling mechanism (e.g. throw an 
 exception).

In this case I don't know for sure what the best alternative term is, I just want to avoid confusion with "invalid behavior". I want to know when a program execution may actually be invalidated (crash, memory corruption, etc.), versus when it is just some particular and *isolated* aspect of behavior that is simply "undefined", but program execution is not invalidated. In other words, if it is illegal or not.

Oct 07 2010
prev sibling next sibling parent so <so so.do> writes:
On Mon, 23 Aug 2010 00:31:49 +0300, retard <re tard.com.invalid> wrote:

 Sun, 22 Aug 2010 16:08:41 -0500, Andrei Alexandrescu wrote:

 On 08/22/2010 03:31 PM, retard wrote:
 I'm just asking, why software like this should be written in buggy D if
 production ready Java already executes fast enough? You must desire
 absolute hard-core super mega performance to justify the use of D.

Assuming the question is not tendentious: The decision of choosing a language has quite a few more ingredients than speed of generated code and quality of implementation.

It's really not intentionally tendentious although I often have that kind of tone. We used to have a desperate need for systems programming languages in gamedev mostly because of the efficiency concerns. Some 320x200x8bit VGA game would have had 0.1 FPS on 80486 / Python! Now, given that we're not developing any AAA titles anyway, the major VM languages such as C# and Java are actually good enough. No more dangerous unsafe memory operations (pointer arithmetic, segfaults etc.). Those languages come with mature gamedev frameworks and the performance is orders of magnitude better than one could hope. E.g. XNA 4.0 and Unity3D 3.0 are very competitive despite some backwards compatibility problems. You don't even write much code anymore, it's just few mouse clicks here and there. I feel the network effect is against D here.

Both of these engines are for artists or small games, no serious game engine built on nothing but C++, though not saying it is great, it is just best tool for the job. I am sure most of the people that actually into D is high performance application coders, others really don't have many reasons for a migration. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Oct 07 2010
prev sibling next sibling parent so <so so.do> writes:
 It appears that in XML parsing Java is actually 5..10 times faster than
 D1/Phobos. Maybe D2/Phobos has finally fixed these issues.

RapidXML is a 2.5k loc header file, using templates. Equal D code possibly using ranges and slicing wouldn't be more than 1k loc, and it would still be possible to outperform it since C++ don't have any of these and much more. I would love to see a comparison of C++ and D implementation of this lib/header. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Oct 07 2010
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 08 Oct 2010 07:17:42 +0400, so <so so.do> wrote:

 It appears that in XML parsing Java is actually 5..10 times faster than
 D1/Phobos. Maybe D2/Phobos has finally fixed these issues.

RapidXML is a 2.5k loc header file, using templates. Equal D code possibly using ranges and slicing wouldn't be more than 1k loc, and it would still be possible to outperform it since C++ don't have any of these and much more. I would love to see a comparison of C++ and D implementation of this lib/header.

Tango (D1) XML module performance comparison: http://dotnot.org/blog/archives/2008/02/
Oct 07 2010
prev sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Fri, 08 Oct 2010 06:55:12 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Russel Winder wrote:
 So the ability to improve performance of code by just waiting and buying
 new kit is over -- at least for now.  If you do not turn your serial
 code into parallel code there will be no mechanism for improving
 performance of that code.  A bit sad for inherently serial algorithms.

I'm not sad at all. I enjoy optimizing code for performance, and working on optimizers.

This just in: Compiler writer actually inherently serial algorithm! -- Simen
Oct 08 2010