Re: a question

[Patrik Jonsson]

One more thing: if the exact same run varies in runtime by that much,
that's a system issue. On the same machine, the same run should take
pretty much exactly the same time each time.

Different snapshots, on the other hand, can vary dramatically in
runtime because of different numbers of grid cells and different
optical depths.

On Fri, Feb 22, 2013 at 8:54 PM, Patrik Jonsson
<sun...@familjenjonsson.org> wrote:
> Sunrise has an unpredictable memory access pattern, so on the SGI
> machines you very quickly become limited by memory latency due to the
> NUMAlink network that connects the nodes. It won't scale to very many
> nodes. There is not much disk I/O. Apart from that, it's very hard to
> say something general, it depends on the particular machine and the
> use case. Tuning parallel computations is an art, I'd suggest you get
> familiar with the profiling tools your system has and try to
> understand this yourself.
>
> On Fri, Feb 22, 2013 at 11:09 AM, mohammad safarzadeh
> <mtsafa...@gmail.com> wrote:
>> Dear Patrik,
>> I asked this question on the group, I wanted to know your opinion on this
>> issue.
>>
>> I am running a test run , and I see that a day it takes 32 hours to finish
>> the run and in another day 48 hours is not enough!
>> I contacted the people on the machine which is shared memory
>> http://www.princeton.edu/researchcomputing/computational-hardware/machine-3/
>> and they told me that you are I/O bound and asked me these question:
>>
>> If you are I/O bound, are you doing your I/O in large chunks?
>>
>> Have you profiled you code to figure out where it might be spending all
>> the time?
>>
>> How much data does your job read? How much does it write? When does
>> it do either (all at the beginning and end, or throughout execution)?
>> These kinds of things can affect start time, end time, and general
>> execution time.