Is there any future?

[ssb]

I agree that developing using .NET is a much faster and easier task than playing with C++ pointers and manual memory management. But that comes at a cost. I've ported some of my projects from C++ to C#, but I've noticed a huge performance hit, even with Ngen'ed .NET executables.
CLR as a library is a nice OO framework but I hate the VM/JIT idea. Consider how nice would be if CLR was a statically linked lib similar to MFC and C# a true native compiler able to compile and link true Win32/64 PE executables.

[theCaller]

Everything comes at a cost.
Native code is faster. That is true indeed.

COM was the Microsoft try of introducing the "bridge" between software components through their interfaces.
That was done in a binary form. COM componets were compatibles each others for they were binary compatible. COM specification granted that compatibility through strict stack morphology rules.

.NET's come to simplify this scenario. contracts between components are now well defined and made thorugh metainfo specification (say a human readable form that is standardized, embedded in each sw component)

The .NET runtime grants this infos to be used and applied. So no matter if you're using VB, C++, C# , Logo, COBOL whatever .. as far as contracts between the sw components you deploy are well defined and under standard protocol, sw components will be easily communicating each other: no matter the underlying physical layer, that is abstracted by the runtime.

This comes at a cost, right. But it's a good compromise.

Native code will not die. It's the core of the system. No one will obscure the tools to make pure native code apps...
As far as CPU will not interpret directly bytecode ... ... maybe we will be in charge of changing the way we've always seen the world ... but until then ...

Best regards,
theCaller

Originally Posted by ssb

I cannot stand Microsoft when they try to push developers to move to a platform inferior in terms of performance.

The gain in productivity greatly outweighs the loss in performance, assuming you're not developing a realtime system. But then again, if you were developing a realtime system, you should know not to use Windows to begin with since it's not a realtime OS.

In response to peleon's original question (what language(s) to learn other than x86 ASM), I would recommend C and C#.

little addone from me
1. future cpu will be amd64 not ia64, due amd is faster in gaming,encode, has 1/3 faster sse2/3 instruction, still is risc, doesnt have fucked up instruction like inc,lea that were 1 tick now 4 clock ticks in P4, another thing amd64 has 8 more general purpose registers for use for coders, so wonder what will they choose? 8 from ia64 or 16 from amd64, ia64 has only faster fpu and is faster in office apps, but who will use old 64/80 bit fpu if we have 128bit sse floats

2. .net i hope it will die, i hate this crap even when i see vb proggy and someone gives it to me i will delete it because why he havent compiled it into normal exe, just requieres me to install 50mb of that VM crap, other things many programs come out in that(due its easier,faster, easier to due network things), but after that someone writes a better proggy in normal pure C or C++ and have more options, is faster.
Microsoft we can bet will try to promote it, Vista will have it by default, but another question who will use Vista until not fully cracked with that DRM crap all inside, so only solution for me now i XP64, best system from msshit so far, fast stable if you know how to tweak it, and doesnt require you to have pixelshader 2.0 or 4.0 soon to draw window like Vista, and 2 TB of memory to just run system

Originally Posted by Human

[...] still is risc [...]

That's not right. RISC means "Reduced Instruction Set Computing". One of the most import things on RISC CPUs is that memory can only be access with "load" and "store" operation and no direct memory addressing is possible. We all know very well that this is neither true on x86 nor on x64 CPUs.

All x86 and x64 CPUs are CISC CPUs, meaning "Complex Instruction Set Computing".

Originally Posted by ssb

I agree that developing using .NET is a much faster and easier task than playing with C++ pointers and manual memory management. But that comes at a cost. I've ported some of my projects from C++ to C#, but I've noticed a huge performance hit, even with Ngen'ed .NET executables.
CLR as a library is a nice OO framework but I hate the VM/JIT idea. Consider how nice would be if CLR was a statically linked lib similar to MFC and C# a true native compiler able to compile and link true Win32/64 PE executables.

Personally I don't see the advantage you thought you would gain by going to the trouble of porting your existing code. Of course the .NET equivalents would be unlikely to match the same performance you had before.

Sure there is an argument to be made that under certain limited circumstances a JIT compiler can make more optimized decisions because it makes them based on information during runtime but overall we know it doesn't really compare to unmanged code at the moment.

Sure go ahead and start your new projects with it. That may add some gain through increased productivity. Port your old code? I just cant see the advantage to that unless you plan on still supporting the code 8-10 years down the line.

Do I personally hate .NET? Hell no. Personally I'm more of a Java/C++ programmer by expertise than a .NET one. However, barring a few niggly bits I don't like about C#, I still tend to prefer it for some jobs.

Try program any business application with it. I bet you I could do it to a much shorter time specification with very acceptable performance that still makes the customer pleased at the same time.

At the end of the day, the old cliche, 'time is money' still holds and the needs of your customer/user are the most important thing. Most of your users are not going to notice that your ListBox loads 100ms slower than an C++ implementation, they just accept it for what it does. However, they are going to notice it when you deliver it in half the time your competitors promised it.

Programming a game or real-time system? Well yes then a different principle applies....

The right tool for the right job is what holds true. As programmer just ensure that your are well versed in a few different languages and continually keep yourself up to date. That is essentially what you are paid for. Anyone can learn 'a language'. Yet not as many of them bother to learn a few more on top of that.

Its not that hard since most of the same paradigms tend to cross over several languages. Heck sometimes I find even a little Python amazingly usefull to whip up something really clever in a really short space of time.

Essentially what I'm saying from all this is that its a bit of a moot argument....it all depends on what you are trying to achieve.

well what i ment was that amd still behaves like old good pentium simple instructions are 1 clock only like risc, and amd is cisc, but its risc core that emulates cisc, at least that what i read long time ago, intel is pure cisc

Originally Posted by Human

amd is cisc, but its risc core that emulates cisc, at least that what i read long time ago, intel is pure cisc

AFAIK All new processors are built this way. cisc commands are fed to the the decoder and that device breaks down those commands into simple instructions (RISC?) and other blocks of processor work in that sipmplified "language". I mean there is no i386 commands in the pentium 4 (for example) except for decoder.

[Maximus]

Pentium family breaks up opetations in several microops (i.e. load/store/alu etc.), whereas AMD uses a 'reduced' microcode set. The microcode is (for all I know) hardwired in the dice.
Real differences come when one processor needs to execute 4 mops compared to the 2 of another...
The Pentium mobile is more based on p3 design than p4 on this point, as it uses bigger hardwired microops.

p1 wasn't 1op/1cycle really. An op usually took 6 cycles, and was sais it was executed in one cycle only because it was sent in the pipeline:

xxxxx1
 xxxxx1
  xxxxx1
12345|||

so, after the operation entered the pipe, no AGI, read-over-write and not other situations (i.e. U/V misleading), the op was executed in '1 cycle'.
AMD is faster than Px family for this reason, but it is more 'sensible' to first level cache misses due to the reduced pipeline.
I noted PM too uses an increased L1 cache for this, so I can only (wildly) guess the time loss for accessing L2 with a shorter pipe is much bigger (in %) than with a longer pipe.
Anyone knows more on the subject?