In article <dvs40o$1amc$1@digitaldaemon.com>, Matthias Spycher says...
>
>Dave wrote:
>>> 2. Languages like Java have the advantage that they don't expose the actual layout of objects in memory to the programmer. Any language with pointers has a disadvantage in the context of dynamic optimization.
>>>
>> 
>> If you're talking about the famous "pointer alias problem" then Java is certainly not immune to that (maybe even less so because of all of the references floating around).
>>
>
>True, but accurate garbage collection is a requirement if you're going to scale to support large, long-running applications. C-pointer functionality eliminates the potential. The D community might (in the future) consider the introduction of a managed D subset that would make accurate GC possible.
>
>>> 3. Multicore/multithreaded systems will provide for enough computational bandwidth for dynamic compilers and GCs to run in parallel with the programs they operate on. Performance degradation due to compilation at runtime will become a moot point on server systems very soon.
>>>
>> 
>> A compiler on these systems can be extremely complex, a VM even more so. A contemporary case in point is the Itanium compiler (it's not multi-core, but supposed to operate many pipelines per clock and a big part of that is the compilers job). If anything the difference between an Itanium static compiler and Java VM's is more pronounced on these systems because of the amount of work involved in optimizing for them. Chips like IBM's Cell system will make the problem even worse, not better.
>
>I agree it's not easy, especially for asymmetrical multi-core processors like Cell. Time will tell. I don't believe dynamically compiled apps will consistently beat the equivalent statically compiled program. But for many apps the performance difference will probably be similar to that between an assembly program and the equivalent C/C++ implementation. And that will have to be weighed against all other factors, e.g. productivity during development, deployment costs, maintenance, etc.
>
>Matthias

Good points... I'm not so sure accurate GC can't be done on non-raw-pointer data with D as-is. Conservative collectors for C/C++ as they are of course is a must, but I'm not so sure w/ D because the compiler/GC interface can be synchronized. Don't ask me to expound on it because I can't, just something in the back of my tiny mind somewhere. <g>

- Dave

Sean Kelly wrote:
> Matthias Spycher wrote:
...
>> True, but accurate garbage collection is a requirement if you're going to scale to support large, long-running applications. C-pointer functionality eliminates the potential. The D community might (in the future) consider the introduction of a managed D subset that would make accurate GC possible.
> 
> The D standard doesn't have any language that prevents this.  I think it would be quite possible to implement an incremental GC in D if one had control over code generation.

Are you suggesting whole-program analysis? Would one have to compile a certain way ahead-of-time to support a particular kind of GC? If yes, do you think that's practical? How would you deal with shared libraries that may be dynamically loaded -- fall back to a conservative GC?

"Roberto Mariottini" <Roberto_member@pathlink.com> wrote in message news:dvr4c1$4de$1@digitaldaemon.com...
> This is something I was afraid of, at the beginnin of my work with Java.
> In the
> end, after 10 years, I can say it never applied to Java.
> I don't exclude that in the Java VM design there's something that ease the
> verification of the VM correctness, giving always high quality VMs. And I
> don't
> use only Sun's JVM. The fact that you have to pass a lot of test by Sun
> before
> you can use the word "Java" for your VM maybe means something.

Sun has worked hard at solving this problem by providing a comprehensive test suite. I think they've been reasonably successful at doing that, although I regularly read that people still have to tweak for various VM's.

But once again, this is *not* an inherent charactistic of VM's. If, for example, one had a comprehensive compiler test suite for various platforms, and one prevented calling any that didn't pass it a "D compiler", one could do just as well.

In article <dvs41e$1ae5$1@digitaldaemon.com>, Sean Kelly says...
>
>pragma wrote:
>> In article <dvrrca$103i$1@digitaldaemon.com>, Don Clugston says...
>>> In digitalmars.com digitalmars.D:35128, Walter said of the difference in reals between Linux and Windows:
>>>
>>>>> pragma's DDL lets you (to some extent) mix Linux and Windows .objs. Eventually, we may need some way to deal with the different padding.
>>> I think it's a pipe dream to expect to be able to mix obj files between operating systems. The 96 bit thing is far from the only difference.
>>>
>> 
>> I read Walter's remark, and it came to me like a shot from the blue.
>> 
>>> Now, he's quite knowledgeable, but I'd love to prove him wrong on this one. I find it hard to believe that it would be impossible. I guess the question is, will the subset of functionality that works be sufficient to be useful? I guess we won't know until the ELF side is working.
>>>
>>> "Compile once, run everywhere that matters"? (Win, Linux, Intel Mac).
>> 
>> Pipe dream or not, I think its worth looking into.  And you're right: the portable subset of features may be just barely usable.  Until we get some people really pounding away on this, we'll never quite know.
>
>For what it's worth, there was a thread on comp.std.c++ recently about a standard shared library format, and someone said that library formats have recently become sufficiently similar that this is a possibility.
>

Ahh, thanks for the info Sean (and for reminding me what a godsend *this* particular NG is).  Its funny looking at the posts that go back a year or two to see folks lobbying around a "Module format" or "module include" (read: import) operator.  Overall, I think we're on the right track with D and DDL.  If any ABI for cross-platform binaries/libraries/modules is going to come about, it'll likely come up later out of necessity - so far I've been *anticipating* need rather than satisfying it.

On an unrelated note, I also stumbled into Bjarne's proposal on XTI which is just flat-out scary:

http://lcgapp.cern.ch/project/architecture/XTI_accu.pdf

- EricAnderton at yahoo

Matthias Spycher wrote:
> Sean Kelly wrote:
>> Matthias Spycher wrote:
> ...
>>> True, but accurate garbage collection is a requirement if you're going to scale to support large, long-running applications. C-pointer functionality eliminates the potential. The D community might (in the future) consider the introduction of a managed D subset that would make accurate GC possible.
>>
>> The D standard doesn't have any language that prevents this.  I think it would be quite possible to implement an incremental GC in D if one had control over code generation.
> 
> Are you suggesting whole-program analysis? Would one have to compile a certain way ahead-of-time to support a particular kind of GC? If yes, do you think that's practical? How would you deal with shared libraries that may be dynamically loaded -- fall back to a conservative GC?

Incremental garbage collection requires compiler support, and it does basically involve whole-progam analysis.  For those unfamiliar with incremental GC, the way it works (even in Java) is for the compiler to inject code around all pointer modifications which signals the GC that the pointer has changed.  This allows the GC to know which memory blocks to rescan later.  The problem with incremental GCs is that it's difficult to guarantee that the GC will make progress, as frequent pointer changes could force the GC start over repeatedly (I read one paper that did describe such an incremental GC, but such implementations are definately not the norm).  Also, the code injection means pointer modifications are far more expensive--from 10 to 100 instructions depending on the situation (if my memory serves me).  However, this slower average performance is counterbalanced by the elimination of "stop the world" collections.  I can see this being a very reasonable approach for some realtime applications, but perhaps not as a general purpose strategy.

There are a few odd alternatives out there, such as Boehm's "mostly parallel" which marks memory blocks as read-only using VMM calls during its initial scanning phase (which doesn't stop the world), and then has a much shorter "stop the world" phase later on.  However, these memory page manipulations are very expensive, so this approach is probably not optimal in most situations.

I think an incremental GC could be done for a subset of D without too much trouble (ie. any code that uses plain old reference manipulation), but being able to pass pointers and arrays of pointers to C functions is a stumbling block.  An incremental GC may still be possible, but it would need to be over-conservative in how pointer changes are tracked. Basically, any time pointer data is passed to an opaque function the compiler would have to assume that it could be modified and to signal the GC appropriately.

The more liekly situation is that D will always use a conservative GC "with hints," so type information is used whenever possible to focus the scan phase, but untyped memory allocations will be scanned by default, though the user could indicate that this is not necessary.  In Ares, I'm going to eventually parameters to malloc/calloc/realloc for this purpose.


Sean

Unknown W. Brackets wrote:
> You provide a framework with which people can make games (except, let's assume you actually make it so the games can be unique and of some quality, not something useless.)  This isn't far from what big game companies do, by the way.  Then, you open source/free this.  You provide support for it, services again.

Yeah, this is how I'm thinking of doing it (games that is). I'm all for open source for the framework as it will allow others making games to contribute useful additions and fixes as well. I even think it would be nice to give away the source for the game for those that buy it. But obviously this can be a problem.

> The only problem is, if you suck as a programmer, you're gonna have problems.

Hmm, what are you trying to say about my coding skills? :)

Well I learned Pascal in high school and college and taught myself C, C++, and a whole bunch of other languages. I guess I'll just have to work twice as hard so that I don't make a fool of myself. I just wish I could retain all of the information I've read in books and websites...

kris wrote:
> Kyle Furlong wrote:
>> kris wrote:
>>
>>> Walter Bright wrote:
>>>
>>>> "kris" <foo@bar.com> wrote in message news:4420779B.6020604@bar.com...
>>>>
>>>>> It would be more interesting if this were entitled D vs C++. After all, isn't that (as Mattias indicated) the target "competition" ?
>>>>
>>>>
>>>>
>>>> We've already had those threads in spades <g>. 
>>>
>>>
>>> True <g>
>>>
>>> Did anyone mention DDL? Given that it would make D the only compiled language I've heard of with a runtime link-loader, that would seem to have some bearing?
>>
>>
>> Just what I was thinking. Can DDL make compile once, run everywhere possible? (assuming that is an idiom we would like to support)
> 
> No, DDL does no such thing. Nor is it intended to (instead, it's deliberately machine-architecture specific).
> 
> Functionality exposed by DDL is roughly the equivalent of a Java class-loader, but for pre-optimized native object-code exposing a D callable interface. This is a highly unusual attribute for native code runtime, and is (in my opinion) one of the most important assets for the D language. DDL also has the potential to support full reflection.

I wasn't talking about across architectures, just operating systems. Obviously the object code is platform specific.

Well, what you can do is wait for the game to get old, and then release the source.  You won't lose much doing that, but others will gain from the source and that will feed back to you.

I'm not saying anything about your coding skills!  I just mean it as a warning: some people these days are not good coders, and they get completely shown up when they try to do open source.  A lot of closed-source programmers could never make it in open source.

But, then, there's always people who will use crappy code, because they don't know or don't care.  But it causes problems.

But as I said, as long as you know what you're getting into, it's cool.  Forum software, which I did a lot of, is rough because security and functionality constantly fight each other.  XSS is really a hard thing to master.  Games don't have to worry about these things as much.

Hopefully my comments are of some help to you :).

Thanks,
-[Unknown]


> Unknown W. Brackets wrote:
>> You provide a framework with which people can make games (except, let's assume you actually make it so the games can be unique and of some quality, not something useless.)  This isn't far from what big game companies do, by the way.  Then, you open source/free this.  You provide support for it, services again.
> 
> Yeah, this is how I'm thinking of doing it (games that is). I'm all for open source for the framework as it will allow others making games to contribute useful additions and fixes as well. I even think it would be nice to give away the source for the game for those that buy it. But obviously this can be a problem.
> 
>> The only problem is, if you suck as a programmer, you're gonna have problems.
> 
> Hmm, what are you trying to say about my coding skills? :)
> 
> Well I learned Pascal in high school and college and taught myself C, C++, and a whole bunch of other languages. I guess I'll just have to work twice as hard so that I don't make a fool of myself. I just wish I could retain all of the information I've read in books and websites...

Lucas Goss wrote:
> Secondly... games! This is where open source doesn't fit in my opinion. I make a game and release it, who will pay for support. Users will think it's a bad game if it doesn't work or if it's buggy. And gamers won't pay to add things (unless it's maybe like $5), and instead choose to try to do Mod's.
> 

Do you know what Valve did with their games? (Half-Life/Half-Life2)

They released the source to the game engine (*not* the graphics engine, only the game logic, which by the way, is huge), and allowed hobyists to modify it and distribute their modifications (aka Mods). That's how Counter-Strike was born.

Yeah, it's not really open source, but it's close. It seemed to work great for Valve!

Walter Bright wrote:

> If, for example, one had a comprehensive compiler test suite for
> various platforms, and one prevented calling any that didn't pass it
> a "D compiler", one could do just as well.

This might not be a bad idea for D.