In article <cf0l3e$q9p$1@digitaldaemon.com>, Dave says...
>In article <ceoc3l$1apl$1@digitaldaemon.com>, Sean Kelly says...
>>int i;
>>
>>void func( inout int ri )
>>{
>>for( int j = 0; j < 10; j++ ) {
>>ri++;
>>i++;
>>}
>>}
>>
>>int main()
>>{
>>i = 10;
>>func(i);
>>printf("%d\n",i);
>>return 0;
>>}
<snip>
>Others - how much current code would that break?? Would it have a big effect on the DTL implementation for example?

I can't say if it would break anything, but I do like what you're proposing. A coding style like the one above is IMO a very bad one.

I was a bit surprised that the above worked as it did, I though func() would make a local copy and "return" it when done with it. Not doing so could create some unexpected effects, for example:

# import std.stdio;
#
# void foo(inout int a, inout int b)
# {
#   writefln(a);
#   b++;
#   writefln(a); // One might expect a to be unchanged at this point
# }
#
# void main()
# {
#   int i = 10;
#   foo(i,i);
# }

This outputs 10 and 11. I think you should be guaranteed that local variables are not altered by "external" influences during the course of executing a function. And if you really want the above behavior, use pointers.

Nick

In article <cf0ocn$sg3$1@digitaldaemon.com>, Nick says...
>
>In article <cf0l3e$q9p$1@digitaldaemon.com>, Dave says...
>>In article <ceoc3l$1apl$1@digitaldaemon.com>, Sean Kelly says...
>
>I can't say if it would break anything, but I do like what you're proposing. A coding style like the one above is IMO a very bad one.
>

I agree - and the C code I've been working with recently has quite a few LOC like that, and I hope future D code will not ;)

The biggest thing for me though are the compiler optimization oppotunities that disappear for many functions that have an argument list like that (if C style aliasing is allowed that is).

I think what Walter said here http://www.digitalmars.com/drn-bin/wwwnews?D/28904 would do D alot of good.

Thanks.

PS: I'm new to D and these newgroups, and I gotta say am very impressed with both. Here's to a grand weekend for everybody..3..2..1..it is now Miller Time for this cat!

In article <cf0ocn$sg3$1@digitaldaemon.com>, Nick says...
>
>I was a bit surprised that the above worked as it did, I though func() would make a local copy and "return" it when done with it. Not doing so could create some unexpected effects, for example:
>
># import std.stdio;
>#
># void foo(inout int a, inout int b)
># {
>#   writefln(a);
>#   b++;
>#   writefln(a); // One might expect a to be unchanged at this point
># }
>#
># void main()
># {
>#   int i = 10;
>#   foo(i,i);
># }
>
>This outputs 10 and 11. I think you should be guaranteed that local variables are not altered by "external" influences during the course of executing a function. And if you really want the above behavior, use pointers.

I don't know.  I would consider it a very bad idea to pass the same variable as multiple parameters of a function with side effects.  This is a case where I don't think it's necessary for the compiler to protect the programmer from himself.  Besides, I may not always want to pay for the extra instructions and such that this would require.


Sean

In article <schancel-8833C7.08301601082004@digitalmars.com>, Sha Chancellor says...
>
>In article <ceis7r$23bt$1@digitaldaemon.com>,
> Dave <Dave_member@pathlink.com> wrote:
>
>> I'm very new to D (literally as of yesterday), but am very impressed with what I'm seeing so far.
>> 
>> Being that I want this language to succeed and an important part of that will be performance potential over C, I'm curious - how does/will D deal with the pointer 'aliasing problem' that plagues C and C++ compiler developers?
<snip>
>
>What aliasing problem would you be referring too?  ( No D does not deal with it with denial, it's an honest question :)

--- Thump, thump - up on the soapbox ---

I hate to say it, but it's appearing more and more like it is being dealt with by denial ;)

I've asked the question a couple of times in a couple of different ways and it seems that none of the 'principles' of D design and implementation can or will give me an answer on future direction [or even future plans] for this issue.

And all the while more code (that a change may break) is being written, large efforts are underway to develop big libraries (like the DTL, parts of which which may break) and version 1.0 is just around the corner (which more-or-less cements the issue for a while, or maybe forever - we are still living issues like this down with C/C++).

Look, FWIW, I'm smitten with D. Absolutely love what I've been able to absorb in a week's worth of late nights. I think Walter is a gutsy genious. Matthew as well - brilliant guy, investing tons of time and stomach lining on developing the DTL and writing about and promoting D. And I'm impressed with all the work and input all the others have put into this language and this newsgroup.

What I'm saying here is all in the spirit of trying to make sure D is being used by more than a couple thousand Die harD D Developers in the coming years. I want this language to succeed because I'm sick and tired of basic inadequecies in C and its derivitive languages. Although I personally hate ocaml, I don't want to see D end up like that - lot's of promise, little future (although I'm damn glad I'm not forced by popularity to use it. It may be intuituve if you speak french, but I don't and loath that language [ocaml, not french] ;).

I work 70+ hrs. a week, have a family that needs attention and STILL want to help D anyway I can, but I simply will not start working (as opposed to playing) with D until fundamental issues like aliasing behaviour, runtime allocated rectangular arrays, etc. are worked out better. All the OOP stuff is great, but it's damn hard to write, improve and _trust the future of_ code developed with a language that hasn't nailed down even more fundamental issues when there are many other good choices out there already that have mature compilers, libraries, etc.

It appears to me (given the versioning scheme of dmc, etc.) that Walter has a different - maybe the correct, who knows - take on versioning than the rest of us. In other words, v1.0 seems like more of an increment than a milestone to him. Problem is almost no one else outside of this community sees it that way. If D takes off (and I'm convinced it won't unless some basic issues like 'the aliasing problem' are taken care of) the D community may have to live with features/results of v1.0 for a long time, even if v1.0 itself is obsoleted in a month.

I like what I've seen so far, but the aliasing issue is one of the underlying reasons WHY C and C++ need to be REPLACED, and are not used for whole classes of applications. Jagged dynamic arrays being the only built-in choice for runtime allocated arrays is another big one.

I hate to rain on the parade here, but I think this language will really suffer in both popularity and somewhat in utility w/o a decent resolution to these two issues (and there may be others as well, but these really stand out). Now a days, most people will simply not adopt another natively compiled language over C/C++/C# and Java until there is a clear performance advantage in doing so and compiler vendors will not support a language where there is primarily C++ style OOP wrapped in different semantics. Face it folks, in the mainstream OOP performance arena C++ is king and Java and C# are making inroads. Ada is the odd man out here, but may well be a better choice than any of those technically. You will win few of those people over, but not many. In the C and Fortran worlds, there is just no way that they will switch until D proves itself a better performer, or at least there is now a reason to believe from the language design that it can perform the same (Fortran) or better (C).

D fans - you gotta see it as most of the rest of the world will see it when a new project comes along. When you think of it, it is not hard at all to imagine this dialog:

Geek: "Boss, there is this new language out there called D that I really like. Howz about we give it a shot for our next project."

PHB: "Ummm, well, why?"

Geek: "Because it's really cool and the compiler is free!"

PHB: "Ok, you've just described about 20 other languages that I can read about and download on the net. Now give me some real good reasons or go back to your C++ IDE, or if you are you still tuning that Java app., finish that.. I have a tee time in a 1/2 hr."

Geek: "Ummm, well I can be maybe about 20% more productive with it, unless the unproven compiler and libraries give me problems."

PHB: "Hmmm, sounds more risky than being near the fairway when I tee off.. How about performance?"

Geek: "Ummm, well the compilers are young yet, but should give me performance on par with Java and maybe reasonably close to C++, at least for some things. But as I say, it's young yet.".

PHB: "Ok, I can understand that every great tool has to start somwhere and the productivity sounds enticing.  You know how picky some users and the development team can be about stuff like performance.. Is there a potential for this language to provide us with better performance once the tools mature - can we finally get rid of those damn Fortran legacy apps. we're always hiring consultants for"?

Geek: "Umm, well, hmmmm, uhhh, well, I guess not, not really anyway. Ok, I'll level with you - it inherited basically about the same performance potential as C++ has, but, but, well it has some cool built-ins and auto-GC".

PHB: "Hmph, well Ok, GC is cool. How useful are the built-ins".

Geek: (Shit, I knew he'd ask that) "Well, for specialized high-performance needs, we can bypass the GC if needed and build our own classes".

PHB: "Sounds like what we've already done and tested with C++"

Geek: "Hmmm, yep".

PHB: (Pats Geek on the shoulder) "Ok, well will talk about it some other time (once I get council from the finger-in-the-wind oracle). In the meantime, get back out there and bust your ass with C++ or finish tuning that Java app. until we sign that contract with that Indian company, would ya".

Geek: (Mumbling under his breath) "[ok - just try not to hit the CEO in the butt with your golf ball again, dork.]"

If you are going to try and win mindshare for a high-performance language, then you have to pay attention to basic issues like this, and do your best to get it right the first time even if the release of the big 1.0 is delayed a while. It doesn't take a rocket scientist to figure out that mimicking C/C++ aliasing and jagged arrays is NOT THE WAY TO GO for a language aspiring to win developers away from it.

I could friggen kick myself for not finding out about D earlier so I could have bitched then. And I'm guessing that many reading this (if any) would like to kick me now.. But anyhow...

PHP is a good example of how to promise and deliver on a language to initially fill a good size niche and then expand to win more mind-share. They didn't try to mimick Java (as used for that class of applications) or ASP on performance or features. What that community started with, promised and delivered on was an easy to learn and use dynamic website scripting language with most of the useful features and decent performance.

I think D will need to do something similiar as far as expectation management. To win away developers and tool vendors from C/C++/Java/C# and maybe even Fortran, some basic underlying design of the language has to be different enough to attract them. IMO, adding more and more, or slightly improving existing, OOP features is not the way to go. Adding high-performance orientated semantics to the language along with /high-performance/ built-ins is the way to go.

In this group and in the archives, I've seen /ALOT/ of talk, argument and mindshare wasted on how this or that OOP feature doesn't exactly coincide with what they expected/wanted/whatever, but comparitively little on the performance of the language and tools or changing the semantics to support high-performance compiler development. The worst part of this, given the squeeky wheel truism, is that Walter has been driven to pay so much attention to OOP nits that the other more basic stuff hasn't gotten the attention it deserves.

Since this is a new language, I really think the most basic needs of the underlying language should be tended to first, don't you??

--- THUMP off the soapbox.. ---

If you made it here, thanks for taking the time to read this..

- Dave

PS: I post more-or-less anonymously to these newsgroups. Rest assured it hasn't been because I'm somehow gutless when it comes to expressing my opinions, defending them or having them attributed to me forever. A family member was recently the victim of ID theft, and I'm a bit wary of any info. I put out into the public domain, including e-mail addresses, etc. (the ID theft modus-operandi included use of an e-mail address).

You obvious have passion and knowledge about the issue of the "Aliasing Problem" that far exceeds my interest. I hope that D doesn't disappoint you in this respect, but I fear that it will. Nonetheless, I do have a few minor points I'd like to make.

Dave wrote:
> In article <schancel-8833C7.08301601082004@digitalmars.com>, Sha Chancellor
> It appears to me (given the versioning scheme of dmc, etc.) that Walter has a
> different - maybe the correct, who knows - take on versioning than the rest of
> us. In other words, v1.0 seems like more of an increment than a milestone to
> him. Problem is almost no one else outside of this community sees it that way.
> If D takes off (and I'm convinced it won't unless some basic issues like 'the
> aliasing problem' are taken care of) the D community may have to live with
> features/results of v1.0 for a long time, even if v1.0 itself is obsoleted in a
> month.

Unless Walter has told you something that he hasn't told anyone else, I don't think anyone knows when DMD 1.0 is coming. I know DMD 0.98 has just been released, but unless Walter slows the releases way down I can't believe we're a couple releases away from DMD 1.0. I think we're going to see a 0.101, 0.102, 0.103, etc. before 1.0 appears. This "floating point" vs. "major.minor" controversy hasn't been commented on by Walter, but Walter hasn't indicated that he wants to release anything other than a polished D 1.0 that will make D look good and stable.

> I like what I've seen so far, but the aliasing issue is one of the underlying
> reasons WHY C and C++ need to be REPLACED, and are not used for whole classes of
> applications. Jagged dynamic arrays being the only built-in choice for runtime
> allocated arrays is another big one. 
> 
> I hate to rain on the parade here, but I think this language will really suffer
> in both popularity and somewhat in utility w/o a decent resolution to these two
> issues (and there may be others as well, but these really stand out). Now a
> days, most people will simply not adopt another natively compiled language over
> C/C++/C# and Java until there is a clear performance advantage in doing so and

I'm not particularly concerned about the performance of C/C++. I care about the easy of programming in those languages (or lack thereof).

I don't like Java because of the performance issues and the requirement of using OOP, but the people who like Java usually don't mind the performance loss and enjoy the OOP aspects. If they're looking for better performance, they'll either like the D syntax or they won't. I doubt they'd switch to D just because it's x percent faster than C/C++. But I'm just guessing.

> compiler vendors will not support a language where there is primarily C++ style
> OOP wrapped in different semantics. Face it folks, in the mainstream OOP
> performance arena C++ is king and Java and C# are making inroads. Ada is the odd
> man out here, but may well be a better choice than any of those technically. You
> will win few of those people over, but not many. In the C and Fortran worlds,
> there is just no way that they will switch until D proves itself a better
> performer, or at least there is now a reason to believe from the language design
> that it can perform the same (Fortran) or better (C).

Honestly, I don't think D is even targeted at Fortran programmers. Or Cobol programmers.

It'd be great if D could appeal to programmers of every language, but I really don't think we're going too get many Visual Basic converts either. Or Caml or Haskell.

D is designed to be what C++ should have been. C programmers that don't like C++ because it's too complicated should like D. C++ programmers who don't think that C is powerful enough should like D. That's the niche that D is targeting. If the libraries become powerful enough so that Java, C#, and Delphi programmers come aboard that's great, but the grand vision has never been "one language to rule them all". Just the best all-around language yet (perhaps I overstate the goal?). Yes, performance is important, but so is the ease of programming.

> Since this is a new language, I really think the most basic needs of the
> underlying language should be tended to first, don't you??

If you're building a house and essentially all you have left to do before you sell it is install the carpet, is that a good time to pull all of the incandescent light fixtures and replace them with fluorescence lights. I think you're talking about big changes and recently Walter has been talking about being done with the design. If you were making these suggestions a year ago, you might have found more interest. But even then could have been too late. Walter's been designing D for several years.

> 
> --- THUMP off the soapbox.. ---
> 
> If you made it here, thanks for taking the time to read this..

Thanks for posting. Maybe Walter can think of an easy way to adjust the Aliasing to allay your performance fears.

We'd all like D to be the best language, but there are different ideas of how that's accomplished. With the increasing speed and memory of new hardware, performance issues aren't always the most important issue. And I think Walter's current goal is for DMD to work right and he'll work on getting it to be "leaner and meaner" later.

> 
> - Dave
> 
> PS: I post more-or-less anonymously to these newsgroups. Rest assured it hasn't
> been because I'm somehow gutless when it comes to expressing my opinions,
> defending them or having them attributed to me forever. A family member was
> recently the victim of ID theft, and I'm a bit wary of any info. I put out into
> the public domain, including e-mail addresses, etc. (the ID theft modus-operandi
> included use of an e-mail address).

A few people around here post more anonymously than you do, I wouldn't feel bad about it.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

On Sun, 8 Aug 2004 20:48:36 +0000 (UTC), Dave wrote:

> In article <schancel-8833C7.08301601082004@digitalmars.com>, Sha Chancellor says...
>>
>>In article <ceis7r$23bt$1@digitaldaemon.com>,
>> Dave <Dave_member@pathlink.com> wrote:
>>
>>> I'm very new to D (literally as of yesterday), but am very impressed with what I'm seeing so far.
>>> 
>>> Being that I want this language to succeed and an important part of that will be performance potential over C, I'm curious - how does/will D deal with the pointer 'aliasing problem' that plagues C and C++ compiler developers?
> <snip>
>>
>>What aliasing problem would you be referring too?  ( No D does not deal with it with denial, it's an honest question :)
> 
> --- Thump, thump - up on the soapbox ---
> 
> I hate to say it, but it's appearing more and more like it is being dealt with by denial ;)

[big snip]

I think I understand what the "aliasing" issue is. What I can't quite see is what you think the resolution should be. Are you ask for the compiler to detect (potential?) aliasing situations and issue an error message? Or is it a run-time solution you are requiring?

If someone on my team coded something like the example you gave, I'd have them rewrite that potentially dangerous code into something a *lot* more sane. Even if updating a shared variable absolutely had to be coded, I'd insist on a runtime check, along the lines of ...

int i;

void func( inout int ri )
{
    if (&ri != &i)
    {
        for( int j = 0; j < 10; j++ ) {
            ri++;
            i++;
        }
    }
    else
        throw new Error("Aliased ri/i");
}

int main()
{
i = 10;
func(i);
printf("%d\n",i);
return 0;
}

//--------------Though this is a safer way...
int i;

int func( in int ri )
{
    for( int j = 0; j < 10; j++ ) {
        ri++;
        i++;
    }
    return ri;
}

int main()
{
int res;
i = 10;

i = func(i);
printf("i=%d\n",i);

return 0;
}

//-----------------

For a compiler to detect aliasing and abort when found, is a dangerous route. It assumes that the compiler absolutely knows what is in the mind of the coder. Who's not to say that the aliasing situation is not the desired one in some circumstances. eg. To demonstrate it to students.

It think Walter saying that it is better to assume that variables are not aliased is the better way to go. And if the coder writes code that can possibly result in it happening, then it is their responsibility to check for it.
-- 
Derek
Melbourne, Australia
9/Aug/04 9:42:21 AM

In article <cf6f15$557$1@digitaldaemon.com>, Derek Parnell says...
>
>On Sun, 8 Aug 2004 20:48:36 +0000 (UTC), Dave wrote:
>>[big snip]
>
>I think I understand what the "aliasing" issue is. What I can't quite see is what you think the resolution should be. Are you ask for the compiler to detect (potential?) aliasing situations and issue an error message? Or is it a run-time solution you are requiring?

What I'm specifically thinking of is something very close to what Walter mentions here: http://www.digitalmars.com/drn-bin/wwwnews?D/28215

Strictly speaking of aliasing problems, since I think non-overlapping array slices are covered by the spec. already, non-aliasing function params would give the most bang for the buck because this is where it messes up optimization the most and probably where it is easiest to check.

I think it would be do-able for a compile-time check to be made on out/inout function/method parameters for native, built-in and object data types, but /not/ pointers, and not for extern (C) functions. That way, the compiler could be 'sure' that it could aggressively optimize for these types of functions and not worry about side effects.

I think this would also have a lot of utility because D coding won't require pointers so much as C and to some extent C++. And of course, it may keep progammers from stepping on each others (heck, there own) code quite a bit for large programs with quite a few modules.

I think the above would be a reasonably workable solution for the following types of situations, because the scoping, out/inout params. and 'import' functionality of D gives the compiler the visibility it needs to determine aliasing like this.

Ok, I know the following is simplistic and doesn't cover all situations, but something like this is what I'm talking about.

;---
objx.d:
class ObjX {
int varY;
int varZ;
}

main.d:
import objx;

int i;
ObjX x, y, z;
// The compiler would "only" need to track variables declared outside
//  a functions scope of the type(s) passed through out/inout param(s).
//  and accessed in a function. The scope of all variables inside a
//  function has to be known when parsing the function, right?
//  Otherwise an "undefined identifier" error would occur.
void foo(inout int ri) {  ri++;  i++; }
// Function _D5main3fooFKivz stored in a linked list attribute in the symbol
//  table for variable _D5main1ii

void bar(out int ri, inout int rj) {  ri--;  rj++; }
void baz(inout ObjX ox) { ox.varY *= 10; x.varZ--; }

class A {
int j;
}
class B : A {
int k;
this() { this.x = new ObjX; }
void foobar(out int z) { k++; z = k / 10; }
ObjX x;
}

B b;
void foobaz(inout A a) { b.k / a.j; }

int a[];
void snafu(inout int arr[]) {
arr[] = 10;
for(int i; i < 10; i++) {
a[i] /= arr[i];
}
}

void main(char[][] args)
{
foo(i);   // Compile error: i is accessed in foo(); can't be passed byref
bar(i,i); // Compile error: i is passed by ref. for more than 1 param.
x = new ObjX();
baz(x);   // Error: x is accessed in baz()
y = x;    // Stored in symbol table for y as currently referring to x
FuncY();  // Error: x is referred to by y and accessed in baz(), called by
FuncY() (see * below)
z = new ObjX();
y = z;    // Symbol table says y is now referring to z
FuncY();  // Ok
FuncZ();  // Error: a refers to b which is accessed in foobaz

b.foobar(b.k); // Error: b.k is passed by ref. and accessed in b.foobar()

a.length = 10;
snafu(a); // Error: a is passed by ref. and accessed in snafu()
for(int i; i < 10; i++) {
printf("a[%d] = %d\n",i,a[i]);
}

y = b.x;
FuncY(); // Ok: y referring to b.x, which is not accessed in baz()

b.x = x;
FuncY(); // Error: b.x refers to x, which is accessed in baz(), called by
FuncY()
}

// (*) A symbol table lookup would check the scope of y for use in FuncY
//      The symbol lookup on y and a check of the 'refers to' attribute could
//       tell the compiler that y currently refers to x
//      symbol table attribute for x would list baz() as a function with a
//        referrence parameter of type ObjX inside x's scope, generating an
//        error.
//  Possible w/o jumping through hoops??
void FuncY() {  baz(y); }
void FuncZ() { b = new B; A a = b; foobaz(a); }

;---

>
>If someone on my team coded something like the example you gave, I'd have them rewrite that potentially dangerous code into something a *lot* more sane. Even if updating a shared variable absolutely had to be coded, I'd insist on a runtime check, along the lines of ...
>

I think you may be talking more of the specifics of the example, whereas I'm talking more generalities exemplified by it. From what I've seen there is a lot of code out there where file scope vars. could be passed into large functions by reference, and break things. Those are nasty bugs to track down also, especially in someone elses code.

With the C and C++ specs. (and right now for D without 'noalias function reference parameters' in the spec.), the compiler has to produce the semantically correct results, so the compiler can't safely optimize many functions even when in actuality they are never used in a way that would be broken by the optimizations.

That's the crux of the issue. Aliasing can effect the code generated for a lot more than in just the few functions where it may actually apply. It's one of those "a few bad apples spoil the barrel" type of things.

C has another problem because extern scope vars. can be accessed in library functions that are linked in, the programmer and compiler can't reasonably check for this in alot of cases.

D on the other hand can check for this easier if I'm correct that the import statement gives the compiler visibility to imported module variable definitions. That's also why it should be able to inline functions better over an entire program, which is a huge plus for D (if I'm right about how import works).

I'm guessing Intel spent several man-years on Whole Program Optimization and alias tracking so they could safely use aggressive optimization techniques when building their C/C++ compiler. Looks like they succeeded - comparable C code often (but not always) runs as fast as their Fortran compiler it seems for even numerical stuff, at least for artificial benchmark types of code, and there Fortran compiler is supposed to be quite good.

I don't think the alias fix would take several man years for Walter. Because of the language design (and who we have writing the compiler), I suspect it maybe something do-able, maybe even b4 v1.0 is released.

The whole point of my earlier rant is that I think a reasonable amount of effort could pay big dividends for D. It's worth some more discussion anyhow, I think..

- Dave

In article <cf66ab$350$1@digitaldaemon.com>, J C Calvarese says...
>
>You obvious have passion and knowledge about the issue of the "Aliasing Problem" that far exceeds my interest. I hope that D doesn't disappoint you in this respect, but I fear that it will. Nonetheless, I do have a few minor points I'd like to make.
>

Passion yes, knowledge, maybe a just a little bit. I'm no compiler writer, heck I'm not even a numerics guy.

The reason I care about it is because D currently adapts something bad from C that I think could finally be done away with w/o a lot of pain. And I hate paying for something many times (in terms of clean code generation) that is there to accomidate a bare minority of the code.

Who knows - maybe the reason Walter is not commenting on this thread is because he's got it figured out or he no longer thinks it as important as he once did in the grand scheme of things (check the archives or my earlier posts pointing to some of these archives if you're curious about that).

>just been released, but unless Walter slows the releases way down I can't believe we're a couple releases away from DMD 1.0. I think we're going to see a 0.101, 0.102, 0.103, etc. before 1.0 appears. This "floating point" vs. "major.minor" controversy hasn't been commented on by Walter, but Walter hasn't indicated that he wants to release anything other than a polished D 1.0 that will make D look good and stable.

Well, that's encouraging at least. 2 things made me think we were heading to 1.0: I believe there was some talk of a release date of March 04 in the archives. Obviously we are way past that. 2nd, the version number scheme that is used for other DM products indicates 1.0 is a couple of releases away unless they start being numbered 0.99.1, 0.99.2, etc. or I guess 1.0 alpha1, 1.0 alpha2, 1.0 beta1, etc. could be used. But your right - none of this is set in stone.

>
>I'm not particularly concerned about the performance of C/C++. I care about the easy of programming in those languages (or lack thereof).
>
>I don't like Java because of the performance issues and the requirement of using OOP, but the people who like Java usually don't mind the

I'm confused - you don't care about C++ performance, but do about Java performance?

The truth is becoming, except for probably some (important) OOP stuff like generics and others, a few Java runtimes are closing the gap with top C++ compilers in both benchmarks and more than just some 'real world' code from what I've heard from fellow developers who've used both.

That's another reason I want D to be superior in performance, or at this stage, at least superior in performance /potential/.

>performance loss and enjoy the OOP aspects. If they're looking for better performance, they'll either like the D syntax or they won't. I doubt they'd switch to D just because it's x percent faster than C/C++. But I'm just guessing.

Right now, according to some benchmarks I've run, D seems a good margin slower for somethings, especially when the built-in strings and AA's are used. For example char[] concatenation in a tight loop like this:

;---
D:

import std.string;
import std.stream;

int main()
{
char[] input, output;

output = "<TABLE><TR><TD>\n";
File f = new File("some_large_file",FileMode.In);
while(!f.eof()) {
input = f.readLine();
output ~= input;
output ~= "</TD><TD>\n";
}
f.close();

output ~= "</TD></TR></TABLE>\n";

printf("output length: %d\n",output.length);
return(0);
}
output length: 6944735
real    0m37.747s
user    0m31.840s
sys     0m3.180s
;---

C++:

#include <string>
#include <fstream>
using namespace std;

int main()
{
string input, output;

output = "<TABLE><TR><TD>\n";
ifstream f("some_large_file",fstream::in);
while(getline(f,input)) {
output += input;
output += "</TD><TD>\n";
}
f.close();

output += "</TD></TR></TABLE>\n";

printf("output length: %d\n",output.length());
return(0);
}
output length: 6944735
real    0m0.311s
user    0m0.260s
sys     0m0.040s
;---

is alot slower than basic_string<> in C++. Now I know about OutBuffer, but people will be drawn to using char[] for this, just like they are drawn to Java String instead of StringBuffer or StringBuilder (Java v1.5). Here's the OutBuffer version:

import std.string;
import std.stream;
import std.outbuffer;

int main()
{
char[] input;
OutBuffer output = new OutBuffer();

output.write("<TABLE><TR><TD>\n");
File f = new File("some_large_file",FileMode.In);
while(!f.eof()) {
input = f.readLine();
output.write(input);
output.write("</TD><TD>\n");
}
f.close();

output.write("</TD></TR></TABLE>\n");

printf("output length: %d\n",output.toString().length);
return(0);
}
output length: 6944735
real    0m5.217s
user    0m2.640s
sys     0m2.280s
;---

C++ is still 10x faster, and the Java version would probably be not far behind C++ from what I've seen.

Like it or not, many people will choose whether or not to give a language a 2nd look based on benchmarks. _Especially_ when the competition is C/C++ or Java.

>Honestly, I don't think D is even targeted at Fortran programmers. Or Cobol programmers.

Maybe not Cobol programmers, but check the archives on the Fortran question. While maybe not an explicit goal, it seems to be a sincere wish of Walter and others that D would be considered as a replacement for Fortran. It is one of the areas C/C++ falls short. One of the reasons why C/C++ falls short here is [you guessed it] 'the aliasing problem'.

>It'd be great if D could appeal to programmers of every language, but I really don't think we're going too get many Visual Basic converts either. Or Caml or Haskell.

Caml or Haskell I agree with, but that is probably a pretty small minority. Visual Basic I strongly disagree with. Apparently many of those people have decided to switch to Java or C# when VB went the .NET route. D would be right up their alley.

>D is designed to be what C++ should have been. C programmers that don't like C++ because it's too complicated should like D. C++ programmers who

That's the point - C++ should have handled the aliasing problem (among other C weaknesses) differently, but the principal designers of that language were too damn busy fighting over arcane OOP issues (sound familiar? ;).

>If you're building a house and essentially all you have left to do before you sell it is install the carpet, is that a good time to pull all of the incandescent light fixtures and replace them with fluorescence lights. I think you're talking about big changes and recently Walter has been talking about being done with the design. If you were making these suggestions a year ago, you might have found more interest. But even then could have been too late. Walter's been designing D for several years.

Funny you should mention that. Something like it happened to a house I had built. It turns out some of the electrical would not pass inspection so they had to change that before they could lay the carpet (true story).

And I /may not/ be talking about changes that are all that huge or drastically hard to implement either. It's certainly worth more discussion IMHO, which is why I keep at this thread.

>
>> If you made it here, thanks for taking the time to read this..
>
>Thanks for posting. Maybe Walter can think of an easy way to adjust the Aliasing to allay your performance fears.

I hope so.

>of how that's accomplished. With the increasing speed and memory of new hardware, performance issues aren't always the most important issue. And I think Walter's current goal is for DMD to work right and he'll work on getting it to be "leaner and meaner" later.

Sorry, but I have to call you on that.. Many have been saying similiar for years and it seems that software complexity always fills the gap, and then some. Java fans are qouted as saying the same ad nauseum in the early days and even now to some extent. In the eight or so years since Java took off, people are still comlaining about it and /both/ machines and Java runtimes are quite a bit more performant now than they were then.

I've heard tell that a machine costing under about $5000 hasn't even been built yet that can run the next version of Windows with generally acceptable performance. MS is literally betting the farm that Moore's Law will continue unimpeded so they have something to run what they sell. It's a good bet, but still a bet.

Maybe with a D spec. that takes care of the aliasing issue, they could have wrote the new Windows with D and I could run it on my trusty 'old' Pentium 4 machine, and spend the $3000 I'd save on a new Harley ;)

- Dave

[mega-snip]

> ;---
> D:
> 
> import std.string;
> import std.stream;
> 
> int main()
> {
> char[] input, output;
> 
> output = "<TABLE><TR><TD>\n";
> File f = new File("some_large_file",FileMode.In);
> while(!f.eof()) {
> input = f.readLine();
> output ~= input;
> output ~= "</TD><TD>\n";
> }
> f.close();
> 
> output ~= "</TD></TR></TABLE>\n";
> 
> printf("output length: %d\n",output.length);
> return(0);
> }

Have you tried using a BufferedFile? The default File is unbuffered. There are a number of posters who think the default File should be buffered and I'm starting to agree - just because people seem to assume it is buffered.

> output length: 6944735
> real    0m37.747s
> user    0m31.840s
> sys     0m3.180s
> ;---

[mega-snip]

Ben Hinkle wrote:
<snip>

> Have you tried using a BufferedFile? The default File is unbuffered. There
> are a number of posters who think the default File should be buffered and
> I'm starting to agree - just because people seem to assume it is buffered.

I would be careful with this.  Something I have found with Java IO
Streams is that buffering can backfire--and if there is no way to
turn it off then the developer is stuck.  Let me give an example:

In a web environment you need to handle as many requests as you can
at one time.  This is key to scalability.  Initial testing might
suggest that using a BufferedInputStream for file IO would speed up
the request/response time on the server.  Then later, when you are
doing load testing, you find that the extra KB or so of RAM taken
up by the buffer is adding up quickly and your system starts falling
apart at the seams due to the heavy load on the memory system.

This is something I have been bitten by in the past.  I would be
surprised to find it only limited to Java.  The solution to use
unbuffered IO or even a greatly reduced buffer size helped the
scalability of the webapp.