Website message overhaul

[Nick Sabalausky]

"Paulo Pinto" <pjmlp at progtools.org> wrote in message 
news:ja8p96$1q53$1 at digitalmars.com...
> Hi,
>
> the code below is what I managed to achieve, but I
> do conceed that the D code looks better.
>

Hmm, I'm impressed that it does appear to be possible. And it's not even as 
bad-looking as I would have expected. Benchmarks would be interesting.

Although, I do still think it's an example of an efficient approach that's 
effectively discouraged by the langauge, and therefore much less likely to 
actually happen in the wild. How many C# users are even going to know they 
can do that? (But maybe the features involved are all more common knowlege 
in the C# world than I think?)

> Regarding the efficiency of native code in other languages,
> do you consider efficiency the hability to do low level tricks
> with the language or generating proper native code?
>

Mainly the former. (Which is part of why I was always more drawn to C# than 
Java). Like you indicated about quality of implementation, just because 
something is native code doesn't necessarily mean it's *good* native code.

> I have been developing applications in last 10 years in high level
> languages and very seldom required to do low level tricks to achieve
> what I consider efficient code.
>

Well, the vast majority of the time I come across a slow, bloated app, it's 
from a VM or otherwise dymanic language. The vast majority of the time I 
come across a lean, zippy app, it's from something like C/C++/D/etc. 
Whatever the exact reasons, the former group of langauges tends to lean 
towards inefficient approaches, and the latter group tends to lean towards 
more efficient approaches. (I try to avoid calling the things like 
C#/Ruby/Java/etc high-level, since I consider D to be just as high-level, if 
not more - it's just that D is *also* more low-level, too)

Also, in my own personal experience coding, even just a quick-n-dirty 
approach in C, C++ or D tends to be *noticably* more efficient than putting 
forth the same amount of effort in something like C# or Java. With the 
VM-ish stuff, I've always found you need to put forth more effort to get 
comparable efficiency.

> Regarding your example I would rather write a software rasterizer or
> code using SIMD instructions or a GPGPU language.
>

Ok, so I'm old and so are my examples ;)

> The cast trick you did although quite handy, is the type of language
> feature that prevents D to use advanced GC algorithms.
>

Interesting point. Although, it is a balancing act: From what I hear, JVM is 
considered to have a top-notch GC (no doubt due in part to it's lack of 
low-level ability), but I bet you'd be hard-pressed to get our 
reinterpret-cast-Foo example or codecs/filter/rasterizers/etc (assuming you 
actually wanted to ;)) to run as fast in Java as in D.

>
>
>
> using System.Runtime.InteropServices;
> using System.IO;
>
>
> [StructLayoutAttribute(LayoutKind.Sequential, Pack=1)]
> internal unsafe struct Foo
> {
>     int x, y;
>     byte r, g, b, a;
>     fixed char ident[16];
>     fixed uint data[100];
> }
>
> public class Example {
>     public unsafe static void Main(string[] args)
>     {
>        var buffer = File.ReadAllBytes("data.bin");
>        fixed (byte *bufferPtr = &buffer[0]) {
>            Foo* data = (Foo*)  bufferPtr;
>         }
>     }
> }
>
>