Hey All,
I have just run some tests.
Firstly I ran a simulation with the model on my 1TB Drive. It took 10min 30 seconds.
Then I ran the exact simulation off my SSD. It also took 10min 30 seconds.
Why would there be no benefit in simulations from going from a 120MB/s drive to a theoretical max 500 - 520MB/s drive?
Also the simulations aren't much shorter on my i7 pc compared to a dual core i5 laptop......
IES seems to be the least scalable program I have used.
Has any one had any decent gains in using SSD's over normal hard drives and having a faster cpu etc
No Difference in simulation speed on SSD or 1TB drive.
-
Marc Jensen
- VE Graduate

- Posts: 92
- Joined: Mon Jan 28, 2013 3:51 am
No Difference in simulation speed on SSD or 1TB drive.
Regards,
Marc Jensen,
Marc Jensen,
Re: No Difference in simulation speed on SSD or 1TB drive.
I guess the reason would be that your SSD drive is only going to help out programs that are hitting the hard drive all the time.
The majority of the time IES is using CPU and memory and NOT writing to the hard drive so you aren't going to be seeing much performance improvement.
Zap
The majority of the time IES is using CPU and memory and NOT writing to the hard drive so you aren't going to be seeing much performance improvement.
Zap
Re: No Difference in simulation speed on SSD or 1TB drive.
oh - IES isn't multi-threaded or 64 bit so that fancy CPU isn't going to help out that much. Use Task Manager to dedicate the ve.exe module to one particular core and up the priority level.
Zap
Zap
-
Marc Jensen
- VE Graduate

- Posts: 92
- Joined: Mon Jan 28, 2013 3:51 am
Re: No Difference in simulation speed on SSD or 1TB drive.
Thanks,
I realise it is not multithreaded and needs an update for that asap.
I will give that a go with one core. However I have noticed that every now and again the ve.exe swaps what core it uses. interesting.
I know that Flucs-Pro and Microflo, Radiance sensor calcs are multi - cpu but nothing else is ...
I wish IES would properly load up the hardware as each time I press simulate, you cant help thinking that it could be much faster!
I realise it is not multithreaded and needs an update for that asap.
I will give that a go with one core. However I have noticed that every now and again the ve.exe swaps what core it uses. interesting.
I know that Flucs-Pro and Microflo, Radiance sensor calcs are multi - cpu but nothing else is ...
I wish IES would properly load up the hardware as each time I press simulate, you cant help thinking that it could be much faster!
Regards,
Marc Jensen,
Marc Jensen,
Re: No Difference in simulation speed on SSD or 1TB drive.
yeh I'm pretty sure there's plenty of scope for speeding things up and utilizing multi-threading.
The Flucs/Radiance sensor calcs and CFD Engine (although that might have been reversed) have a limited multi-core ability. Problem with Apache is that each time step needs to know the result of the previous timestep so you cant just hive the days out. The sub timestep calcs could be though. Suncast is the one place I'd really like to see multi-threading... it could split the 24*12 calcs out and recombine the results file at the end... or put the results into an SQL database and there's no need for any sequential file to be created at all.
I guess it just asks Windows for a thread to run on and is in no control over what processor it uses itself. I've seen a mild decrease in simulation time if I set the affinity and up the priority - then re-direct other processes away from that core but it's not anything impressive.
The Flucs/Radiance sensor calcs and CFD Engine (although that might have been reversed) have a limited multi-core ability. Problem with Apache is that each time step needs to know the result of the previous timestep so you cant just hive the days out. The sub timestep calcs could be though. Suncast is the one place I'd really like to see multi-threading... it could split the 24*12 calcs out and recombine the results file at the end... or put the results into an SQL database and there's no need for any sequential file to be created at all.
I guess it just asks Windows for a thread to run on and is in no control over what processor it uses itself. I've seen a mild decrease in simulation time if I set the affinity and up the priority - then re-direct other processes away from that core but it's not anything impressive.
-
Marc Jensen
- VE Graduate

- Posts: 92
- Joined: Mon Jan 28, 2013 3:51 am
Re: No Difference in simulation speed on SSD or 1TB drive.
I agree with suncast. It could theoretically utilize full system resources however that would require one month sections to be allocated to each cpu. In that case the top of the line Intel Cpus could simulate the entire year worth of sun one month in each thread all at once due to their capability of running 12 sequential threads. Improvements like that really get me going!
If following your methodology for calculations, I believe the following format of processing would improve simulation speed markedly, if implemented.
Take an i7 Quad Core with HyperThreading for example: 8 threads.
Cores 1 - 8 all used in sequential order on individual steps for simulations.
I will call each core a number such as Core 1 as 1...
Step 1: 1 starts simulations
Step 2: 1 orders first hour/day/week (Block) for simulation so that 2-8 can sequentially start some part of the calculations and checking.
Step 3: 2 simulates the first block whilst 1 checks with previously simulated data/ time step so it knows the last result
Step 4: three cores or two cores work in unison to check previous data with recently simulated data. once checked and verified with no errors, the next block is completed, with the other group taking the next sequential block to work.
step 5: the next group takes the previous groups blocks into simulation and compares with its and the final core 8 combines and smoothes data.
Now obviously this would at most increase the speed by around 2x - 3x
if implemented in such a way that the final core/s do not have excessive workload in smoothing etc. And as always the lower the timestep the better the accuracy of this simulation method.
As I am not a software guru with limited experience this could be a complete hash but the theory is there and if my explanation works/ is legible then i will be happy.
The best method to simulate would to use 3 cores,
1 checks previous data, 2 simulates block, 3 checks and prepares next block.
Probably would speed up the process by up to 3x if perfect but more like 1.5x - 2x but would be much more accurate compared to the previously mentioned technique.
At this stage I think that any improvements would be beneficial:)
If following your methodology for calculations, I believe the following format of processing would improve simulation speed markedly, if implemented.
Take an i7 Quad Core with HyperThreading for example: 8 threads.
Cores 1 - 8 all used in sequential order on individual steps for simulations.
I will call each core a number such as Core 1 as 1...
Step 1: 1 starts simulations
Step 2: 1 orders first hour/day/week (Block) for simulation so that 2-8 can sequentially start some part of the calculations and checking.
Step 3: 2 simulates the first block whilst 1 checks with previously simulated data/ time step so it knows the last result
Step 4: three cores or two cores work in unison to check previous data with recently simulated data. once checked and verified with no errors, the next block is completed, with the other group taking the next sequential block to work.
step 5: the next group takes the previous groups blocks into simulation and compares with its and the final core 8 combines and smoothes data.
As I am not a software guru with limited experience this could be a complete hash but the theory is there and if my explanation works/ is legible then i will be happy.
1 checks previous data, 2 simulates block, 3 checks and prepares next block.
Probably would speed up the process by up to 3x if perfect but more like 1.5x - 2x but would be much more accurate compared to the previously mentioned technique.
At this stage I think that any improvements would be beneficial:)
Regards,
Marc Jensen,
Marc Jensen,
