"Paulo Pinto" <[email protected]> wrote in message news:[email protected]... > 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.
