Website message overhaul

[Paulo Pinto]

Hi,

the code below is what I managed to achieve, but I
do conceed that the D code looks better.

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?

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.

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

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




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;
         }
     }
}


--
Paulo

Am 19.11.2011 16:32, schrieb Nick Sabalausky:
> "Paulo Pinto"<pjmlp at progtools.org>  wrote in message
> news:ja6mof$p0p$1 at digitalmars.com...
>> Am 18.11.2011 22:40, schrieb Nick Sabalausky:
>>>
>>> For example, if you take a language that has no direct memory
>>> manipulation,
>>> you're never going to write, say, a codec or a software rasterizer that's
>>> as
>>> fast as what could be done in C/C++/D/etc. If you take a language that
>>> does
>>> have that ability, but it's awkward to use, then it *might* be possible,
>>> but
>>> it's not realistically going to happen (and if it does, it only means
>>> someone just wasted a bunch of their time).
>>>
>>> The only way this will ever change is if somebody invents a *perfect*
>>> optimizer, and that obviously hasn't happened yet.
>>
>> But does it matter if the application is already executing fast enough
>> for its purposes?
>>
>
> That's not the issue though. The question was "Is the efficiency of native
> code [necessarily] possible in C# "? "Good enough" is beside the point.
>
>> I am a big defendent of polyglot programming, if the application still
>> lacks the required execution after all algorithm changes have been tried
>> then the hot spot can even be written in Assembly for what I care.
>>
>> Always use the right tool for the job.
>>
>> As for your example, my C# is a bit rusty but I'll have a go at it during
>> the weekend.
>>
>
> It may very well be possible, but back when I encountered it a few years ago
> I spent at least a couple days on it and gave up. Good luck though. If you
> do manage to get it, I'd be very interested in seeing how. Hell, C# has had
> some new versions since I left it, there might even be a new feature now
> that would change things.
>
>