Board index » delphi » Re: Highlander question - Win32/.Net

Re: Highlander question - Win32/.Net


2007-08-31 03:10:41 PM
delphi232
Form editors are different in Delphi. In addition resource formats are
different: WinForms uses the standard .NET resources. VCL.NET uses .DFM
data.
You can propably mix them if you create component in code and do not use
IDE's form editor but that is not practical.
Jaakko
 
 

Re: Highlander question - Win32/.Net

Quote
1) The native code compiler isn't set properly for optimization.
2) The native code isn't optimized.
3) The native code compiler you use is from 60s. :)
4) .NET code uses a library assembly which is highly optimized compared with
its Native code equivalent.

My own tests with Delphi & C# shows that native Delphi code is much faster.
However, the speed issue is not simply a matter of head-to-head comparison
of compiler performances. .NET uses lots of assemblies that have a direct
effect on overall performance of the application. The best way of doing this
is to convert a complete CPU-hungry native code GUI application to .NET and
compare the overall performance.


If you've carefully read Joanna's link, there's only one explanation, and
you're right : the JIT compiler does a better optimization than the native
code compiler.
Saying .Net code is faster than Native code is a non-sense.
It's exactly like saying "Compiled VB(Visual Basic) programs may run faster than ASM
programs".
The only good explanation would be that the guy who did the FFT did such a
bad job that the JIT compiler optimized it better than the native code compiler.
My 2c
 

Re: Highlander question - Win32/.Net

Bob writes:
Quote
Markus.Humm writes:

>It would be faster if the just in time compiler would create better
>optimized code out of the .NET CLR code than the Delphi compiler out
>of the pas-code or if .NET provides some faster library routines than
>VCL.
>

Also, the JITer has the opportunity to optimize the compiled code for
the actual machine it is running on. I don't know if it actually does
this, but it is feasible. For example, a native x86 compiler needs to
keep machine code to the lowest common denominator. While a JITer can
take advantage of the fact that the current machine is a x64 (or some
other processor) and use more optimized machine code for that
processor.
This is a good point.
I know from my friends in the computer games industry that they will include
machine-specific variants for critical code (Integer FFT's being one of
them, or so I believe!) to take best advantage of the hardware.
--
Ed.
 

Re: Highlander question - Win32/.Net

Olivier Pons writes:
Quote
>1) The native code compiler isn't set properly for optimization.
>2) The native code isn't optimized.
>3) The native code compiler you use is from 60s. :)
>4) .NET code uses a library assembly which is highly optimized
>compared with its Native code equivalent.
>
>My own tests with Delphi & C# shows that native Delphi code is much
>faster. However, the speed issue is not simply a matter of
>head-to-head comparison of compiler performances. .NET uses lots of
>assemblies that have a direct effect on overall performance of the
>application. The best way of doing this is to convert a complete
>CPU-hungry native code GUI application to .NET and compare the
>overall performance.

If you've carefully read Joanna's link, there's only one explanation,
and you're right : the JIT compiler does a better optimization than
the native code compiler.
Saying .Net code is faster than Native code is a non-sense.
It's exactly like saying "Compiled VB(Visual Basic) programs may run faster than ASM
programs".
The only good explanation would be that the guy who did the FFT did
such a bad job that the JIT compiler optimized it better than the native
code compiler.
My 2c
It's not going to be the implementation of the FFT because the test used the
same code, with minimal and documented changes, so it certainly *feels* as
though the argument is going to boil down to the quality of the math code
libraries in use.
--
Ed.
 

Re: Highlander question - Win32/.Net

Bob Dawson writes:
Quote
Total strawman. Please cite a CodeGear statement based on that
assumption, or claiming that all w32 code will transition to .NET
effectively with a simple recompile.
Fishfact.
Quote
Nor did they simply recompile the VCL to produce the VCL.NET
themselves.
Sure. But VCL isn't a complete abstraction.
Quote
>I think her comments are accurate.

Of course they are. What I thought poorly done was your waving them
about as some sort of lost gospel that CodeGear doesn't know about.
You're entitled to your opinion.
Quote
>So it is a waste of time to put together a realistic/coherent
>argument.

Pity you think so. But cursing the darkness is your choice.
Why is it a pity? I have put together such arguments, but denial runs
deep. There has to be sufficient pain to change course and there hasn't
been yet.
I am less interested in Delphi each day; it would be
nice if I could have a renewed interest. But that is not really up to me.
Quote
>Right, so here's a rhetorical question: Why is CodeGear pursuing a
>.NET strategy that ignores the underlying understanding of the
>points Joanna just made?

Non rhetorical answer: I don't see that it is.
Of course you don't. I wouldn't expect you would.
Quote
>don't need a language that targets Win32 and .NET. That kind of
>programmer would simply pick the best tool for the job.

Since you seem unwilling to address the point of what shared elements
actually cost, I don't see you've earned any credit for the implicit
claim that one tool can not be best for both.
Shared elements are costly because the language must has constructs that
don't align with the runtime environment. For example, Garbage
Collection.
Theoretically it is possible that one tool is the best for both, however
in the case of Delphi, IMO, it is not.
Quote
The same piano that plays Mozart also plays Scott Joplin. Jean-Pierre
Rampal and Ian Anderson both specialize in the flute.
Those analogies are more appropriate for application domains, not
platforms. IOW, I can use Delphi Win32 to create a web application with
Intraweb, or I can build a GUI.
--
Brian Moelk
Brain Endeavor LLC
XXXX@XXXXX.COM
 

Re: Highlander question - Win32/.Net

Brian Moelk writes:
Quote
Bob Dawson writes:
>Which isn't an effective rhetorical stance--in fact to CodeGear it's
>probably rather insulting, rather than being persuasive.

They're the one pursuing a strategy that does the very thing Joanna
recommends against:

"Whatever facilities an IDE may provide, assuming that you can just
recompile a Win32 app to .NET is asking for problems."
That is actually already true if you port from, say, Delphi 7 to Delphi
2007, i.e. on the same platform. If you port, you must always be aware
of certain items.
My experience is that most of the code I have and had in Win32 could be
ported easily. Perhaps it is the way I write, and how I avoid certain
features and techniques (like PChars, Move, FillChar, building strings
using concatenation) wherever I can, I don't know. I had no great
difficulties with my code.
I can imagine that other code will be harder to port. I once tried to
see if I could port SynEdit to .NET, but it is so full of code that
uses PChars that I gave up. I was thinking of rewriting PChar as a
record type with operators (like some kind of iterator), but imagnined
that this would not make things faster. A complete rewrite using
strings, string builders and indices would have been required.
--
Rudy Velthuis [TeamB]
"What a cruel thing is war: to separate and destroy families and
friends, and mar the purest joys and happiness God has granted us
in this world; to fill our hearts with hatred instead of love for
our neighbors, and to devastate the fair face of this beautiful
world." -- Robert E. Lee, letter to his wife, 1864
 

Re: Highlander question - Win32/.Net

"Brian Moelk" wrote
Quote
Bob Dawson writes:
>Total strawman. Please cite a CodeGear statement based on that
>assumption, or claiming that all w32 code will transition to .NET
>effectively with a simple recompile.

Fishfact.
Fishfact showed that for a simple case, recompiling is possible (which it
is), and nothing more.
If you took the Fishfact demo seriously as a larger claim, you're the first
person I have ever met who did. You do realize that in this country auto
insurance is sold by talking lizards ...
Quote
Why is it a pity?
Because I think you have serious things to say that should at least be
listened to, and you insist on taking yourself out of play by copping an
attitude.
bobD
 

Re: Highlander question - Win32/.Net

Farshad writes:
Quote
Modern compilers like Delphi do a great job in optimiziation so there
must be very rare cases where a JIT compiler can produce better code.
AFAIK, Delphi does absolutely *no* optimization of floating point
expressions, so the JIT compiler could very well get an edge there...
Also, in .NET the Extended data type is gone, while it is still default
for all intermediate FP results in W32, so memory access times may
differ too.
--
Anders Isaksson, Sweden
BlockCAD: web.telia.com/~u16122508/proglego.htm
Gallery: web.telia.com/~u16122508/gallery/index.htm
 

Re: Highlander question - Win32/.Net

Bob Dawson writes:
Quote
If you took the Fishfact demo seriously as a larger claim, you're the first
person I have ever met who did.
I really don't, it was offered as an absurd example. The larger point
here is that the current Delphi for .NET strategy is one of code
migration/compatibility with Win32, which is problematic IMO.
Now, a cross platform strategy (not a cross runtime) will have similar
issues to resolve, but this actually makes a meaningful difference to
how customers deploy their applications: Windows, Linux, Mac.
The cross runtime strategy (defining Win32 as a "runtime") has just as
many issues to resolve, if not more, without a meaningful difference in
deployment: Windows vs. Windows.
Quote
>Why is it a pity?

Because I think you have serious things to say that should at least be
listened to,
Thanks; but I don't believe that I have been heard.
Not that I have any expectation of agreement or believe that if CodeGear
does not do the things I think they should means that I haven't been heard.
Quote
and you insist on taking yourself out of play by copping an
attitude.
I think Nick has made it clear that I am "out of play" regardless. The
attitude I have is born from heartbreak; I admit this particular thread
was more of a cheap shot than I normally take, so I will just bow out.
--
Brian Moelk
Brain Endeavor LLC
XXXX@XXXXX.COM
 

Re: Highlander question - Win32/.Net

Rudy Velthuis [TeamB] writes:
Quote
That is actually already true if you port from, say, Delphi 7 to Delphi
2007, i.e. on the same platform. If you port, you must always be aware
of certain items.
Yes, but to a far less degree. And, like all ports/migrations/updates,
there has to be a good enough reason to do so.
--
Brian Moelk
Brain Endeavor LLC
XXXX@XXXXX.COM
 

Re: Highlander question - Win32/.Net

Ed Weatherup writes:
Quote
Bob writes:
>Markus.Humm writes:
>
>>It would be faster if the just in time compiler would create better
>>optimized code out of the .NET CLR code than the Delphi compiler out
>>of the pas-code or if .NET provides some faster library routines than
>>VCL.
>>
>Also, the JITer has the opportunity to optimize the compiled code for
>the actual machine it is running on. I don't know if it actually does
>this, but it is feasible. For example, a native x86 compiler needs to
>keep machine code to the lowest common denominator. While a JITer can
>take advantage of the fact that the current machine is a x64 (or some
>other processor) and use more optimized machine code for that
>processor.

This is a good point.

I know from my friends in the computer games industry that they will include
machine-specific variants for critical code (Integer FFT's being one of
them, or so I believe!) to take best advantage of the hardware.

Also, the FastCode project (hence Delphi - at least in functions 'imported' from
them) uses this technique, AFAIK - so no .NET advantage here.
my 2c,
--
m. th.
 

Re: Highlander question - Win32/.Net

Jaakko Salmenius explained :
Quote
Form editors are different in Delphi. In addition resource formats are
different: WinForms uses the standard .NET resources. VCL.NET uses .DFM data.

You can propably mix them if you create component in code and do not use
IDE's form editor but that is not practical.

I was under the impression that it was fairly
easy to create wrappers for WinForm controls.
Thanks,
Brad.
 

Re: Highlander question - Win32/.Net

Bob laid this down on his screen :
Quote
Markus.Humm writes:

>It would be faster if the just in time compiler would create better
>optimized code out of the .NET CLR code than the Delphi compiler out
>of the pas-code or if .NET provides some faster library routines than
>VCL.
>

Also, the JITer has the opportunity to optimize the compiled code for
the actual machine it is running on. I don't know if it actually does
this, but it is feasible.
AFAIK, that has always been the plan and the
expectation, but they have never actually done it.
HTH,
Brad.
 

Re: Highlander question - Win32/.Net

Quote

I know from my friends in the computer games industry that they will include
machine-specific variants for critical code (Integer FFT's being one of
them, or so I believe!) to take best advantage of the hardware.

Isn't that exactly what .NET does?