Anders F Björklund wrote:

> Norbert Nemec wrote:
> 
>> For C - of course, one should be able to bind in existing C code, but in the long term, there should not be any reason to write new code in C if you have a D compiler at hand.
> 
> I see D as a nice replacement for C++ in the (very) long run,
> but I will continue to use either C or Java when they fit better...

For Java this is clear - it has a completely different objective, so D does not even try to compete with in every respect.

For C on the other hand, D should try to surpass it in every respect, so that there are no cases left, where C "fits better". This certainly is an ambitious goal that may never be reached completely, but nevertheless, it is a goal.

> Maybe the auto initialization can be be replaced with an error if you try to actually use the value without setting it first ? Like in Java.

This would not make much difference. If the compiler is able to detect this error, it is also able to optimize away unnecessary initializations. This is simple in trivial cases but - I believe - impossible in general.

J C Calvarese wrote:

> The majority of programmers would never touch this
> setting. Those that have to clear 1 TB of memory have the option.

You don't really have to go for one 1TB to see the use of that option. Write a routine that has a 1KB array locally on the stack and call that routine repeatedly...

Norbert Nemec wrote:

>>I see D as a nice replacement for C++ in the (very) long run,
>>but I will continue to use either C or Java when they fit better...
> 
> For Java this is clear - it has a completely different objective, so D does
> not even try to compete with in every respect.

Just some... And the languages are not *that* different, actually ?
(just talking about the Java language, not the JVM or the religion)

> For C on the other hand, D should try to surpass it in every respect, so
> that there are no cases left, where C "fits better". This certainly is an
> ambitious goal that may never be reached completely, but nevertheless, it
> is a goal.

I don't see either D or C++ as a replacement for regular C, more as a compliment? In my world, C is a more portable alternative to assembler.
This does not mean I write everything in it (or in assembler, either)

For me, D fits in nicely between the C and Java language "extremes"...

--anders

Brian Chapman wrote:

> But all of this is irrelevant to me, because if you're wanting to do gigabyte bare-metal memory blits for video editing, it would be beyond me why you would be using D and expecting it to do what you want. Why not just use Java? That makes about as much sense. You need to know YOUR hardware and write bare-metal ASM to get what you need done if it's that vital.

Writing assembler to get performance is about as outdated as counting cycles. As I said before: if the code is simple enough to write it in assembler, it is also simple enough for a reasonable compiler to optimize it to the same extent.

To exploit the full power of a modern processor, you have to do the right amount of loop unrolling, loop fusing, command interlacing and so on. YOu have to play with the data layout in memory, perhaps chunking arrays into smaller pieces. There are several more techniques to use, when you want to make full use of pipelining, branch prediction, cache lines and so on.

Languages like Fortran 95 would in principle allow to compiler to do all of this automatically (Some good implementations begin to emerge.)

Doing all of it by hand in C results in complete spaghetti code, but it is possible if you know exactly what you are doing. (In a course we did, we eventually transformed one single loop into an equivalent of ~500 lines of highly optimized spaghetti. The result was ten times faster than the original and somewhere around 80% of the absolute theoretical limit of the processor.

The result was still pure C and therefore completely portable. The performance was, of course, tuned to one specific architecture, but there were basically constants to adjust for tuning it for about any modern processor.

Doing the same thing in assembler would probably not be much faster. (After you went from 8% to 80%, the remaining factor of 1.25 probably isn't worth the effort. 80% peak performance is already well beyond what people usually go for.)

Furthermore, writing that kind of spaghetti code in C without getting an error in already needs a lot of discipline. Doing the same thing in assembler will probably land you in the next psychiatry...

Norbert Nemec wrote:

> Writing assembler to get performance is about as outdated as counting
> cycles. As I said before: if the code is simple enough to write it in
> assembler, it is also simple enough for a reasonable compiler to optimize
> it to the same extent.

Of course, *reading* assembler is a good way to help write that good C code and is also a great help when debugging without the source code?

So I still think learning to read (and write too, just for compliment)
assembler is relevant, just as I think C is... Lots of people disagree*.

> Doing the same thing in assembler would probably not be much faster. (After
> you went from 8% to 80%, the remaining factor of 1.25 probably isn't worth
> the effort. 80% peak performance is already well beyond what people usually
> go for.)

You could be in for a surprise there, though. But I agree that writing
assembly is now a lot harder these days, in the post-RISC CPU era...

These days, assembler and C are more useful for generating *small* code?
Major loop unrolling and load/store reordering are a pain to do in asm.

--anders

* = Those darn Quiche Eaters. C and ASM is for us Real Programmers. :-)

In general, rewriting C in assembly doesn't improve much,
since modern compilers are good at optimizing general-purpose code. Where hand-tuned assembly can often boost the performance is with
programs that may exploit MMX & SSE instructions.



Norbert Nemec wrote:
> Writing assembler to get performance is about as outdated as counting
> cycles. As I said before: if the code is simple enough to write it in
> assembler, it is also simple enough for a reasonable compiler to optimize
> it to the same extent.
> 
> To exploit the full power of a modern processor, you have to do the right
> amount of loop unrolling, loop fusing, command interlacing and so on. YOu
> have to play with the data layout in memory, perhaps chunking arrays into
> smaller pieces. There are several more techniques to use, when you want to
> make full use of pipelining, branch prediction, cache lines and so on.
> 
> Languages like Fortran 95 would in principle allow to compiler to do all of
> this automatically (Some good implementations begin to emerge.)
> 
> Doing all of it by hand in C results in complete spaghetti code, but it is
> possible if you know exactly what you are doing. (In a course we did, we
> eventually transformed one single loop into an equivalent of ~500 lines of
> highly optimized spaghetti. The result was ten times faster than the
> original and somewhere around 80% of the absolute theoretical limit of the
> processor.
> 
> The result was still pure C and therefore completely portable. The
> performance was, of course, tuned to one specific architecture, but there
> were basically constants to adjust for tuning it for about any modern
> processor.
> 
> Doing the same thing in assembler would probably not be much faster. (After
> you went from 8% to 80%, the remaining factor of 1.25 probably isn't worth
> the effort. 80% peak performance is already well beyond what people usually
> go for.)
> 
> Furthermore, writing that kind of spaghetti code in C without getting an
> error in already needs a lot of discipline. Doing the same thing in
> assembler will probably land you in the next psychiatry...

zwang wrote:

> In general, rewriting C in assembly doesn't improve much,
> since modern compilers are good at optimizing general-purpose code. Where hand-tuned assembly can often boost the performance is with
> programs that may exploit MMX & SSE instructions.

Then again, modern compilers can use those instructions too...

Here's for GDC's speedily porting to GCC 4.0, that does those.

--anders

Anders F Björklund wrote:

> Norbert Nemec wrote:
>> For C on the other hand, D should try to surpass it in every respect, so that there are no cases left, where C "fits better". This certainly is an ambitious goal that may never be reached completely, but nevertheless, it is a goal.
> 
> I don't see either D or C++ as a replacement for regular C, more as a compliment? In my world, C is a more portable alternative to assembler. This does not mean I write everything in it (or in assembler, either)

OK, I probably came on a bit too fast with my answer. C certainly has its uses. Personally, I don't use it at all, but then - everybody has a limited view of the world...

Anders F Björklund wrote:

> Norbert Nemec wrote:
> 
>> Writing assembler to get performance is about as outdated as counting cycles. As I said before: if the code is simple enough to write it in assembler, it is also simple enough for a reasonable compiler to optimize it to the same extent.
> 
> Of course, *reading* assembler is a good way to help write that good C code and is also a great help when debugging without the source code?

Of course: if you want to exploit your compiler you have to know it, so reading assembler might be a good idea once in a while...

>> Doing the same thing in assembler would probably not be much faster. (After you went from 8% to 80%, the remaining factor of 1.25 probably isn't worth the effort. 80% peak performance is already well beyond what people usually go for.)
> 
> You could be in for a surprise there, though.

Not really. In that specific example (which was typical for numerics) the algorithm was given. It was known that the calculation needed a certain number of floating point operations. Each processor has some physical limit of floating point operations per second that it could theoretically achieve under absolute optimum conditions. No code in the world will ever break this limit. If you reach 80% of it with plain C code, you know that using assembler cannot not give you much gain. No surprise possible as long as you stick to the same algorithm.

> These days, assembler and C are more useful for generating *small* code?

Of course. Code-size was never a concern for me yet. I was only talking about performance. (Be aware though, that excessive code-bloat is bad for performance as well. The code-cache is limited as well, so excessive loop-unrolling will kill performance as well.)

Norbert Nemec wrote:

> Of course. Code-size was never a concern for me yet. I was only talking
> about performance. (Be aware though, that excessive code-bloat is bad for
> performance as well. The code-cache is limited as well, so excessive
> loop-unrolling will kill performance as well.)

I think the new GCC default on Mac OS X, -Os, is a fair trade-off ?
It's same as -O2, without the excessive code-heavy optimizations...
http://gcc.gnu.org/onlinedocs/gcc-3.3.5/gcc/Optimize-Options.html

It's a good allround compiler setting. For systems that tune the
output to the present computer, like Gentoo Linux, then other
flags might be in order that more specifically target the CPU.

But it's very hard to "optimize for the general case", which is why
Just-In-Time compilers and recompiling from source code are popular ?
Problem with assembler is that it just isn't portable enough today.

But I think the *performance* of D and DMD is more than good enough.
Right now I'm more concerned about the bugs and ever getting to "1.0"
(and porting GDC to the new GCC 4.0, would also be very interesting)

--anders