Jump to content
Ian Branch

PC Specs for Delphi??

Recommended Posts

Hi Team,

Apologies if this isn't the correct place for this.

The PC that we develop on has evolved significantly since Delphi 1.

We now have multi core, multi thread processors, SSDs, etc, etc.

My question is..  What spec/hardware characteristic of a PC has the most benefit/impact on the performance on the IDE?

Is it RAM speed, SSD speed, CPU Cores, etc?  I currently run Win 11 with D11, 32GP RAM , fast SSD, 6core I7.

Regardless of the spec of my existing PC, what is the single change can I make to my PC that will have the most impact/improvement to the performance of the IDE.

I suspect this will be like 'what is the best code editor?' question. 🙂

 

Regards & TIA,

Ian

Share this post


Link to post

Given enough RAM to dedicated to the O/S and at a few GB left over for apps, I think NVMe drives are rediculously fast and can be the best $-per-wow spent.  They can read 7,000+ MB/s and write nearly as fast.  They will put a pep in your step.  I'm using Intel, but I see a Seagate Firecuda 530 with 7,300 MB/s sequential read and 6,900 MB/s seq. write which is enticing.

 

Share this post


Link to post

Tks Darian,

I use NVME drives and I have 32GB RAM.

I note, according to the Win 11 Task Manager, that Delphi uses about 10-12% of the CPU when loading and then 0% idling.

When I do a build it jumps back up, peaking at around 21%. 

Strangely, the Task Manager suggests this is 'Very High' Power usage.  Huh?

 

Ian

Edited by Ian Branch

Share this post


Link to post

This sounds about right. Doing compiles is like flooring the pedal in your car at a stop light when the light turns green.

 

I run Delphi inside of VirtualBox on my Mac, which has 36GB of RAM, a 6-core i7 CPU, and 2TB of SSD. The odd-numbered cores all go to about 80% when I do a compile that takes more than a few seconds.

 

There's always a "weakest link" no matter how fast everything runs.  If you'r CPU isn't saturated, then your RAM or DISK is limiting things to some extent. And who knows what's going on with the GPU during compiles!

Share this post


Link to post

Hi David,

Thanks for your input to the discussion.

When I build a project group my CPU2 goes to around 80%-90%, the rest around 10-25%.

 

Ian

Share this post


Link to post
14 minutes ago, Ian Branch said:

I use NVME drives and I have 32GB RAM.

I note, according to the Win 11 Task Manager, that Delphi uses about 10-12% of the CPU when loading and then 0% idling.

When I do a build it jumps back up, peaking at around 21%. 

Strangely, the Task Manager suggests this is 'Very High' Power usage.  Huh?

 

Ian

NVMe drives ... SATA or PCIe?   I have a PCIe... Samsung 970 EVO with 3500 MB/s Read and an older Samsung SSD 960 PRO with 2100 MB/s.  These are fast, but apparently they can get twice as fast as that now.  Might need to get a Christmas present to myself...

32GB of RAM should be plenty.  If builds are only peaking 21% CPU then you are probably maxed out there too.  You should be pretty speedy already.   

 

There are software optimizations... like Excluding your source and output folders from Antivirus.  

 

  • Like 1

Share this post


Link to post
27 minutes ago, Darian Miller said:

There are software optimizations... like Excluding your source and output folders from Antivirus.  

Ahh.  Hadn't thought along those lines.  Will have a look.

PCIE - Samsung 980s.

Share this post


Link to post

Having a fast SSD doesn't hurt, nor does it hurt to have source and output on different drives, but I wish I could get a CPU that had a core that could be clocked really high, since the compilers mostly are single core intensive.

 

  • Like 1

Share this post


Link to post

cnPack has a setting to set the IDE to CPU 0.

Anybody got any thoughts on the benefit or otherwise of this?

Share this post


Link to post

Well that's a No-No.  What normally takes 3 and a bit minutes was still going 14 minutes later... 😞

Share this post


Link to post
23 minutes ago, Ian Branch said:

cnPack has a setting to set the IDE to CPU 0.

Anybody got any thoughts on the benefit or otherwise of this?

Why would this be useful? It's invariably best to let the system schedule threads. If you are going to do it manually then you probably need to schedule all compute threads manually. Forcing one thread to a specific processor without taking care of other threads in the system will just lead to contention. 

  • Like 1

Share this post


Link to post
27 minutes ago, Ian Branch said:

cnPack has a setting to set the IDE to CPU 0.

I can only imagine that this might be useful for debugging some particular IDE or IDE plugin bugs/oddities. Nothing you should use for day to day work.

Share this post


Link to post
4 minutes ago, dummzeuch said:

I can only imagine that this might be useful for debugging some particular IDE or IDE plugin bugs/oddities. Nothing you should use for day to day work.

How could that be useful? The OS is known to manage context switches correctly. 

Share this post


Link to post

Regarding specs: Windows 10 seems to have some very efficient caching algorithm which means that given enough RAM it doesn't really matter whether your IDE or your Sources are on a hard disk or an SSD.

 

An SSD mostly affects the boot time and the first start of a program / first loading of a file. (As said above: Given enough RAM. As the saying goes: RAM can be only be replaced with more RAM.)

 

On RAM constricted systems, the effect of an SSD might be more significant.

 

At least that's my impression, I haven't measured it.

Share this post


Link to post
Just now, David Heffernan said:

How could that be useful? The OS is known to manage context switches correctly. 

Sorry, I can't read the mind of the cnpack developers. I was just trying to come up with a reason why somebody went to the trouble of implementing this. It might also be ancient, maybe to address something in Windows 95 or NT4 and Delphi 3, who knows?

 

Which reminds me of something: In the olden days, when a CPU only had one core, before hyperthreading and when computers with more than one CPU were very expensive, I happened to get my hands on a dual CPU computer. I found several bugs in our Delphi programs the never occurred on other machines. Basically these were race conditions that could only happen if code was really executed in parallel, not simply multi tasked on a single CPU.

Share this post


Link to post
2 minutes ago, David Heffernan said:

Didn't support multi threading IIRC

Hm, yes. Good thing I also mentioned NT 4 then.

Share this post


Link to post
26 minutes ago, dummzeuch said:

Good thing I also mentioned NT 4 then.

Which is why I didn't quote NT4 ofc

Share this post


Link to post

 

40 minutes ago, David Heffernan said:
43 minutes ago, dummzeuch said:

Windows 95

Didn't support multi threading IIRC

The closest it came, was non-preemptive multitasking.

https://en.wikipedia.org/wiki/Cooperative_multitasking

 

But, DPMI allowed you do actual concurrent programming. I had true multitasking COM port threads in some of my Borland Pascal DOS apps.

Share this post


Link to post
8 hours ago, Lars Fosdal said:

Having a fast SSD doesn't hurt, nor does it hurt to have source and output on different drives, but I wish I could get a CPU that had a core that could be clocked really high, since the compilers mostly are single core intensive.

 

Like a few THz? 😉

Share this post


Link to post
8 hours ago, Lars Fosdal said:

The closest it came, was non-preemptive multitasking.

https://en.wikipedia.org/wiki/Cooperative_multitasking

From your link:

Quote

Cooperative multitasking was the primary scheduling scheme for 16-bit applications employed by Microsoft Windows before Windows 95 and Windows NT [...] Windows 9x used non-preemptive multitasking for 16-bit legacy applications

(emphasis mine)

 

So that would mean Windows 95 had preemptive multitasking for 32 bit programs. I'm not sure though, I never really used it.

 

Windows 3.x used cooperative multitasking for Windows programs, but preemptive multitasking for DOS programs. Of that I am sure because I used and programmed for it.

  • Like 1

Share this post


Link to post
18 hours ago, Ian Branch said:

Regardless of the spec of my existing PC, what is the single change can I make to my PC that will have the most impact/improvement to the performance of the IDE.

Turn off all and every virus-scanning thingies during work!

 

15 hours ago, Darian Miller said:

There are software optimizations... like Excluding your source and output folders from Antivirus.

Sometimes it's scary how much faster stuff gets done. IDE/Compiler/installations write [big] exe files (and other "watched" stuff) so that is key.

 

Darian, i have not tried that. A much better approach than turning stuff off. If i get the time i'll see if it gets me up to the same efficiency.

Share this post


Link to post
1 hour ago, dummzeuch said:

So that would mean Windows 95 had preemptive multitasking for 32 bit programs.

So far as I remember you could not install Win95 on multi processor machines. We'll, you could but only one processor would be used. 

Share this post


Link to post

I want to remember that 3.1 and 95 was an actual application that was loaded with a MS-DOS script/.bat. But it was some time ago.

Share this post


Link to post
1 hour ago, Dany Marmur said:

Turn off all and every virus-scanning thingies during work!

May not be possible in a corporate environment.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×