Delphi on dual core CPUs
Dave White
"FWIW Delphi 7 compile times suffer on dual-core, I'm running it with
affinity adjusted to single-core, but this requires in turn adjusting
the affinity of debugged applications (as by default, they inherit the
affinity of the debugger)."
I'm in the process of ordering a new development system here at the ab.
I've been OK'd to get a nice X2 4800+ system, but now I'm not sure if that's
the way to go. I use a single core AMD 64 at home, and that's pretty nice.
I'm moving all of my development into virtual machines, so I thought a nice
fast dual core with a couple of gigs of RAM would work well.
Anubody have any comments on this? And how will compiled apps perform under
dal core? Will they potentially run slower too?
--
Dave White
SpectraChrom Software
www.spectrachrom.com
Tom Corey
> "FWIW Delphi 7 compile times suffer on dual-core, I'm running it with
> affinity adjusted to single-core, but this requires in turn adjusting
> the affinity of debugged applications (as by default, they inherit the
> affinity of the debugger)."
> Anubody have any comments on this? And how will compiled apps
> perform under dal core? Will they potentially run slower too?
I have a dual core 4400 CPU at home, and do some development work on it
there under D7. Eric is perhaps compiling much larger or more resource
intensive applications than I am, but for my 15,000 line database
application I've never noticed any slowdown in either compiling time or
run time performance.
Lou Feliz
I plan loading my D7 development environment into a VM Ware virtual machine
and if IIRC it will be a single CPU VM. My current Dev box is a fast
single core box with 3 gB of RAM, but my new one will be dual core w/ 4GB of
RAM. Once Dual core box is up ad running, I will just move the VM to new
box. Other benefit of using a VM is that I try new components in a copy of
the VM as well as the ability to move VM to new hardware and do not have to
worry about reinstalling Delphi again.
-Lou
"Dave White" <nos...@spam.com> wrote in message
news:4458eeca$1...@newsgroups.borland.com...
Eric Grange
> I've been OK'd to get a nice X2 4800+ system, but now I'm not sure if that's
> the way to go.
Don't doubt it a second, that's the way to go :)
And since it's new hardware, get 64bit compatible parts and a WinXP64 Pro (same
price as XP32) while you're at it, the OS is just way more responsive that XP32
(it's as responsive as Win2k3, without having to down-tweak a server OS).
In the first two days after installing, the combination of the 64bit OS
strictness, full DEP and dual-core allowed me to catch a dozen bugs that had
gone "unnoticed" for months, maybe years (they might have been noticed, but only
as non-reproducible random crashes).
> And how will compiled apps perform under dal core?
Depends on what your applications do, though that's likely something you'll want
to be experimenting first hand, before it hits your customers ;)
> Will they potentially run slower too?
The application I observed the slowdown for is about 950k lines, thousandths of
units: a whole build happens in around 35 seconds with D7's affinity adjusted to
single-core, about 45-50 seconds without, so it's not a fatal slowdown, but it's
noticeable.
As for why it's slower, I'm not sure, but I suspect it could be the same issue
that affected InterBase/FireBird some time ago: when Delphi 7 is compiling
without affinity limitation, it occupies both cores at about 40%, with affinity
set, I get one core at 100% (same pattern InterBase had on dual CPUs).
So it could be time wasted by compiler process/thread getting flipped constantly
between the two cores by the OS. Another possibility could be that some file
access patterns used by the compiler gets in the way of efficient disk I/O when
ran on "truly" multi-thread capable hardware.
Adjusting D7's affinity isn't really an issue (easily done in a D7 launcher),
more problematic is that debugged processes starts with the same affinity as the
debugger process, ie. if you set D7 to single-core, they'll start in
single-core, so you won't be testing them in a dual core situation...
For that, have to add some code (in the initialization section of some well
chosen unit f.i.) that will force the process affinity mask of your application
to the "systemMask" f.i. when it's being debugged.
Eric
Dave White
"Eric Grange" <egra...@SPAMglscene.org> wrote in message
news:4458f937$1...@newsgroups.borland.com...
>
> Don't doubt it a second, that's the way to go :)
> And since it's new hardware, get 64bit compatible parts and a WinXP64 Pro
(same
> price as XP32) while you're at it, the OS is just way more responsive that
XP32
> (it's as responsive as Win2k3, without having to down-tweak a server OS).
>
Thanks for the info. I had thought of using Win2k3, but never even thought
of XP64. Although all of my development will be in virtual machines, I
still need to keep all the normal corporate apps on the host CPU -
Groupwise, Novell, our Laboratory Information Management System, etc. I'll
need to look into this a little more.
Tom Corey
> Thanks for the info. I had thought of using Win2k3, but never even
> thought of XP64. Although all of my development will be in virtual
> machines, I still need to keep all the normal corporate apps on the
> host CPU - Groupwise, Novell, our Laboratory Information Management
> System, etc. I'll need to look into this a little more.
If it's strictly a business machine, XP64 should not be a problem at
all. If it's more of a personal machine, you may run into grief with
USB consumer device drivers.
I tried XP64 briefly. It ran flawlessly. However, my Palm wouldn't
sync, and iPod sync was spotty. Some software that installs items in
the Explorer context menu (e.g. WinZip) don't work with the 64-bit OS.
The software works, the context menu extensions don't. Also, no spell
checking with the 64-bit version of OE, but the 32-bit version is
included in XP64, and it works fine.
Dave White
news:xn0elsh9m...@newsgroups.borland.com...
>
> If it's strictly a business machine, XP64 should not be a problem at
> all. If it's more of a personal machine, you may run into grief with
> USB consumer device drivers.
>
This would be strictly a business machine, but I do need to connect to a USB
scanner (just plain Twain). I may hold off on the XP64 for a little while.
The beauty of running all the development stuff in virtual machines means
that if I decide to go with XP64 next year, I just need to re-install the
office apps on the C drive - everything else will be in VMs on a second
drive.
Tom Corey
> This would be strictly a business machine, but I do need to connect
> to a USB scanner (just plain Twain). I may hold off on the XP64 for
> a little while.
Check for drivers. Epson had 64-bit drivers available for my RX500
all-in-one scanner/printer, and HP Laserjet drivers were also easy to
find. Seems like recent equipment from the larger vendors is pretty
well supported on XP64.
> The beauty of running all the development stuff in
> virtual machines means that if I decide to go with XP64 next year, I
> just need to re-install the office apps on the C drive - everything
> else will be in VMs on a second drive.
Preaching to the choir :)
Captain Jake
> under
> dal core? Will they potentially run slower too?
That depends entirely on what they do and how they are architected. A
well-written multithreaded application should be faster on a dual-core
machine than it would be on a single core machine. On the other hand, a lot
of bugs in multithreaded applications that don't show up in a single core
system will crap all over a dual-core system.
Thomas Miller
Lou Feliz wrote:
> Hmm...
>
> I plan loading my D7 development environment into a VM Ware virtual machine
> and if IIRC it will be a single CPU VM. My current Dev box is a fast
> single core box with 3 gB of RAM, but my new one will be dual core w/ 4GB of
> RAM. Once Dual core box is up ad running, I will just move the VM to new
> box. Other benefit of using a VM is that I try new components in a copy of
> the VM as well as the ability to move VM to new hardware and do not have to
> worry about reinstalling Delphi again.
>
--
Thomas Miller
Chrome Portal Project Manager
Wash DC Programmers SIG Chairperson (formally Delphi)
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
http://www.bss-software.com
http://www.cpcug.org/user/delphi/index.html
http://sourceforge.net/projects/chromeportal/
http://sourceforge.net/projects/uopl/
http://sourceforge.net/projects/dbexpressplus
Eric Grange
> don't work with the 64-bit OS.
They don't work with the 64bit *explorer*, but they'll be registered for the
32bit one. If you want to fire it up, an easy way is to make a shortcut to the
32bit IEXPLORE.exe with '-e c:\' as parameters f.i.
(btw, 7-Zip has a 64bit version with a 64bit explorer plugin, I'm keeping the
32bit explorer around only for Tortoise)
There is a 64bit of TweakUI around the web (highly recommended).
Eric
Christopher Burke
days ago.
BDS 2006 now runs as well as D7 did on the original box.
I'm impressed.
Your compiled applications will run better if you write multi-threaded
applications in such a way as it supports multi-cpu.
Marco van de Voort
> I'm in the process of ordering a new development system here at the ab.
> I've been OK'd to get a nice X2 4800+ system, but now I'm not sure if that's
> the way to go. I use a single core AMD 64 at home, and that's pretty nice.
> I'm moving all of my development into virtual machines, so I thought a nice
> fast dual core with a couple of gigs of RAM would work well.
>
> Anubody have any comments on this? And how will compiled apps perform under
> dal core? Will they potentially run slower too?
The main issue is usually that equally (or even somewhat higher) priced
dual-cores run at a lower speed than the single core equivalent. Note that
a X2's "+" rating gets a significant boost because of the dualness.
A dual 2.4 Ghz 4800+ X2 with 2 MB cache costs about Eur 729 here, while
San Diego 2.4 GHz (1 MB cache, about the same per core) costs Eur 379.
I don't think they will differ much in single threaded performance.
I tuesday bought a T2300 dual core laptop (Core Duo 1.66Ghz, 2MB), and the
compiling performance (measured with FPC, but all compilers are memory
latency intensive and will be pretty similar) was pretty awful compared to a
Athlon64 3700+ (2.2MHz, single, 1MB).
There of course is also an effect because of the SMP vs single tasking
(multi CPU threading overhead), cache trashing, cache size etc, but the
above issue is afaik the largest.
In general treating the dual core as a SMP machine with two CPUs is a pretty
accurate one (though not perfect due to lower intra CPU latency).
Only when you have a multithreaded application that also really does CPU
intensive things in multiple threads, then you will see an improvement in
application performance. (assuming the system is mostly idle for the rest).
Besides this, SMP, dual core and HT (2 "logical" cores, though not physical
might all also expose additional race bugs in your software. A good example
is Indy9. Make sure you update Indy9 at least to 9.0.18.
(I haven't used Indy10 in production on Windows till now, so can't comment
on that)
So first you must characterise your workload.
Marco van de Voort
> that affected InterBase/FireBird some time ago: when Delphi 7 is compiling
> without affinity limitation, it occupies both cores at about 40%, with affinity
> set, I get one core at 100% (same pattern InterBase had on dual CPUs).
Hmm, that (the 2x 40%) is also what I see. Ok, affinity tweaking time for me
:)
Marco van de Voort
> I went from an Intel 2.8Ghz P4 (S478) to a dual core 2.8GHz (S775) a few
> days ago.
>
> BDS 2006 now runs as well as D7 did on the original box.
>
> I'm impressed.
>
> Your compiled applications will run better if you write multi-threaded
> applications in such a way as it supports multi-cpu.
Not just multithreading. There must really get significant work
paralellisable in those threads.
All to often you see apps with a lot of threads that are effectively nearly
serial due to lock-creep, or apps that do all significant work in one
thread.
The only good thing that you get then from dual core/HT/SMP is improved
thread start/stop latency and the price is the need for SMP-safe locking
Tom Corey
> They don't work with the 64bit explorer, but they'll be registered
> for the 32bit one. If you want to fire it up, an easy way is to make
> a shortcut to the 32bit IEXPLORE.exe with '-e c:\' as parameters f.i.
Oh, now you tell me. Where the heck were you months ago when I was
trying XP64? :)
> There is a 64bit of TweakUI around the web (highly recommended).
TweakUI is among the first things I install on any new system.
Joachim Römke
"Marco van de Voort" <mar...@stack.nl>
> I tuesday bought a T2300 dual core laptop (Core Duo 1.66Ghz, 2MB), and the
> compiling performance (measured with FPC, but all compilers are memory
> latency intensive and will be pretty similar) was pretty awful compared to
> a
> Athlon64 3700+ (2.2MHz, single, 1MB).
I'm using a T2300 Notebook,too.
720000 lines complette build: 10 sec
CPU1: 60-80%
CPU2: 20-40%
How much faster is the Athlon?
Jonathan Benedicto
> 720000 lines complette build: 10 sec
> CPU1: 60-80%
> CPU2: 20-40%
Lock Delphi onto one of the chips and it should compile faster.
Jonathan
Adem
>Don't doubt it a second, that's the way to go :)
>And since it's new hardware, get 64bit compatible parts and a
>WinXP64 Pro (same price as XP32) while you're at it, the OS is
>just way more responsive that XP32 (it's as responsive as
>Win2k3, without having to down-tweak a server OS).
Does anyone know if I can 'upgrade' a Win2k3 to WinXP64 Pro?
By upgrade, I mean, install over a Win2k3 without loosing the
settings.
Joachim Römke
"Jonathan Benedicto" <inv...@nobody.com> schrieb im Newsbeitrag
news:445a25f2$1...@newsgroups.borland.com...
The difference is < 1 sec. CPU1: ~100%
Achim
Chee Wee Chua (Borland Support)
>Does anyone know if I can 'upgrade' a Win2k3 to WinXP64 Pro?
No, you cannot.
Nate Walker
they'll get you set up.
Nate.
"Chee Wee Chua (Borland Support)" <cwc...@borland.com> wrote in message
news:oh9l52p1l54sqf356...@4ax.com...
Marco van de Voort
> A dual 2.4 Ghz 4800+ X2 with 2 MB cache costs about Eur 729 here, while
> San Diego 2.4 GHz (1 MB cache, about the same per core) costs Eur 379.
> I don't think they will differ much in single threaded performance.
>
> I tuesday bought a T2300 dual core laptop (Core Duo 1.66Ghz, 2MB), and the
> compiling performance (measured with FPC, but all compilers are memory
> latency intensive and will be pretty similar) was pretty awful compared to a
> Athlon64 3700+ (2.2MHz, single, 1MB).
Mea culpa. It was slower, but not much (3 1/4 min for the Athlon, 4 for the
core duo, which is not bad for the frequency and HD difference).
The trouble was that I had FreeBSD compiletimes in mind (there it is +/-
2min). The faster process-startup time on *nix compared to windows, which is
significant due to make and assorted helper bins) is the main cause for
this OS related difference.
For the good order:
- Athlon64 1MB 2200 MHz (San Diego 3700+) + 7200 rpm : 3 1/4 min
- T2300 (dual) 2MB 1666 MHz 5400 rpm hd : 4 min.
(XPsp2, 1GB mem both)
No significant gain due to dual core, but overall on par with expectations.