[sac-user] My wish list for Release 2.0

Salem Reyen salemreyen at yahoo.com
Fri Aug 27 14:08:20 CEST 2010


Carl,
 
  Let me use an (over-simplified) example for prefetching:
 
/* Say, the system has 3TB RAM and for matrices A, B, C and D, each has size 1TB */
/* Assume simu takes a long time for large data size */
 
A = load_from_database();
B = simu(A);
C = simu(B); /* With explicit prefetch support, it can start swaping out A while it computes simu(B)  */                        
D = load_from_database(); /* An OS paging is avoided because A is already out */
...
 
BTW, D can also be loaded during the computation of simu(B).
 
Salem
 
 
 
 
 
 


--- On Fri, 8/27/10, Carl Alan Joslin <carl.joslin at joslinfamily.co.uk> wrote:


From: Carl Alan Joslin <carl.joslin at joslinfamily.co.uk>
Subject: Re: [sac-user] My wish list for Release 2.0
To: "sac user mailing list" <sac-user at sac-home.org>
Date: Friday, August 27, 2010, 7:19 AM


Well the short answer is no, SaC can not tell the difference between
swap/disk and memory so it will not make 20 memory copies over 1 disk
copy.

SaC does do a good job at reducing random access to memory.  This was
done not to help with swap but to help higher up on the memory hierarchy
at the cache level.  Random access to memory can also be expensive, as
when you read just a byte from memory the processor reads at least the
entire cache line into its cache, this then results in another line
having to be moved out of the way. 

I do agree with you that controlling things explicitly does tend to
result in improved performance.  However I still can not see a use case
yet on how explicit handling of the disk/memory boundary will
significantly help performance.

Avoiding disk usage does seem to have the potential for huge benefits in
performance for large working set problems, however I am not sure how
yet.


Carl

On Thu, 2010-08-26 at 20:59 -0700, Salem Reyen wrote:
> Carl,
> 
>   Since I did not actually test the Roomy, I will not claim it will
> provide a better performance. I used Roomy as (not necessarily the
> best) example for explicit swap control.  I think the difference
> between implicit swap (via OS paging) and explicit swap (via dumping
> to a file) is that the explicit swap provides the compiler a total
> control of data location (to reduce random disk access) and disk swap
> minimization.  I agree that SaC provides very aggressive optimization
> techniques to reduce the number of memory copies.  But my question is
> that can SaC distiguishes between disk copy and memory copy?  More
> precisely, if there is a choice between 1 disk copy and 20 memory
> copies, can SaC select the later one for a large size data?
> 
> Salem 
> 
> 
> --- On Thu, 8/26/10, Carl Alan Joslin <carl.joslin at joslinfamily.co.uk>
> wrote:
>         
>         From: Carl Alan Joslin <carl.joslin at joslinfamily.co.uk>
>         Subject: Re: [sac-user] My wish list for Release 2.0
>         To: "sac user mailing list" <sac-user at sac-home.org>
>         Date: Thursday, August 26, 2010, 11:21 AM
>         
>         I have only had a very quick look at roomy.  Could you explain
>         in more
>         detail why not just using a 64bit system with a very large
>         amount swap
>         spread over several disks, will not solve the problem.  SaC
>         tries hard
>         to minimises access to arrays to a few sequential passes of
>         each array.
>         Because of this I am unsure how you expect to get extra
>         performance from
>         using roomy over the swap system of your operating system.
>         After just a
>         couple of minutes looking at this I can only see 2^64bits of
>         address
>         space as the main limitation.
>         
>         Perhaps you could explain what I am not getting with the
>         problem.
>         
>         Carl
>         
>         On Thu, 2010-08-26 at 06:23 -0700, Salem Reyen wrote:
>         > I understand that SaC is just at version 1.0 and there are
>         more things
>         > which can be added.  I don't mind that SaC doesn't provide
>         object
>         > oriented classes (a useful features for having a cleaner
>         design for
>         > its graphic library),
>         > lazy evaluation (to avoid loading gigantic object before its
>         actual
>         > usage) or eval function (to generate complex math function
>         on the fly)
>         > because they can be done at user level if SaC is used as an
>         > intermediate language.  However, there is one missing
>         feature that
>         > cannot be done at user level:  implicit out of core support.
>         That is,
>         > the user doesn't have to worry about "out of memory"
>         message.  To
>         > reduce overhead, the compiler can minimize I/O by generating
>         code that
>         > can prefetch large data from the disk before its use and
>         reuse the
>         > data from a "cache" to avoid reloading.  Since the speed of
>         solid
>         > state drives have increased so dramatically (250MB/s to
>         1.5GB/s per
>         > drive), it may be practical to re-visit the "old" topics
>         such as I/O
>         > minimization and parallel I/O (eg, like the Roomy project
>         > http://roomy.sourceforge.net/). 
>         > 
>         > Well, I am just rambling ... 
>         > 
>         > Salem 
>         > 
>         > 
>         >  
>         > 
>         > _______________________________________________
>         > sac-user mailing list
>         > sac-user at sac-home.org
>         > http://lists.sac-home.org/mailman/listinfo.cgi/sac-user
>         
>         _______________________________________________
>         sac-user mailing list
>         sac-user at sac-home.org
>         http://lists.sac-home.org/mailman/listinfo.cgi/sac-user
>         
> 
> _______________________________________________
> sac-user mailing list
> sac-user at sac-home.org
> http://lists.sac-home.org/mailman/listinfo.cgi/sac-user

_______________________________________________
sac-user mailing list
sac-user at sac-home.org
http://lists.sac-home.org/mailman/listinfo.cgi/sac-user



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sac-home.org/pipermail/sac-user/attachments/20100827/d8806f21/attachment-0002.html>


More information about the sac-user mailing list