Re: What Delphi users really want (other than bugfixes)
From: Eric Grange (egrangeNO_at_SPAMglscene.org)
Date: 08/31/04
- Next message: Brion L. Webster: "Re: Delphi Survey for BorCon attendees."
- Previous message: Alan Garny: "Re: Version control"
- In reply to: Kevin: "Re: What Delphi users really want (other than bugfixes)"
- Next in thread: Craig Stuntz [TeamB]: "Re: What Delphi users really want (other than bugfixes)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 31 Aug 2004 18:26:14 +0200
> Maybe you can't directly access SIMD from .NET code but what do you make
> of this:
Still waiting for any of that "JIT-only optimization" to happen
in the real world and have it beat an AOT compiler... not that
this wouldn't be theoretically impossible... just quite anti-JIT
philosophy, given that modern C/C++ compilers f.i. can do
whole-application optimizations.
> * Processor-Specific Optimizations— At run time, the JIT knows
> whether or not it can make use of SSE or 3DNow instructions.
Yes, it knows it, but just doesn't (can't?) come up with anything
useful out of it (or maybe in hyper-specific cases noone has ever
seen?).
Reason: base data types do not map to SSE or 3DNow! types.
As long as you don't have support for 2-4 floats vector types
(and matrix), right there in the language alongside integer
or classic float type, compiler can't use SIMD efficiently,
because code won't be layed out in a way that would make it
efficient.
> * Your executable will be compiled specially for P4, Athlon or
> any future processor families. You deploy once, and the same
> code will improve along with the JIT and the user's machine.
I would be more impressed if the JIT was able to overtake ye olde
Delphi compiler codegen ;)
We're speaking of 2004 technology failing to edge what is essentially
a 386-era compiler with no instruction scheduling, no support for
Pentium instructions, local optimizations only, no inlining support,
archaic FPU codegen, etc.
Somehow, I can't reconcile the inferior performance of the JIT codegens
given their superior optimization support list...
So, I don't have much faith in promises of "superior optimization"
when it comes from the same people that made a JIT codegen that
can generate such an hideous ASM as the .Net JIT does (just look
at calls and how they are implemented)... seems
to be quite a different team than the one behind VC++ compiler f.i.,
and the words they use don't carry the same weight/meaning.
Maybe it's a case of over-optimizing the transmission and chassis
but forgetting about tyres and engine.
> I compared Delphi binaries to C# .NET binaries and the .NET code
> ran twice as fast.
Please post samples, should such a case exist, it could make
it a world's first! ;)
> I could come to was that .NET was doing something like SIMD to accomplish
> the same thing. I could be wrong [..]
I'm pretty sure it is not using SIMD, at best it will use scalar SSE2
on P4 and A64, but that's about it: ie. use SSE2 to manipulate one
value at a time, but unable to use it to add two values at a time.
Eric
- Next message: Brion L. Webster: "Re: Delphi Survey for BorCon attendees."
- Previous message: Alan Garny: "Re: Version control"
- In reply to: Kevin: "Re: What Delphi users really want (other than bugfixes)"
- Next in thread: Craig Stuntz [TeamB]: "Re: What Delphi users really want (other than bugfixes)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|