Board index » delphi » Re: .NET

C4D - Kim Madsen

Delphi Developer
 

Re: .NET


2005-08-30 11:39:47 AM
delphi45
Hi,
Quote
The principle reason painting is slow in .NET 1.1 has nothing to do
with GC. When optimizing one should fix the slow stuff first, and it
isn't the GC in that case.
I wasnt talking about overall GUI performance, but about the situations where the application stalls for 1/2 to a whole
second because GC kicks in.
This rarely is discovered on server applications simply because there is no GUI there that stalls while the GC is doing
its thing.
Quote
Also, I have never been sure why people think having the CPU pegged is a
*bad* thing. They'll pay lots of money for a fast CPU and then expect
it to sit idle all day. it is a problem when a task *monopolizes* a CPU,
not when it *uses* it.
Thats exactly what Intel and AMD wants to hear... They produce faster CPU's every year. To make their business work,
they _need_ to make older CPU's obsolete within a few years time. MS and Sun is doing everything they can to help them
with that by spending more and more CPU cycles outside the user application for doing house keeping and often too in
poorly optimized algorithms (which Borland also have had a couple of in the RTL libraries :))
--
best regards
Kim Madsen
XXXX@XXXXX.COM
www.components4developers.com
The best components for the best developers
kbmMW - RAD Enterprise class n-tier application server framework
kbmMemTable - High performance memory table
kbmWABD - RAD web development
kbmX10 - RAD house automation
 
 
Donald Shimoda

Delphi Developer

2005-08-30 12:18:31 PM

Re: .NET

Dave Nottage [TeamB] writes:
Quote

Also, parts of the Space Cadet pinball game that comes with Windows
was originally written in Delphi, then converted to C/C++ <g>
Really? I know Danny Thorpe work on Space Cadet, but is the first time
i read was written in Delphi.
Donald
 
Germán Pablo Gentile

Delphi Developer

2005-08-30 12:20:26 PM

Re: .NET

C4D - Kim Madsen writes:
Quote
Thats exactly what Intel and AMD wants to hear... They produce faster
CPU's every year. To make their business work, they need to make
older CPU's obsolete within a few years time. MS and Sun is doing
everything they can to help them with that by spending more and more
CPU cycles outside the user application for doing house keeping and
often too in poorly optimized algorithms (which Borland also have had
a couple of in the RTL libraries :))
Sounds like {*word*97} theory. Just must be kidding.
Donald
 

Andre Kaufmann

Delphi Developer

2005-08-30 01:03:15 PM

Re: .NET

Richard Foersom writes:
Quote
[...]

So the fact that when MS use their own development tools and
frameworks, tells you that you can have some belief in quality and
longviety of the tools. When they do not you have reason to worry.

Marc please tell, which major applications have Microsoft written with
C# in dot-net?

Don't know a C# only application but most of the following applications
/ API's have CLI code:
- Windows Vista Avalon / Aero, WinGFX
- SQL Server
- Visual Studio
- Managed DirectX
Is there a need to convert all (existing) applications to 100% managed
code ?
Quote
Doei RIF
Andre
 
Robert Giesecke

Delphi Developer

2005-08-30 02:09:07 PM

Re: .NET

C4D - Kim Madsen writes:
Quote

I wasnt talking about overall GUI performance, but about the situations where the application stalls for 1/2 to a whole
second because GC kicks in.
This rarely is discovered on server applications simply because there is no GUI there that stalls while the GC is doing
its thing.

I've never faced this sort of problem. Looks to me, that you are too busy complaining how bad .Net is, that you forgot not
use finalizers.
Gosh! right! Finalizers are called in GC's thread, so if you have code there it probably has to be synchronized. *ouch*
Come on, has anybody, except Mr Madsen, ever seen GC making your app sluggish or even stalling?
 
Eric Grange

Delphi Developer

2005-08-30 03:29:37 PM

Re: .NET

Quote
In addition, the .NET memory model has other advantages not directly
related to GC but which nonetheless can give a performance boost over
so-called "native" code, such as the fact that locality improves as the
application runs. Since pointers are almost never fixed and the
collector tends to move long-lived allocations near each other,
locality tends to improve over what it was when the memory was first
allocated.
Locality is a bit more complex than that, and compactions during garbage
collections along with linear allocation more than negate its benefits
in all but extremely rare instances that one can encounter in only
in specially designed test cases (and even then...).
And I am not even speaking of the cache trashing issues arising from
GC-managed memory or locks-freezes GC can trigger (if you need a clue,
check into why the non-threaded GC is recommanded for servers).
Quote
The idea that GC somehow must be slow is nearly always repeated by
folks who don't develop with it very much.
The idea that GC is fast is a myth repeated by those that have never
done much development when performance really mattered, or never had
their software pitted against competiting software on pure performance
aspects, implementation of well-known algorithms/maths principles.
If you doubt it, just look at what the performance-aware side of MS
has been working tirelessly to get: GC allocation bypassing in C++/CLI.
Eric
 
C4D - Kim Madsen

Delphi Developer

2005-08-30 03:33:04 PM

Re: .NET

Quote
I've never faced this sort of problem. Looks to me, that you are too busy complaining how bad .Net is, that you forgot
not
use finalizers.
Gosh! right! Finalizers are called in GC's thread, so if you have code there it probably has to be synchronized.
*ouch*
Its not a specific .Net GC problem mind you... its simply the drawback of all the typical managed GC'ers.
You are, which is pretty typical in this group, not reading my posts thoroughly it seems.
Im not complaining over how bad .Net is... never have been. Im merely pointing out that .Net (and Java) have issues of
their own,
and are not the holy grale, solving all problems, despite some peoples and companies belief in that.
As I have worked on several large projects using both platforms, Im not exactly a novice.
Quote
Come on, has anybody, except Mr Madsen, ever seen GC making your app sluggish or even stalling?
Im sure lots of people have seen that if they work with any sort of near realtime application... or any complexity in a
GUI app.... still not talking about overall slugishness, but the extra spikes of GC lock down times.
A couple of them raised their voices as a reply to my post... Adam and Mike... if you'd care to browse around the posts.
--
best regards
Kim Madsen
XXXX@XXXXX.COM
www.components4developers.com
The best components for the best developers
kbmMW - RAD Enterprise class n-tier application server framework
kbmMemTable - High performance memory table
kbmWABD - RAD web development
kbmX10 - RAD house automation
 
IanH

Delphi Developer

2005-08-30 06:05:36 PM

Re: .NET

Eric Grange writes:
<snip>
Quote
The idea that GC is fast is a myth repeated by those that have never
done much development when performance really mattered, or never had
their software pitted against competiting software on pure
performance aspects, implementation of well-known algorithms/maths
principles. If you doubt it, just look at what the performance-aware
side of MS has been working tirelessly to get: GC allocation
bypassing in C++/CLI.
Eric,
Surely the only route left for developers concerned about performance
is C++/CLI? However much I prefer the readability of Object Pascal, the
native code generation capabilities of the VC++ compiler make this far
more suitable for high-performance apps than Delphi, particulary for
server-side apps.
My original choice of Delphi for my projects was based on the balance
between ease of use and power: making UI development easy, without
compromising on power (read: speed and flexibility) for the rest of the
app.
If coding a UI in C# and program logic in C++ becomes a seamless
operation (on my list of things to try), then Delphi loses it is main
selling point for me.
Ian
 
marc hoffman

Delphi Developer

2005-08-30 06:15:37 PM

Re: .NET

Richard,
Quote
No Marc, your argument with Delphi and MFC were wrong.
No, it wasn't. i maybe was imprecise by lumping together Visual C++ with
MFC without knowing the details (i'm not a Visual C++ or MFC developer,
after all). Point was and is, Office is written in Visual C++.
--
marc hoffman
Chief Architect, .NET
RemObjects Software
www.chromesville.com
and the fifty-two daughters of the revolution
turn the gold to chrome
 
marc hoffman

Delphi Developer

2005-08-30 06:19:16 PM

Re: .NET

C4D,
Quote
I wasnt talking about overall GUI performance, but about the situations where the application stalls for 1/2 to a whole
second because GC kicks in.
ahh, yes. i remember the good old Commodore C64 Basic used to do that... ;)
Quote
This rarely is discovered on server applications simply because there is no GUI there that stalls while the GC is doing
its thing.
Except that a mission-critical server will be stalling instead?*
(*not that im saying that IS happening with .NET; but fr the sake for a
a pure GC on client vs server discussion)
--
marc hoffman
Chief Architect, .NET
RemObjects Software
www.chromesville.com
and the fifty-two daughters of the revolution
turn the gold to chrome
 
marc hoffman

Delphi Developer

2005-08-30 06:21:25 PM

Re: .NET

Robert,
Quote
Come on, has anybody, except Mr Madsen, ever seen GC making your app
sluggish or even stalling?
I sure did. As mentioned in the other reply, Commodore C64 basic apps
would sometimes hang for up to /several minutes/ for the GC to do it's
job, if things got out of hand.
Oh wait. You meant with .NET, right? <g>
--
marc hoffman
Chief Architect, .NET
RemObjects Software
www.chromesville.com
and the fifty-two daughters of the revolution
turn the gold to chrome
 
Oliver Townshend

Delphi Developer

2005-08-30 06:34:38 PM

Re: .NET

Quote
I sure did. As mentioned in the other reply, Commodore C64 basic apps
would sometimes hang for up to /several minutes/ for the GC to do it's
job, if things got out of hand.
I knew you Remobjects guys were clever, but I didn't realize you'd ported
.Net to a C64. Is it in Beta?
Oliver Townshend
 
Angra Mainyu

Delphi Developer

2005-08-30 06:45:36 PM

Re: .NET

"Dave Nottage [TeamB]" wrote
Quote
Richard Foersom writes:

>It would be a
 >major scoop for Borland and big defeat for Microsoft if it was ever
 >discovered that a wellknown Microsoft application was written in
 >Delphi, rather than in one of Microsofts own tools.
I guess its not that well known, but:

groups.google.com.au/group/comp.os.ms-windows.programmer.misc/msg
/281be9e585978a50?hl=en&
Not to discredit the major scoop for Borland and big defeat for Microsoft but
ROADMAP.EXE. On CD, 108. Size, 197,260. Timestamp, 31/08/95 06:49:36A.M is
reaching pretty far back, 10 years from tomorrow to be exact. I can not help but
wonder what an insignificant wimp Microsoft would be today if this had been
widely known back then.<g>
 
Rudy Velthuis [TeamB]

Delphi Developer

2005-08-30 07:10:13 PM

Re: .NET

At 03:18:48, 30.08.2005, Dave Nottage [TeamB] writes:
Quote
groups.google.com.au/group/comp.os.ms-windows.programmer.misc/msg
/281be9e585978a50?hl=en&
So MS has a roadmap written in Delphi, but Borland does not have a
(public) roadmap? <g>
--
Rudy Velthuis [TeamB] velthuis.homepage.t-online.de
"If you can read this you're not aiming in the right direction."
-- Toilet-ceiling graffiti
 
Leonel

Delphi Developer

2005-08-30 07:57:34 PM

Re: .NET

Donald Shimoda writes:
Quote
Really? I know Danny Thorpe work on Space Cadet, but is the first time
i read was written in Delphi.
homepages.borland.com/dthorpe/products.html
"The pinball object model and collision physics code were originally
implemented in Delphi. (yes, pre-Delphi 1.0) When Microsoft got the
hots to license the game engine for the Win95 Plus! Pack, I had little
choice but to translate the Delphi code to C/C++ before turning the
source code over to them. I don't know when Microsoft became aware of
the Delphi project at Borland, but I certainly wasn't going to hand it
to them on a silver platter."
--
Leonel