Discussion:
Eric's floating point test
(too old to reply)
Tim Anderson
2003-12-29 13:37:24 UTC
Permalink
Did some playing around with this.

Sorry, my tests were in C# as I'm more concerned at the moment with .Net
perf rather than D8 perf; but it is all relevant.

First result: D8 about 39K ticks, C# about 6.5K ticks. Suggests some
specific Delphi problem here.

Now some experiments.

Point 1: .Net always allocates arrays on the heap. Stack is quicker. So
instead of arrays I used a struct with 16 float members:

struct TStackMatrix
{

public float XW;

public float XX;

public float XY;

etc;

Result: C# about 2.5K ticks. A lot faster.

Note I'm not saying you should do arrays like this. However, it's one thing
to say ".Net is slow", another thing to say, ".Net arrays are slow because
they are allocated on the heap".

Point 2: Use a procedure instead of a function, passing the result variable
by reference.

Result: C# about 1K ticks. About twice as fast again.

Point 3: Delphi 7 has an optimizer. Do we know how it is optimizing this
code? Well, it can be tested by decompiling the exe. But it's interesting to
turn D7's optimizer off.

Result: D7 about 1.7K ticks. Now slower than C#.

If I have time, I'll poke about with the D8 code too.

Tim
Borland execs speak:
http://www.itwriting.com/borlandtop.php
Eric Grange
2003-12-29 14:07:42 UTC
Permalink
Post by Tim Anderson
First result: D8 about 39K ticks, C# about 6.5K ticks. Suggests some
specific Delphi problem here.
Indeed... Would it be possible to post the relevant bits for the
generated output of D8FDN & C#? (IL assembly stuff)
Post by Tim Anderson
Note I'm not saying you should do arrays like this. However, it's one thing
to say ".Net is slow", another thing to say, ".Net arrays are slow because
they are allocated on the heap".
But isn't it like saying that a rusty Ford truck can go almost as fast -if not
faster- than a Ferrari, when dropped into a straight fall from a high enough
altitude? ;)

Quick note for those missed the first episode: D7 with compiler optimization
is about 0.65k ticks (wild guess based on your initial .net tick count),
and at that level, D7 still has some reserve (asm code variant isn't used).

Eric
Eric Grange
2003-12-29 14:22:13 UTC
Permalink
Actually about .82k ticks here. Not a bad guess though :-)
hmmm... then I'll make another guess: CPU is a P4? ;)

Eric
Tim Anderson
2003-12-29 14:30:46 UTC
Permalink
Post by Eric Grange
Actually about .82k ticks here. Not a bad guess though :-)
hmmm... then I'll make another guess: CPU is a P4? ;)
Spot on - P4 2.0 Ghz

Tim
Tim Anderson
2003-12-29 14:10:00 UTC
Permalink
Post by Eric Grange
Post by Tim Anderson
First result: D8 about 39K ticks, C# about 6.5K ticks. Suggests some
specific Delphi problem here.
Indeed... Would it be possible to post the relevant bits for the
generated output of D8FDN & C#? (IL assembly stuff)
Sure, I'll do this later.
Post by Eric Grange
Post by Tim Anderson
Note I'm not saying you should do arrays like this. However, it's one thing
to say ".Net is slow", another thing to say, ".Net arrays are slow because
they are allocated on the heap".
But isn't it like saying that a rusty Ford truck can go almost as fast -if not
faster- than a Ferrari, when dropped into a straight fall from a high enough
altitude? ;)
Not really. It's more a matter of knowing the strengths and weaknesses of
your tools.
Post by Eric Grange
Quick note for those missed the first episode: D7 with compiler optimization
is about 0.65k ticks (wild guess based on your initial .net tick count),
and at that level, D7 still has some reserve (asm code variant isn't used).
Actually about .82k ticks here. Not a bad guess though :-)

Tim
Tim Anderson
2003-12-29 15:13:00 UTC
Permalink
Post by Eric Grange
Indeed... Would it be possible to post the relevant bits for the
generated output of D8FDN & C#? (IL assembly stuff)
I've posted my sample to:

http://www.itwriting.com/csharptest.zip

This is a Visual Studio project but includes the exe so you don't need to
have VS.

Note that (for some reason) the code runs slower within the VS IDE. So run
it outside the IDE to make comparisons.

Tim
Borland execs speak:
http://www.itwriting.com/borlandtop.php
Eric Grange
2003-12-29 15:51:46 UTC
Permalink
Btw, I don't think it was necessary to go to such length
to keep the same matrix initialization for the struct ;)
But then again, it shows how annoying it can get to have
to use a struct in that case :)

Eric
Tim Anderson
2003-12-29 15:58:25 UTC
Permalink
15700, 4700 and 761 respectively, ie. it starts quite slower
than your P4, but ends faster... (D7 is at 561 on that machine,
it's an AXP 2200+, same clock speed as the 2500+ but smaller
CPU cache).
This may be my fault. I started down a different track (trying to reproduce
TVector and TMatrix) and I no longer have the code that gave the 6.5k ticks.
With the code I posted, I get a figure close to yours.
That 761 figure looks good enough performance-wise (compares
not-so-unfavourably with 450 on D7 w/ASM), however, it comes
at quite a hefty price: having to manually unroll loops and arrays.
The point is that .Net is pretty much as good at multiplying as other
compilers.

It's obviously more restrictive than D7 when it comes to perf. tweaking.
Anyway, I guess that unless Borland fix their copy real quick,
they are bound for a very rough ride in the .net world if such
a performance ratio vs C# gets confirmed in other areas as well.
Too soon to make a judgment on this. For all I know it may be faster in some
other test.

Tim
Eric Grange
2003-12-29 17:57:22 UTC
Permalink
ok :)
Post by Tim Anderson
The point is that .Net is pretty much as good at multiplying as other
compilers.
Still gets a two-to-one ratio. Not catastrophic, but not stellar either.
More of worry is that if you're not careful, you can easily end up with
utterly catastrophic results.
The "best" .net solution isn't far from what can be called hacking,
just too many language features have to be sacrificed.

Eric
Tim Anderson
2003-12-29 18:02:36 UTC
Permalink
Post by Eric Grange
Post by Tim Anderson
The point is that .Net is pretty much as good at multiplying as other
compilers.
Still gets a two-to-one ratio. Not catastrophic, but not stellar either.
None of the changes I made change the number of multiplication operations.
So I think you should take the best figure, which is more like 1.5 to 1.
Then again, as I mentioned, we don't know what the D7 optimizer is doing.
Post by Eric Grange
More of worry is that if you're not careful, you can easily end up with
utterly catastrophic results.
Agreed. On the other hand, not all performance issues actually matter. The
answer is in profiling and optimizing the bottlenecks.
Post by Eric Grange
The "best" .net solution isn't far from what can be called hacking,
just too many language features have to be sacrificed.
Well, do many apps have loops with 10 million iterations? I realize that
*some* do. But these are exactly the areas that merit very careful
attention.

Tim
Eric Grange
2003-12-30 08:26:32 UTC
Permalink
Post by Tim Anderson
None of the changes I made change the number of multiplication operations.
So I think you should take the best figure, which is more like 1.5 to 1.
If you compare C#'s best, then compare it to D7's best, which is the asm
version, which is that extra bit faster (on in more "streaming" situation,
its performance is better than what this benchmark shows).
Post by Tim Anderson
The answer is in profiling and optimizing the bottlenecks.
Which is a pure waste of time. If the language/compiler can generate good
enough code most of time, out of simple code, all the better.
There are enough REAL bottlenecks without having to worry about artificial
ones introduced by compiler/framework deficiencies.
Post by Tim Anderson
Well, do many apps have loops with 10 million iterations?
Very simple, 60 FPS, a dozen of meshes with ten thousandth of vertices
each, and here you are. Not a particularly heavy situation.
You can always use tricks to delay computations over several frames,
use partition schemes, etc. But all these come at a complexity cost,
make your code more tied to a particulat hardware situation, and at
some point, you still have to perform them, and they are far from being
the only things you have to worry about, actually, quite often the least
of them. With D8 performance levels, they suddenly become a glaring
issue with no elegant solution.

Eric
Tim Anderson
2003-12-30 09:49:33 UTC
Permalink
Post by Eric Grange
Post by Tim Anderson
None of the changes I made change the number of multiplication operations.
So I think you should take the best figure, which is more like 1.5 to 1.
If you compare C#'s best, then compare it to D7's best, which is the asm
version, which is that extra bit faster (on in more "streaming" situation,
its performance is better than what this benchmark shows).
If you need the perf. of asm you should not use a .Net app. Use native code.

Or do the perf. intensive calc in an external dll an PInvoke.
Post by Eric Grange
Post by Tim Anderson
The answer is in profiling and optimizing the bottlenecks.
Which is a pure waste of time.
Can't agree here.
Post by Eric Grange
If the language/compiler can generate good
enough code most of time, out of simple code, all the better.
There are enough REAL bottlenecks without having to worry about artificial
ones introduced by compiler/framework deficiencies.
That's misleading. All compilers and frameworks have different
characteristics. You should try to get the best from your tools.
Post by Eric Grange
Post by Tim Anderson
Well, do many apps have loops with 10 million iterations?
Very simple, 60 FPS, a dozen of meshes with ten thousandth of vertices
each, and here you are. Not a particularly heavy situation.
As I said, some apps do. But is it a minority. You have choices. .Net isn't
the right choice for every scenario. Note there is managed Dx too.
Post by Eric Grange
You can always use tricks to delay computations over several frames,
use partition schemes, etc. But all these come at a complexity cost,
make your code more tied to a particulat hardware situation
Not like the asm you were commending then :-))
Post by Eric Grange
of them. With D8 performance levels, they suddenly become a glaring
issue with no elegant solution.
You are drawing a generalised conclusion from a very specific instance.

Tim
Eric Grange
2003-12-30 10:27:24 UTC
Permalink
Post by Tim Anderson
If you need the perf. of asm you should not use a .Net app. Use native code.
That's all it is about, being able to use native code in future Delphi
version, just like C++ users can. They have choice of .net AND native
(incl. native Win64).
Post by Tim Anderson
Or do the perf. intensive calc in an external dll an PInvoke.
Which is slow.
Post by Tim Anderson
Post by Eric Grange
Post by Tim Anderson
The answer is in profiling and optimizing the bottlenecks.
Which is a pure waste of time.
Can't agree here.
Proper algorithms and datastructures are much better tools
if you're after efficiency.
Post by Tim Anderson
That's misleading. All compilers and frameworks have different
characteristics. You should try to get the best from your tools.
Not really. If you have to sacrifice language features to get
efficiency, it's a clear sign of a design flaw in the language.

I don't know about you, but what I'm after in a development tool
is for it to take care of trivial issues, not to end up having
to manually unroll loops or outlaw arrays.
Post by Tim Anderson
Not like the asm you were commending then :-))
You may be surprised to learn that this ASM code survived all new
Delphi versions with zero change (it dates from K6 days), while other
higher level parts required changes: IDE experts, DataBase connectivity,
multithreading, forms using some "standard" VCL components and
variant-based code come to mind. For some of them, quite heavy changes.
Post by Tim Anderson
You are drawing a generalised conclusion from a very specific instance.
The issue has been found with integer computations too, and some time
ago, string manipulations. If you also look at the overall sluggishness
of .net GUIs and their overblown memory consumption, there isn't much
room left for hope. ;)
Maybe the v2.0 will be better, but the v1.1 just isn't efficient.
I mean, come on! I don't remember seeing the form designer repaint
itself, but with C#Builder, this is plain obvious, and from various
comments, D8FDN is no better. (is that why Borland forced the
"edit a single form at a time" down out throats, because having
several being edited at a time would bring the IDE to its knees?)

Eric
Tim Anderson
2003-12-30 10:57:56 UTC
Permalink
Post by Eric Grange
Post by Tim Anderson
Or do the perf. intensive calc in an external dll an PInvoke.
Which is slow.
Compared to what? There's certainly a performance cost but nevertheless
PInvoke is very fast. If you PInvoke within a 10 million iteration loop, you
have made a mistake. If you PInvoke once and do your 10 million externally
you could get a big gain.
Post by Eric Grange
Post by Tim Anderson
Post by Eric Grange
Post by Tim Anderson
The answer is in profiling and optimizing the bottlenecks.
Which is a pure waste of time.
Can't agree here.
Proper algorithms and datastructures are much better tools
if you're after efficiency.
Which you derive in part through profiling, unless you are a perfect coder
of course.
Post by Eric Grange
Post by Tim Anderson
That's misleading. All compilers and frameworks have different
characteristics. You should try to get the best from your tools.
Not really. If you have to sacrifice language features to get
efficiency, it's a clear sign of a design flaw in the language.
Don't agree. Eg. variants are slow, but can be useful (they are in D7 too).
Post by Eric Grange
You may be surprised to learn that this ASM code survived all new
Delphi versions with zero change (it dates from K6 days)
That doesn't surprise me, but it is still platform-specific.
Post by Eric Grange
Post by Tim Anderson
You are drawing a generalised conclusion from a very specific instance.
The issue has been found with integer computations too, and some time
ago, string manipulations.
Not aware of any problems with integer computations (and as we discovered,
there isn't a problem with float calc either). Not sure about string
manipulation, but certainly how you code this makes a big difference.
Post by Eric Grange
If you also look at the overall sluggishness
of .net GUIs and their overblown memory consumption, there isn't much
room left for hope. ;)
Much of this is down to slow GDI+ performance. But I don't mean to get into
a huge debate about all the characteristics of .Net here. I would freely
agree that it isn't the best tool for every project. However, neither is it
the slow thing that some make out. To my mind .Net has many useful features
and these need to be balanced against areas of compromise.

Tim
Eric Grange
2003-12-30 11:39:37 UTC
Permalink
[...] If you PInvoke once and do your 10 million externally
you could get a big gain.
In which case you're just using .net as a front-end.
Which you derive in part through profiling, unless you are
a perfect coder of course.
Typically no, because it's too late to change your structures.
So in practice all you can do is patch'n hack, or start from
scratch.
Don't agree. Eg. variants are slow, but can be useful (they are in D7 too).
That misses the point. If two languages A and B offer the same features,
but for one of for B the feature collapses under pressure, it is perfectly
correct to consider the implementation of that feature by B is flawed.
In our particular case, it is even more correct since B has no feature
that A hasn't.
That doesn't surprise me, but it is still platform-specific.
Not really, it runs under Linux too.
.net is quite tied to the MS Platform (and will probably remain so).
Not aware of any problems with integer computations (and as we discovered,
there isn't a problem with float calc either).
I don't see your point. Sooner or later, the calc happens on the CPU,
so what, we should be happy that .net doesn't use an FPU emulator?
That still doesn't solve the fact that the compiler places garbage
and redundance around the useful bits, and measuring the amount of
useless stuff around the useful stuff has always been what differentiates
compilers.
Not sure about string manipulation, but certainly how you code this makes
a big difference.
Just concatenate, cut, search and use functions that return strings
(procedure trick also works for strings...)
Much of this is down to slow GDI+ performance.
No one forced MS or Borland to promote GDI+, it was their choice. ;)

Eric
Tim Anderson
2003-12-30 11:51:14 UTC
Permalink
Post by Eric Grange
[...] If you PInvoke once and do your 10 million externally
you could get a big gain.
In which case you're just using .net as a front-end.
If you like. You may have all your code in .Net except this small part.
Post by Eric Grange
Which you derive in part through profiling, unless you are
a perfect coder of course.
Typically no, because it's too late to change your structures.
So in practice all you can do is patch'n hack, or start from
scratch.
You said "algorithms and datastructures".
Post by Eric Grange
That misses the point. If two languages A and B offer the same features,
but for one of for B the feature collapses under pressure, it is perfectly
correct to consider the implementation of that feature by B is flawed.
In our particular case, it is even more correct since B has no feature
that A hasn't.
?? I don't follow you here. Are you saying D7 has all the features of .Net?
It does not.

Further, I don't see how you can progress from "feature B is slower" to
"feature B collapses under pressure". Different.
Post by Eric Grange
Not really, it runs under Linux too.
On PowerPC? Sparc? PocketPC?
Post by Eric Grange
.net is quite tied to the MS Platform (and will probably remain so).
I've not argued otherwise (though there is Mono).
Post by Eric Grange
Not aware of any problems with integer computations (and as we discovered,
there isn't a problem with float calc either).
I don't see your point.
Point is that .Net does these functions nearly as fast as native code.
Post by Eric Grange
Much of this is down to slow GDI+ performance.
No one forced MS or Borland to promote GDI+, it was their choice. ;)
I agree. Microsoft should have done more to make Windows Forms perform well.
More effort was put into ASP.Net. OTOH Microsoft is trying to move away from
Windows Forms (and accelerated GDI+ will come) so the problem will reduce
over time.

Tim
Will DeWitt Jr.
2003-12-30 11:48:44 UTC
Permalink
Post by Tim Anderson
Post by Eric Grange
Not really, it runs under Linux too.
On PowerPC? Sparc? PocketPC?
I can't help myself here, so forgive me. But maybe you've missed the
past decade and a half-- Microsoft software has always run almost
exclusively on x86-based systems. Alpha support was available for NT
but the percentage of users running an Alpha-based system was
miniscule. There's an Itanium release of Windows 2000 (and I think
XP), but again, very small percentage of the actual people running
Windows uses either of those platforms. Now there's AMD x86-64, which
provides full backwards compatibility with IA-32.

My question now is, what does it matter if the code doesn't run on
PowerPC, Sparc or PocketPC? Those platforms are irrelevant and
represent a minor fraction of the Microsoft Windows market.

Will
Tim Anderson
2003-12-30 14:05:01 UTC
Permalink
Post by Will DeWitt Jr.
My question now is, what does it matter if the code doesn't run on
PowerPC, Sparc or PocketPC? Those platforms are irrelevant and
represent a minor fraction of the Microsoft Windows market.
Will, I agree with you (except for PocketPC). Read the thread to understand
why I made the point I did.

Tim
Eric Grange
2003-12-30 13:16:45 UTC
Permalink
Post by Tim Anderson
?? I don't follow you here. Are you saying D7 has all the features of .Net?
It does not.
Apart for the security stuff, D7 actually has more.
.Net has promises of multiplatform, but they are yet undelivered.

However, I war rather referring to the C# vs D8FDN difference there,
and the overall .net arrays vs normal arrays. Your testing essentially
show that arrays under .net are much slower than structure access.
Post by Tim Anderson
Further, I don't see how you can progress from "feature B is slower" to
"feature B collapses under pressure". Different.
Not that much. Something that is slow but rarely used isn't an issue,
but if when used a lot, it becomes a major performance issue on its own,
that's what I call a collapse.
Post by Tim Anderson
On PowerPC? Sparc? PocketPC?
.net doesn't really run on the first two (probably never will on the 2nd),
and is quite limited to emulation on the third.
Using an x86 emulator (ala Bochs), I can have my code run on the three ;)

The real underlying issue however, is that as in stands, I'm 100% convinced
optimizing for the existing .net Framework (at the language level) is a pure
waste of time, since all those optimizations will be obsoleted or become
slowdown-inducing in the next Framework version.
There *are* performance issues, MS is perfectly aware of them, I have no
doubt about it, and they'll deal with them, you can be sure of it.
But the optimizations of today won't be those of tomorrow, you can be sure
of that too (cf. the DirectX saga).
Post by Tim Anderson
Point is that .Net does these functions nearly as fast as native code.
So does GW-BASIC ;). But just like GW-BASIC, there is so much useless stuff
happening around the useful bits that it hardly matters.
Post by Tim Anderson
I agree. Microsoft should have done more to make Windows Forms perform well.
More effort was put into ASP.Net. OTOH Microsoft is trying to move away from
Windows Forms (and accelerated GDI+ will come) so the problem will reduce
over time.
Yes, I completely fail to see the reason why MS didn't use .net as an
abstraction layer. They could then just have provided "drivers" that
could have used existing GUI technology and avoided the performance issue.
Their 'clean-break' only resulted in bunch of legacy "dead-code" even
before .net became mainstream.

Eric
Tim Anderson
2003-12-30 14:09:54 UTC
Permalink
Post by Eric Grange
Post by Tim Anderson
?? I don't follow you here. Are you saying D7 has all the features of .Net?
It does not.
Apart for the security stuff, D7 actually has more.
see http://www.gotdotnet.com
Post by Eric Grange
However, I war rather referring to the C# vs D8FDN difference there,
and the overall .net arrays vs normal arrays. Your testing essentially
show that arrays under .net are much slower than structure access.
Exactly so.
Post by Eric Grange
Post by Tim Anderson
Point is that .Net does these functions nearly as fast as native code.
So does GW-BASIC ;). But just like GW-BASIC, there is so much useless stuff
happening around the useful bits that it hardly matters.
GW-BASIC is interpreted IIRC. .Net is compiled. So I doubt your statement is
correct. But I don't intend to run up a sample :-)

Tim
Eric Grange
2003-12-30 14:49:52 UTC
Permalink
Post by Tim Anderson
GW-BASIC is interpreted IIRC. .Net is compiled.
Doesn't matter, GW-BASIC used the FPU for its multiplication so it's
as fast as .net on this aspect. And as for .net being "compiled",
that didn't seem to serve D8FDN very well, proof if there was need
that it's possible to have compilers that are inferior to interpreters.

Eric
Tim Anderson
2003-12-30 15:36:20 UTC
Permalink
Post by Eric Grange
Post by Tim Anderson
GW-BASIC is interpreted IIRC. .Net is compiled.
Doesn't matter, GW-BASIC used the FPU for its multiplication so it's
as fast as .net on this aspect.
I'll be interested to see your sample code.
Post by Eric Grange
And as for .net being "compiled",
that didn't seem to serve D8FDN very well, proof if there was need
that it's possible to have compilers that are inferior to interpreters.
That interpreters can be better is well known, for certain operations.

Tim
Mark E.
2003-12-30 16:24:47 UTC
Permalink
Post by Eric Grange
Post by Tim Anderson
GW-BASIC is interpreted IIRC. .Net is compiled.
Doesn't matter, GW-BASIC used the FPU for its multiplication so it's
as fast as .net on this aspect. And as for .net being "compiled",
that didn't seem to serve D8FDN very well, proof if there was need
that it's possible to have compilers that are inferior to interpreters.
I think D8FDN suffers from a different type of problem. The .NET
Framework doesn't have native support for global procedures/functions.
Like Java, they must be methods of a class. The standard way to do this
is to define a class and define class methods so you can execute the
calls without instantiating any classes. Anyway, because D8 had backward
compatibility high on the list, they did some non-standard things. A
Delphi Unit is created as a .NET class. Then it can have global
functions and variables because they are actually members of the class.

This means that Delphi For .NET does not create code that looks nice
when taken to another .NET language. If you compile to IL and reflect
back to C# or VB it looks funny.

The point is that the IL that the Delphi compiler creates *may* (don't
know myself) be creating inefficient IL in the name of backward
compatibility.

-Mark E.
Per Larsen
2003-12-31 13:04:38 UTC
Permalink
Post by Mark E.
I think D8FDN suffers from a different type of problem. The .NET
Framework doesn't have native support for global procedures/functions.
That's only conceptually true. Technically, a static method in .NET is
identical to a global method in native code.

- Per
Frank Andreas de Groot
2003-12-30 14:58:47 UTC
Permalink
Post by Tim Anderson
GW-BASIC is interpreted IIRC. .Net is compiled.
Nonsense.
.net code is interpreted, but the resulting assembly code is cached.
Many BASIC interpreters had this feature 2 decades ago.
Tim Anderson
2003-12-30 15:31:31 UTC
Permalink
Post by Frank Andreas de Groot
Post by Tim Anderson
GW-BASIC is interpreted IIRC. .Net is compiled.
Nonsense.
.net code is interpreted, but the resulting assembly code is cached.
Many BASIC interpreters had this feature 2 decades ago.
By your logic I suppose all languages are interpreted. It is just a matter
of when you compile and when you cache.

Tim
Mark E.
2003-12-30 16:51:13 UTC
Permalink
Post by Tim Anderson
By your logic I suppose all languages are interpreted. It is just a matter
of when you compile and when you cache.
Compiling at run-time is insane.
There is no possibility to optimize, simply because there is no time to do that.
What? It sounds like you are implying that the compile happens at
runtime every time. This is not true. It is compiled to IL when you
compile from the IDE. Then the JIT compiles it to native machine code
when execute the FIRST time. That native code is cached as used
ever-after. It doesn't take as long as you would think either. All the
hard compiliation is done getting it to IL.

Furthermore the runtime can observe how the program is being used and
*change* the compiled exe to optimize for performance. This is a feature
in both Java and .NET. This means you app has the potential to get
faster the more it is used. Other native compiled apps can't do this.
This is why Java & .net applications have such a limited use, they can only be
used for database and web-type applications.
False. Granted, you can't use it for ALL application types but you
overly constrain them.

-Mark E.
Frank Andreas de Groot
2003-12-30 16:58:17 UTC
Permalink
Post by Mark E.
Furthermore the runtime can observe how the program is being used and
*change* the compiled exe to optimize for performance. This is a feature
in both Java and .NET. This means you app has the potential to get
faster the more it is used. Other native compiled apps can't do this.
This is why Java and .net is very much slower than native exe's?
Due to all this wonderful cool technology?
Don't make me laugh. It's crap and it will always remain crap.
Rudy Velthuis (TeamB)
2003-12-30 17:50:30 UTC
Permalink
Post by Frank Andreas de Groot
Post by Mark E.
Furthermore the runtime can observe how the program is being used and
change the compiled exe to optimize for performance. This is a feature
in both Java and .NET. This means you app has the potential to get
faster the more it is used. Other native compiled apps can't do this.
This is why Java and .net is very much slower than native exe's?
It isn't.
--
Rudy Velthuis (TeamB)

"A picture is worth a thousand words (which is why it takes a thousand
times longer to load...)" -- Eric Tilton, Composing Good HTML
Marco Caspers
2003-12-31 12:15:20 UTC
Permalink
[snip]
Post by Rudy Velthuis (TeamB)
Post by Frank Andreas de Groot
This is why Java and .net is very much slower than native exe's?
It isn't.
<<<<<<<

In regards to this thread it is. A factor 8-60 slower..
Rudy Velthuis (TeamB)
2003-12-31 12:53:03 UTC
Permalink
Post by Marco Caspers
[snip]
Post by Rudy Velthuis (TeamB)
Post by Frank Andreas de Groot
This is why Java and .net is very much slower than native exe's?
It isn't.
<<<<<<<
In regards to this thread it is. A factor 8-60 slower..
Show me your code.
--
Rudy Velthuis (TeamB)

"Politics is the art of looking for trouble, finding it everywhere,
diagnosing it incorrectly, and applying the wrong remedies."
-- Groucho Marx
Marco Caspers
2004-01-02 09:32:40 UTC
Permalink
Post by Rudy Velthuis (TeamB)
Show me your code.
It's not my code, but it was posted at some point in this thread or the
previous one that spawned this one..
Rudy Velthuis (TeamB)
2004-01-02 10:37:46 UTC
Permalink
Post by Marco Caspers
Post by Rudy Velthuis (TeamB)
Show me your code.
It's not my code, but it was posted at some point in this thread or the
previous one that spawned this one..
Oh, I tweaked it a bit, and got it down to differences like 20% slower,
instead of a few hundred to thousand percent.
--
Rudy Velthuis (TeamB)

"Don't let it end like this. Tell them I said something." - Pancho
Villa, dying words.
Mark E.
2003-12-31 14:18:13 UTC
Permalink
Marco Caspers wrote:
[...]
Post by Marco Caspers
In regards to this thread it is. A factor 8-60 slower..
Actaully, in regards to this thread it is more like 5%-10% slower.

And I think that can still be improved.

-Mark E.
Eric Grange
2003-12-31 14:25:15 UTC
Permalink
Post by Mark E.
Actaully, in regards to this thread it is more like 5%-10% slower.
No, the best achievement was using C#, and was 50% slower than
the D7 version compiled with optimization on (but not the handwritten
asm, in which case the ratio is closer to 1 to 2, in favor of D7).
D8FDN best case was reported as 6-8 times slower than D7.

The 5%-10% was between C#'s best and D7 with optimization *off* IIRC.

Noteworthy is that C#'s initial is 4x D8FDN's initial, and that C#'s best
required to forfeits array and function.

Eric
Rudy Velthuis (TeamB)
2003-12-31 13:51:53 UTC
Permalink
Post by Eric Grange
Post by Mark E.
Actaully, in regards to this thread it is more like 5%-10% slower.
No, the best achievement was using C#, and was 50% slower than
the D7 version compiled with optimization on (but not the handwritten
asm, in which case the ratio is closer to 1 to 2, in favor of D7).
D8FDN best case was reported as 6-8 times slower than D7.
The 5%-10% was between C#'s best and D7 with optimization off IIRC.
Noteworthy is that C#'s initial is 4x D8FDN's initial, and that C#'s
best required to forfeits array and function.
I am going to try them all, now.
--
Rudy Velthuis (TeamB)

"Giving birth is like taking your lower lip and forcing it over
your head." - Carol Burnett.
Eric Grange
2003-12-31 15:14:57 UTC
Permalink
Post by Rudy Velthuis (TeamB)
I am going to try them all, now.
IMHO the most annoying point, if confirmed, is the performance
delta with equivalent C# code (can't confirm directly myself,
don't have D8FDN).
The perf delta between fields & arrays is also quite annoying,
these are static arrays, accessed in this particular case with
constant indices, meaning that all range checks can and should
happen at compile-time (if only to report errors).

Btw, does D8 reports an error at compile time (like D7 does)
if you attempt to access for instance the non-existing item [5, 5]
in the matrix? (as clue the range checks are at least made at
compile-time, if not used to simplify the compiled output).

Eric
Martin Waldenburg
2003-12-31 15:17:23 UTC
Permalink
Post by Eric Grange
The 5%-10% was between C#'s best and D7 with optimization *off* IIRC.
You seem to have serious problems to understand English.

Martin
Eric Grange
2003-12-31 16:01:58 UTC
Permalink
When you'll be done snipping, maybe you could try for yourself
on your machine, then contribute your results? hmm?
Would contribute more to the debate than guesstimates about
things being marginally slower or faster because the marketing
droid told so.

Eric
Martin Waldenburg
2003-12-31 16:07:36 UTC
Permalink
My results have been verified by Tim Anderson.
I compile always with optimization ON.

Martin
Eric Grange
2003-12-31 16:09:34 UTC
Permalink
And your results are...? (figures)

Eric
Martin Waldenburg
2003-12-31 16:12:07 UTC
Permalink
Post by Eric Grange
And your results are...?
marginaly differences.

Martin
Eric Grange
2003-12-31 16:15:23 UTC
Permalink
Post by Martin Waldenburg
marginaly differences.
Figures = numbers for the different cases = number of ticks
The only figures Tim posted showed otherwise, so please,
post yours if you have them. Compiled exe would be great too,
to let people try for themselves and eliminate machine-specific
issues.

Eric
Martin Waldenburg
2003-12-31 19:06:48 UTC
Permalink
Post by Eric Grange
Figures = numbers for the different cases = number of ticks
although that specific part of Borlands license
is null and void under German law I don't intend
to violate it.

Martin
Mark E
2004-01-01 05:38:34 UTC
Permalink
Post by Martin Waldenburg
Post by Eric Grange
Figures = numbers for the different cases = number of ticks
although that specific part of Borlands license
is null and void under German law I don't intend
to violate it.
I respect that you feel this way. Perhaps you could send them directly
to Eric with an agreement from him that he won't publish them?

As I recall, the license is that benchmarks can't be published.

Also, I don't think it a violation if you provide the source code that
can be run to derive a personal benchmark. You are not providing the
results or a conclusion, you only provide the means for an individual to
compare for themselves.

-Mark E.
chrisC
2003-12-30 19:21:06 UTC
Permalink
Frank...
Free your mind. You're on one-track.

Chris
Post by Frank Andreas de Groot
Post by Mark E.
Furthermore the runtime can observe how the program is being used and
*change* the compiled exe to optimize for performance. This is a feature
in both Java and .NET. This means you app has the potential to get
faster the more it is used. Other native compiled apps can't do this.
This is why Java and .net is very much slower than native exe's?
Due to all this wonderful cool technology?
Don't make me laugh. It's crap and it will always remain crap.
Per Larsen
2003-12-31 13:13:43 UTC
Permalink
Post by Mark E.
What? It sounds like you are implying that the compile happens at
runtime every time. This is not true. It is compiled to IL when you
compile from the IDE. Then the JIT compiles it to native machine code
when execute the FIRST time. That native code is cached as used
ever-after.
Only for the current session. The next time you start the app, its code is
JIT compiled again.
Post by Mark E.
Furthermore the runtime can observe how the program is being used and
*change* the compiled exe to optimize for performance.
In principle. The current CLR doesn't have that feature implemented.

- Per
Rudy Velthuis (TeamB)
2003-12-31 12:56:21 UTC
Permalink
Post by Per Larsen
Post by Mark E.
What? It sounds like you are implying that the compile happens at
runtime every time. This is not true. It is compiled to IL when you
compile from the IDE. Then the JIT compiles it to native machine code
when execute the FIRST time. That native code is cached as used
ever-after.
Only for the current session. The next time you start the app, its code
is JIT compiled again.
Yes. But I think you'll agree with me that most of the time in number
crunching is spent in loops processing more or less large amounts of
data. Such loops only must be compiled once, and after the first
iteration, they run full speed.

If you want full speed from the start, use NGEN to compile the
intermediate to full native code, which deos not have to be JITted
anymore.
--
Rudy Velthuis (TeamB)

"Pray, v.: To ask that the laws of the universe be annulled on behalf of
a
single petitioner confessedly unworthy."
-- Ambrose Bierce (1842-1914)
Frank Andreas de Groot
2003-12-30 16:42:13 UTC
Permalink
Post by Tim Anderson
By your logic I suppose all languages are interpreted. It is just a matter
of when you compile and when you cache.
Compiling at run-time is insane.
There is no possibility to optimize, simply because there is no time to do that.

This is why Java & .net applications have such a limited use, they can only be
used for database and web-type applications.
Anyone who takes programming seriously gives that crap a wide berth.
Tim Anderson
2003-12-30 16:41:01 UTC
Permalink
Compiling at run-time is insane.
There is no possibility to optimize, simply because there is no time to do that.
Remember you are compiling intermediate language, not text code. Plus, it
can optimize for the specific hardware on which it is running.

But I suppose D7 is no good either because it compiles too quickly :-)

Tim
Per Larsen
2003-12-31 13:07:01 UTC
Permalink
Compiling at run-time is insane.
I wouldn't go quite that far :)
There is no possibility to optimize, simply because there is no time to do that.
That's relative. The current JIT compilers do perform certain types of
optimizations, but it's true that the more aggressive types of optimizations
are usually too time-consuming to be performed at run-time.

- Per
Eric Grange
2003-12-29 15:44:49 UTC
Permalink
Performance profile seems quite different from your P4 here:
15700, 4700 and 761 respectively, ie. it starts quite slower
than your P4, but ends faster... (D7 is at 561 on that machine,
it's an AXP 2200+, same clock speed as the 2500+ but smaller
CPU cache).
If that gets confirmed, I smell a rat in the .net JIT code
generation (no good reason why your P4 would be 2+ times
faster in the "inefficient" cases, but get smoked in the
"efficient" case).

That 761 figure looks good enough performance-wise (compares
not-so-unfavourably with 450 on D7 w/ASM), however, it comes
at quite a hefty price: having to manually unroll loops and arrays.

Also, I'm not so sure the function<->procedure exchange would work
that well if instead of placing the result in the same variable
all the time, result was stored in different variables or an array
(which is more akin to real-world use of the thing).

Anyway, I guess that unless Borland fix their copy real quick,
they are bound for a very rough ride in the .net world if such
a performance ratio vs C# gets confirmed in other areas as well.

Eric
mrqzzz
2003-12-29 14:35:21 UTC
Permalink
Hello.
Post by Tim Anderson
Sorry, my tests were in C# as I'm more concerned at the moment with .Net
perf rather than D8 perf; but it is all relevant.
....
Post by Tim Anderson
Point 3: Delphi 7 has an optimizer. Do we know how it is optimizing this
code? Well, it can be tested by decompiling the exe. But it's interesting to
turn D7's optimizer off.
Result: D7 about 1.7K ticks. Now slower than C#.
Looks like you're optimizing C# and unoptimizing D7.
Fair ?
Post by Tim Anderson
If I have time, I'll poke about with the D8 code too.
If my team of 20 members developed speed-critical projects with Delphi for
,say, 3 years, must we rewrite the whole thing in C# to obtain something
still slower ?

I understand this is the direction, virtual machine, sandboxes, safe code,
etc...
But when you must deal with macro projects, passing from Delphi to D8FDN is
a real sufference...

Marcus.
Tim Anderson
2003-12-29 15:10:13 UTC
Permalink
Post by mrqzzz
Post by Tim Anderson
turn D7's optimizer off.
Result: D7 about 1.7K ticks. Now slower than C#.
Looks like you're optimizing C# and unoptimizing D7.
Fair ?
I'm not trying to be "fair". I'm investigating why the performance is
different.

One of the points about optimization is that it sometimes makes more
difference in test code running meaningless loops than in real-world
scenarios.
Post by mrqzzz
But when you must deal with macro projects, passing from Delphi to D8FDN is
a real sufference...
I agree. However, nobody will move to .Net because it is faster (well, they
might move to ASP.Net because it is faster than ASP). The advantages are
elsewhere; the performance problem however is something that can often be
mitigated.

Tim
Borland execs speak:
http://www.itwriting.com/borlandtop.php
Captain Jake
2003-12-29 16:11:54 UTC
Permalink
In borland.public.delphi.non-technical, Tim Anderson <***@hot_m_ail.com>
wrote in message <3ff02f2d$1
@newsgroups.borland.com>...
Post by Tim Anderson
Did some playing around with this.
Does the EULA allow this? If so then D8 represents a radical change in the
license.
--
***Free Your Mind***
Frank Andreas de Groot
2003-12-29 16:22:19 UTC
Permalink
Post by Captain Jake
Does the EULA allow this? If so then D8 represents a radical change in the
license.
As I told you before, a US judge has deemed such clauses null and void,
everybody is free to publish benchmark results, regardless of any EULA.
Captain Jake
2003-12-29 17:04:11 UTC
Permalink
In borland.public.delphi.non-technical, Frank Andreas de Groot
Post by Frank Andreas de Groot
As I told you before, a US judge has deemed such clauses null and void,
everybody is free to publish benchmark results, regardless of any EULA.
Are you aware that judges have limited jurisdictions in the United States and
unless the judge that made the decision was at the SCOTUS level rather than
just a district that his ruling only affects the region over which he has
jurisdiction?

If a judge in another jurisdiction makes a ruling that ruling doesn't enable
you to change your behaviour accordingly, all it does it make it slightly
more likely that if you get sued you might be able to site legal precedent in
your case. And even if you prevail in the courts you will still be saddled
with the legal bills.
--
***Free Your Mind***
William Meyer
2003-12-29 18:53:50 UTC
Permalink
Post by Captain Jake
Are you aware that judges have limited jurisdictions in the United
States and unless the judge that made the decision was at the SCOTUS
level rather than just a district that his ruling only affects the
region over which he has jurisdiction?
And if it was a ruling in the 9th Federal Circuit, then it should be
viewed as transitory, since they are pretty routinely overturned. <g>
--
Bill
--------

"You can't keep on doing things the old way and still get the benefits
of the new way." -- Thomas Sowell
Mike Mormando
2003-12-29 19:18:21 UTC
Permalink
Post by Frank Andreas de Groot
Post by Captain Jake
Does the EULA allow this? If so then D8 represents a radical change in the
license.
As I told you before, a US judge has deemed such clauses null and void,
everybody is free to publish benchmark results, regardless of any EULA.
I believe that was only a New York state judge, so, you can publish
benchmarks only in New York. ;)
Mike
Will DeWitt Jr.
2003-12-29 15:32:03 UTC
Permalink
Post by Captain Jake
In borland.public.delphi.non-technical, Tim Anderson
@newsgroups.borland.com>...
Post by Tim Anderson
Did some playing around with this.
Does the EULA allow this? If so then D8 represents a radical change
in the license.
No it does not appear to have changed. From license.txt--

5. LIMITATIONS. You may not: (a) modify, adapt,
alter, translate, or create derivative works of the
Product or merge the Product with other software
other than as described in the Product's
accompanying documentation or as approved of in
writing by Borland; (b) lease, rent or loan the
Product to any third party; (c) sublicense,
distribute or otherwise transfer the Product or any
component thereof to any third party except as
expressly authorized in this Agreement; (d) reverse
engineer, decompile, disassemble, or otherwise
attempt to derive the source code of the Product;
(e) remove, alter, or obscure any confidentiality or
proprietary notices (including copyright and
trademark notices) of Borland or its suppliers on
the Product; (f) allow third parties to access or
use the Product such as in a time-sharing
arrangement or operate the Product as part of a
service bureau or, except as expressly authorized
under Sections 2, 3 or 4, otherwise for the use or
benefit of third parties; (g) reproduce or use the
Product except as expressly authorized under
Sections 2, 3 or 4; or (h) disclose or publish
performance benchmark results for the Product. The
rights granted under this License apply only to this
Product. You must procure a separate license to use
other Borland software. Furthermore, you may not
permit your End Users to conduct the restricted
activities limited by items (a) through (e), (g) and
(h) above insofar as they apply to Redistributables,
and such End User's sublicense rights to the
Redistributables are conditioned upon compliance
with such limitations. The limitations in this
Section 5 apply equally to your use of the Product,
in whole or in part, including any component or
Redistributable.

----

Sad that it's still burdened with the "no benchmarks" clause (that's
the (h) clause for the lazy). You know what's really interesting is
the "Furthermore" section towards the end stating that you may not
permit your "End Users" to conduct activities limited by (a) through
(e), (g) and (h). What does this mean for people writing
encoders/decoders or so forth that may at some point have their work
benchmarked against a competitors product (which likely performs the
same way or has very similar algorithms)?

There is no sanity at Borland with regard to this.

Will
Captain Jake
2003-12-29 17:06:35 UTC
Permalink
In borland.public.delphi.non-technical, "Will DeWitt Jr." <***@boink.net>
wrote in message <3ff05703$1
@newsgroups.borland.com>...
Post by Will DeWitt Jr.
In borland.public.delphi.non-technical, Tim...
No it does not appear to have changed. From license.txt
Ah, for a few minutes I thought Borland had changed it's stance on this. Now
I find out that nothing has changed, and
Tim is simply ignoring the license agreement. <sigh>
--
***Free Your Mind***
Eric Grange
2003-12-29 18:05:29 UTC
Permalink
Post by Captain Jake
Does the EULA allow this? If so then D8 represents a radical change in the
license.
Somehow, I'm not sure it would be a great move from Borland to try
and drop a veil of secrecy around this... In fact, I rather see none
of them (Borland or TeamB, hint, hint) ever touching this thread ;)

Though a comment from some Borlander, stating something like

"We'll have it fixed ASAP and bring D8FDN to C# performance
level or better, my head on a pike if we fail!"

would sure be nice - even without the "head on a pike" thing :)

Eric
Captain Jake
2003-12-29 18:20:59 UTC
Permalink
In borland.public.delphi.non-technical, Eric Grange <***@glscene.org>
wrote in message <3ff06c46
@newsgroups.borland.com>...
Post by Eric Grange
In fact, I rather see none
of them (Borland or TeamB, hint, hint) ever touching this thread ;)
Considering that Borland is closed for the holidays until Friday, it is
doubtful that any of them actually see this thread until then. I suspect that
this thread could get cancelled before then, unless TeamB is too busy
bickering
about other things to do their job.
--
***Free Your Mind***
Eric Grange
2003-12-29 19:06:10 UTC
Permalink
Afraid of something are ye?

We were told oh-so-many-times in these very newsgroup that .net
was oh-so-efficient, that it was as fast as natively compiled
code, if not faster. I guess a reality check isn't overdue.

Haven't heard many figures about the memory consumption yet,
I'm quite sure it'll be very interesting too.

Do not mistake me, I take no pleasure in finding out how inefficient
D8FDN is, I would have been very pleased to find a D8 that was faster
than the old D7, or at least as efficient. But I won't put my head
in a hole and deny what I see or look for excuses.
Maybe they won't listen, but at least I'll have tried. Most will just
throw the towel and go.

Eric
Frank Andreas de Groot
2003-12-29 19:12:05 UTC
Permalink
Post by Eric Grange
Maybe they won't listen, but at least I'll have tried. Most will just
throw the towel and go.
Yesterday, I have installed Eclipse and ran my first Java program.
Java makes a lot more sense than .net (it's cross-platform), and it's faster!
Tim Anderson
2003-12-29 19:24:29 UTC
Permalink
Post by Frank Andreas de Groot
Post by Eric Grange
Maybe they won't listen, but at least I'll have tried. Most will just
throw the towel and go.
Yesterday, I have installed Eclipse and ran my first Java program.
Java makes a lot more sense than .net (it's cross-platform), and it's faster!
Generally slower IME. But this one is really difficult to pin down. You have
to consider which JVM along with all the other things that make judging
performance such an inexact science.

Tim
Captain Jake
2003-12-30 16:15:04 UTC
Permalink
In borland.public.delphi.non-technical, Frank Andreas de Groot
Post by Frank Andreas de Groot
Yesterday, I have installed Eclipse and ran my first Java program.
Java makes a lot more sense than .net (it's cross-platform), and it's faster!
You run one program and conclude the language is faster? Damn, I wish I had
as easy a time deriving fundamental truths. Here I am worrying about
reproducible, robust results only to find out I could take a cheap shortcut
to
reality.
--
***Free Your Mind***
Frank Andreas de Groot
2003-12-30 16:43:38 UTC
Permalink
Post by Captain Jake
You run one program and conclude the language is faster?
Where on Earth did you get that idea?
You are so full of yourself and how other programmers are "stupid".
I have this from independent benchmarks, you fool.
Craig Stuntz [TeamB]
2003-12-30 15:55:09 UTC
Permalink
Reply to Jake cancelled due to personal attack. Keep the language
civil, please.

-Craig
--
Craig Stuntz [TeamB] . Vertex Systems Corp. . Columbus, OH
Delphi/InterBase Weblog : http://delphi.weblogs.com
Useful articles about InterBase and Delphi development:
http://delphi.weblogs.com/articles
Tim Anderson
2003-12-30 17:42:13 UTC
Permalink
Post by Craig Stuntz [TeamB]
Reply to Jake cancelled due to personal attack. Keep the language
civil, please.
But he hasn't given us his independent benchmarks yet ...

Actually I couldn't resist running up the matrix example in JBuilder. It's
trivial to port from C# to Java. I noticed:

- that on my machine Java was substantially slower for this.

- that Java has no struct option

so it would be many times slower in this test. I don't know if there any
other way you could speed up this kind of operation in Java?

Tim
Craig Stuntz [TeamB]
2003-12-30 16:55:05 UTC
Permalink
Post by Tim Anderson
But he hasn't given us his independent benchmarks yet ...
This has nothing to do with the personal attack which is used. If
that person is unable to ask for them without juvenile insults, he
should avoid posting at all.

-Craig
--
Craig Stuntz [TeamB] . Vertex Systems Corp. . Columbus, OH
Delphi/InterBase Weblog : http://delphi.weblogs.com
Please read and follow Borland's rules for the user of their
news server: http://info.borland.com/newsgroups/guide.html
Martin Waldenburg
2003-12-30 19:00:08 UTC
Permalink
Post by Tim Anderson
- that on my machine Java was substantially slower for this.
- that Java has no struct option
maybe using a class ?

C# is running with exactly the same speed
if a class is used instead the struct.
BTW D8 too if compiled with {$FINITEFLOAT OFF}
D7 is then only marginaly faster.

Martin
Eric Grange
2003-12-30 19:17:21 UTC
Permalink
Post by Martin Waldenburg
D7 is then only marginaly faster.
About an order of magnitude faster, nothing marginal.
C# could get close to D7 by forfeiting arrays and functions,
but D8FDN couldn't.

Eric
Will DeWitt Jr.
2003-12-30 18:19:30 UTC
Permalink
Post by Eric Grange
About an order of magnitude faster, nothing marginal.
C# could get close to D7 by forfeiting arrays and functions,
but D8FDN couldn't.
Careful, we're discussing something that's against the license
agreement. Wouldn't want the Borland police coming knocking. :P

Will
Martin Waldenburg
2003-12-30 19:39:17 UTC
Permalink
Post by Eric Grange
Post by Martin Waldenburg
D7 is then only marginaly faster.
About an order of magnitude faster, nothing marginal.
C# could get close to D7 by forfeiting arrays and functions,
but D8FDN couldn't.
If I say marginaly then I mean exactly that.
You will have to do at least hundred million
iterations to get a noticeable difference.

Martin
Eric Grange
2003-12-30 22:15:33 UTC
Permalink
Post by Martin Waldenburg
If I say marginaly then I mean exactly that.
You will have to do at least hundred million
iterations to get a noticeable difference.
60 FPS, a dozen meshes at 10k vertices each, here you are,
problem glaring for what was previously a non-issue.
And we're still far from today's industry standards
with such figures.
You've got to realize that there are enough *REAL* problems
out there without having to worry about artificial ones
induced by a tool's deficiency. Not everyone is coding
yet-another-phonebook.

If you follow your own logic, then I guess you're still using
a Pentium 200? More than enough to satisfy all computing needs,
such a beast is "marginally" slower than multi-GHZ CPU.

Eric
Martin Waldenburg
2003-12-30 22:54:41 UTC
Permalink
Eric Grange wrote:
..................

I'm quite sure that my English is
understandably enough, thus I have
to assume that you don't want to
understand and just want to continue
trolling.

Martin
Mark E.
2003-12-30 22:54:33 UTC
Permalink
Post by Eric Grange
Post by Martin Waldenburg
If I say marginaly then I mean exactly that.
You will have to do at least hundred million
iterations to get a noticeable difference.
60 FPS, a dozen meshes at 10k vertices each, here you are,
problem glaring for what was previously a non-issue.
And we're still far from today's industry standards
with such figures.
You've got to realize that there are enough *REAL* problems
out there without having to worry about artificial ones
induced by a tool's deficiency. Not everyone is coding
yet-another-phonebook.
If you follow your own logic, then I guess you're still using
a Pentium 200? More than enough to satisfy all computing needs,
such a beast is "marginally" slower than multi-GHZ CPU.
Eric, be nice now. ;) Martin is a bright guy. His usage is probably not
as demanding as yours. This is the Martin who created the pascal parser
for SynEdit, DWS, CodeLens, and others. He is very aware of performance.
I just don't think he has needed to do anything with the volume of data
that you do with GLScene.

You make a valid point here. There are real issues with it. I don't
think that there is a good answer for it yet. Just keep in mind that
many people (myself included) do not have the same demands that you
have. I too want to be able to use .NET for 3D applications but that
doesn't mean I can't use .NET for many other things right now and be
completely satisfied.

No offense intended to anyone here... I respect both of you as developers.

-Mark E.
Martin Waldenburg
2003-12-30 23:22:29 UTC
Permalink
Post by Mark E.
I just don't think he has needed to do anything with the volume of data
that you do with GLScene.
BTW the last years before I got finaly ill
I've worked as a technical illustrator earning
my lifehood with 3D stuff and the help of a
Sharp pocked computer running a menu driven
BASIC programm written by myself to do the
matrix manipulations.
However at that time I still had to do the
actual drawing by hand.
I know quite a lot about the computational
needs of 3D graphics and I'm also quite sure
that there will very rarely occur a need to
do more than the about ten million matrix
multiplications per second that D8 is capable
to do on my P4 2.8c.
In almost all cases the number of matrix multiplications
needed will be magnitudes lower.

Martin
Eric Grange
2003-12-31 08:06:51 UTC
Permalink
Indeed, but somehow I don't see how people can be content with
lower performance, higher memory use, reduced *effective*
compatibility and having to think about optimization in situations
were it was previously a non-issue (ie. have to waste developement
time because of compiler deficiencies).

It's not like Delphi is the sole product that is .net capable
out there, or the sole compiler. AMOF, its main advantage is
nowadays its existing codebase: while Delphi was essentially static
on the visual design front, others evolved and catched up.
If getting the existing codebase up to usable level requires
the kind of changes enumerated here, a tool switch becomes a very
pragmatic solution: code readability and maintainability won't
suffer as much.

Eric
Mark E.
2003-12-31 15:16:31 UTC
Permalink
Post by Eric Grange
Indeed, but somehow I don't see how people can be content with
lower performance, higher memory use, reduced *effective*
compatibility and having to think about optimization in situations
were it was previously a non-issue (ie. have to waste developement
time because of compiler deficiencies).
With something like GLScene that may be the case. However, I think you
already do that with Delphi but don't think about it because you've
already figured those things out and it's a non-issue. Things like
"don't use variants for floating point math". Sure, that's a stupid and
obvious example but I hope it makes my point. It's just a matter of
getting familiar with a new toolset and identifying the strengths and
weaknesses.

There are many areas where it dramatically increases your productivity
as well. Garbage collection, remoting, serializability, built-in object
property binding (no data-aware controls needed), cross-platform, etc.

Strengths and weaknesses. *Every* toolset has them.

Yes. Cross-platform. People seem to forget about or discount Mono. I
personally think Mono may become /the/ standard. It is already running
on Solaris, Unix, Linux, and Windows. Currently being ported to MacOS X.
No one says you have to use the MS .NET Runtime.

[...]
Post by Eric Grange
If getting the existing codebase up to usable level requires
the kind of changes enumerated here, a tool switch becomes a very
pragmatic solution: code readability and maintainability won't
suffer as much.
You may also find that reworking the codebase is more advantageous to
futher improve readability and maintainability with features of .NET
that don't exist or aren't feasible in a D7 and below.

Since a record type in .NET is (AFAIK) actually an object it can have
methods. So your matrix and vector can have the methods for translations
built onto the object. It can also have operator overloading to improve
code readability.

Vector1 = Vector2 + Vector3;
VectorA.Add(VectorB);

These would do the change you need (var results) and improve
readability. It would also improve maintainability because all the
vector translation routines would be on the vector and it would make it
easier for users to find what they needed.

That drastic of a change comes at a price. You would probably have to
either not do that change and stick with backward compatibility or
abandon backward compatibility and move forward with a new methodology.

Big bad choice eh?

-Mark E.
Eric Grange
2003-12-31 15:53:08 UTC
Permalink
hmm... like not using arrays of functions anymore? ;)
Erratum: *or* functions
Eric Grange
2003-12-31 15:52:06 UTC
Permalink
[...] built-in object property binding (no data-aware controls needed)
I can see that for some people that could be a benefit, but @work
we removed our last data-aware components 2 years ago, and they
were strays, and I don't think we ever had more than dozen of forms
based on data-aware components (never found it convenient,
and from a design point of view, hooking components to explicit fields
isn't very clean for a complex app).
Yes. Cross-platform. People seem to forget about or discount Mono. I
personally think Mono may become /the/ standard. It is already running
on Solaris, Unix, Linux, and Windows. Currently being ported to MacOS X.
No one says you have to use the MS .NET Runtime.
The JIT is just a fraction of the issue, what matters are the library,
and Mono will have a really hard time keeping up on that issue, especially
if they want to support all the GUI and visible stuff.
IMO if you want cross-platform you're better off using Java or C++.
You may also find that reworking the codebase is more advantageous to
futher improve readability and maintainability with features of .NET
that don't exist or aren't feasible in a D7 and below.
hmm... like not using arrays of functions anymore? ;)
It can also have operator overloading to improve code readability.
But operator overloading in .net will play to its weaknesses:
it will increase the number of intermediate objects (generated
automatically by the compiler), increase the number of assignments
and the strees on the GC, and use functions instead of procedures.
These would do the change you need (var results) and improve
readability.
Effectively. But this would also forbid its use in arrays you could
pass to the hardware, resulting in the need to have different classes
to handle the different aspects of a vector (as a lone vector, as an
eigen vector, as a vector in an array, as an array of vector and as
matrix of vectors).
(note that record methods properly implemented in a native compiler
wouldn't suffer from this, because they would need no structural
overhead)
That drastic of a change comes at a price. You would probably have to
either not do that change and stick with backward compatibility or
abandon backward compatibility and move forward with a new methodology.
Big bad choice eh?
The worst choice, you didn't list: if backward compatibility is abandonned,
there is just no incentive to stick with Delphi as it stands in its 8th
incarnation, not just because of performance issue, but also because the new
IDE has nothing more to offer over its cheaper competition from MS
(ability to view and edit multiple forms at a time is gone, horizontal
component palette is gone, and from the behaviour of C#Builder's IDE,
I guess the ability to view and edit 3D stuff in the form designer would
need serious workarounds too, if it's still feasible at all).

Eric
Rudy Velthuis (TeamB)
2004-01-01 13:27:14 UTC
Permalink
Post by Eric Grange
Indeed, but somehow I don't see how people can be content with
lower performance, higher memory use, reduced effective
compatibility and having to think about optimization in situations
were it was previously a non-issue (ie. have to waste developement
time because of compiler deficiencies).
What compiler deficiencies? I tested your code in C# and in D8, and
optimized a little for the platform (something one should IMO always do
if speed is a real issue), and D8 code came out a little faster than
equivalent C# code. I have no idea why.
--
Rudy Velthuis (TeamB)

"An inconvenience is only an adventure wrongly considered; an adventure
is an inconvenience rightly considered."
- Gilbert Keith Chesterton (1874-1936)
Martin Waldenburg
2004-01-01 15:09:52 UTC
Permalink
Post by Rudy Velthuis (TeamB)
and D8 code came out a little faster than
equivalent C# code. I have no idea why.
if you replace the struct in Tim's sample
with a class, convert it to D8 and compile
with C# and D8 using the $FINITEFLOAT directive
Reflector will show for the matrix multiplication
about 540 lines of ILAssembler for C#
but only about 400 for D8.

Martin
Rudy Velthuis (TeamB)
2004-01-01 15:26:56 UTC
Permalink
Post by Martin Waldenburg
Post by Rudy Velthuis (TeamB)
and D8 code came out a little faster than
equivalent C# code. I have no idea why.
if you replace the struct in Tim's sample
with a class, convert it to D8 and compile
with C# and D8 using the $FINITEFLOAT directive
Reflector will show for the matrix multiplication
about 540 lines of ILAssembler for C#
but only about 400 for D8.
I noticed that it makes a big difference where the code is located. If I
put in the same unit as the form, it is a lot faster than when it is put
in its own unit.

I have the impression that the speed of this code is higly dependent on
code alignment.
--
Rudy Velthuis (TeamB)

"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."
- unknown
Martin Waldenburg
2004-01-01 17:23:08 UTC
Permalink
Post by Rudy Velthuis (TeamB)
I have the impression that the speed of this code is higly dependent on
code alignment.
if it is not in the same namespace
or even in the same object then there
are additional access restrictions.
MS has somewhere a site where the
costs in time are listed, unfortunately
I don't have the address at hand.

Martin
Rudy Velthuis (TeamB)
2004-01-01 16:25:37 UTC
Permalink
Post by Martin Waldenburg
Post by Rudy Velthuis (TeamB)
I have the impression that the speed of this code is higly dependent
on code alignment.
if it is not in the same namespace
or even in the same object then there
are additional access restrictions.
Only global procedures in a different unit, or in the same.
--
Rudy Velthuis (TeamB)

"God, please save me from your followers!"
- Bumper Sticker
Martin Waldenburg
2004-01-01 17:40:23 UTC
Permalink
Post by Rudy Velthuis (TeamB)
Only global procedures in a different unit, or in the same.
a call to self.xyz, that means within the same object
will always be the fastest for equivalent (static, virtual..)
implementations.

Martin
Tim Anderson
2003-12-30 23:14:25 UTC
Permalink
Post by Eric Grange
Post by Martin Waldenburg
If I say marginaly then I mean exactly that.
You will have to do at least hundred million
iterations to get a noticeable difference.
60 FPS, a dozen meshes at 10k vertices each, here you are,
problem glaring for what was previously a non-issue.
I think you are misunderstanding Martin.

If you make the following changes:

1. Add the compiler directive {$FINITEFLOAT OFF}

2. Use a class with 16 fields instead of a 4 x 4 array

3. Use a procedure instead of a function

.... then your matrix code runs at a near-identical speed in D8 and D7.

I get a difference of between 5% and 10%. I think it's fair to call that
marginal.

You'll recall that this test was initially proclaimed as 60 times slower in
D8. If nothing else, it shows the value of working at optimization (and that
.Net is not inherently slow).

Tim
Eric Grange
2003-12-31 07:52:34 UTC
Permalink
Post by Tim Anderson
1. Add the compiler directive {$FINITEFLOAT OFF}
You quoted a 15% improvement = negligible
Post by Tim Anderson
2. Use a class with 16 fields instead of a 4 x 4 array
Not a solution, but a hack. This can lead to massive manual
loop unrolling in other situations, or having to maintain a whole
collection of different Matrix classes (field or array based)
= pure waste of (developper) time with only a non-improvement
at best for the end-users
Post by Tim Anderson
3. Use a procedure instead of a function
If there is a change I would go, that would be operator overloading,
not more obfuscating call conventions.
Post by Tim Anderson
.... then your matrix code runs at a near-identical speed in D8 and D7.
Your own figures still have a 1 to 7 ratio in that case.
Unless you consider that a P3 700 is near identical to a 2500+, that is.
Post by Tim Anderson
I get a difference of between 5% and 10%. I think it's fair to call that
marginal.
hmm? It was with C# that you reached a ratio of +50%, where did you reach 5-10%?
By deactivating D7 optimization? Using Variants in the D7 code would have been
a more efficient way to make it look slow.
Post by Tim Anderson
[...] it shows the value of working at optimization (and that
.Net is not inherently slow).
It only shows that if you don't optimize specifically for .net you get
low performance. If you want normal code, you get low performance.

What you fail to see is that there are *other* languages that don't suffer
from this limitation. You can hide your head in the sand all you want and
pretend performance isn't an issue, fact is that D7 was able to compete
with C++ on the performance front, and D8 no longer is. It does not even
seem to compete against C# when using clean code.

If everything is so rosy, that makes me wonder why .net projects like Axiom
are eagerly waiting for .net 2.0 and the estimated 500% performance improvements
they found in early tests...
Oh, and yeah, in the case of Axiom, the optimization that will be required
by .net 2.0 are said to be quite different from those needed to boost
performance in 1.1...

Eric
Tim Anderson
2004-01-01 08:12:39 UTC
Permalink
Post by Eric Grange
Post by Tim Anderson
I get a difference of between 5% and 10%. I think it's fair to call that
marginal.
hmm? It was with C# that you reached a ratio of +50%, where did you reach 5-10%?
I used revised code with the changes I mentioned. The comparison is with
optimized D7.

Tim
Rudy Velthuis (TeamB)
2004-01-01 12:55:48 UTC
Permalink
Post by Eric Grange
It only shows that if you don't optimize specifically for .net you get
low performance. If you want normal code, you get low performance.
Sorry, but this is the same kind of discussion as we had about using
Strings or StringBuilder to concatenate a lot of strings together. This
showed that if you use suboptimal code, you may have gotten away with it
in Delphi 7, in some circumstances, but not on .NET. But if you use code
optimized for the platform, you get what you need.

Of course, if you really need speed, you must always optimize for the
platform, IMO. But even if you don't, don't rely on non-optimized code
that may have worked out in D7 and call it "normal code".
--
Rudy Velthuis (TeamB)

"Your Highness, I have no need of this hypothesis."
-- Pierre Laplace (1749-1827), to Napoleon on why his works on celestial
mechanics make no mention of God.
Eric Grange
2004-01-02 08:23:28 UTC
Permalink
Okay okay, instead of a 4x4 matrix, make it a NxN matrix so
you can't use the dirty trick of manually converting arrays
elements to fields, and manually unrolling all loops.
Where is the the nice and fluffy D8 solution now?

Eric
Rudy Velthuis (TeamB)
2004-01-02 08:57:14 UTC
Permalink
Post by Eric Grange
Okay okay, instead of a 4x4 matrix, make it a NxN matrix so
you can't use the dirty trick of manually converting arrays
elements to fields, and manually unrolling all loops.
Where is the the nice and fluffy D8 solution now?
Let me give that a try. Note that in such cases you won't be able to use
fixed size arrays in Delphi 7 either.
--
Rudy Velthuis (TeamB)

"I think it would be a good idea."
-- Mahatma Gandhi (1869-1948), when asked what he thought of Western
civilization
Tim Anderson
2003-12-30 20:12:34 UTC
Permalink
Post by Martin Waldenburg
Post by Tim Anderson
- that Java has no struct option
maybe using a class ?
You're right. It's still a lot slower, but improved.
Post by Martin Waldenburg
C# is running with exactly the same speed
if a class is used instead the struct.
Confirmed.
Post by Martin Waldenburg
BTW D8 too if compiled with {$FINITEFLOAT OFF}
D7 is then only marginaly faster.
Confirmed - faster than C# in fact :-)
Post by Martin Waldenburg
Martin
chrisC
2003-12-31 01:57:16 UTC
Permalink
Post by Frank Andreas de Groot
Yesterday, I have installed Eclipse and ran my first Java program.
Java makes a lot more sense than .net (it's cross-platform), and it's faster!
Wow! You mean you installed all that Java "crap" !
Maybe leopards may one day change their spots after all.

Chris>
David Smith
2003-12-30 01:37:22 UTC
Permalink
Post by Eric Grange
Afraid of something are ye?
We were told oh-so-many-times in these very newsgroup that .net
was oh-so-efficient, that it was as fast as natively compiled
code, if not faster. I guess a reality check isn't overdue.
It's not Delphi 8's speed over D7 that we are worried about. It's D8's
speed compared to C# we are worried about.

David
Eric Grange
2003-12-30 06:49:28 UTC
Permalink
Post by David Smith
It's not Delphi 8's speed over D7 that we are worried about. It's D8's
speed compared to C# we are worried about.
If you're into moving to .net, I can understand this could turn out
as a strong incentive for using D8FDN only as a tool to convert your
code to C# (via D8 compilation then decompilation with reflector).

Eric
Tim Anderson
2003-12-30 17:44:17 UTC
Permalink
Post by Tim Anderson
Point 2: Use a procedure instead of a function, passing the result variable
by reference.
Actually, this is misleading. Using a function vs procedure makes little
difference. What makes a difference is instantiating a new array (to hold
the result) within the loop. In this example, you could use a class variable
instead and get the same result with either the function or the procedure.

Tim
Loading...