[sac-user] My wish list for Release 2.0

Salem Reyen salemreyen at yahoo.com
Fri Aug 27 15:28:12 CEST 2010


Carl,
 
  Here is even simplier example:
 
  for (i = 0; i < 100; i++) {
     A = SQL(Database[i]); /* Loading data from the database i (which is stored at a disk)  based on some SQL statement and, say, it takes 1 hour */
     B  = roots_of_linear_equation(A); /* O(n^3) operations and, say, it takes 1 hour */
   }
 
Now, without I/O optimization, it will take 200 hours to complete.  However, with I/O
optimization, the loop can transformed into (using OpenMP for example);
 
  for(i = 0; i < 100; i++) {
     A = SQL(Database[i]);
     /* OpenMP parallel region */
    #pragma omp sections { 
       #pragma omp section {
         if (i < 100) A = SQL(Database[i + 1]);
      }
      #pragma omp section {
         B  = roots_of_linear_equation(A);
      }
  }
 
  And the time is reduced to 101 hours.  
 
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, 8:39 AM


Where are you using the disk?  Are you saying that the compiler adds the
load_from_database() its self?

I can see that there is the potential to reduce memory usage by delaying
the load_from_database() rather than having it at the start.  There is
no technical reason I can think of that SaC could not move
load_from_database() calls around.  However to be able to do this it
must be statically possible for SaC to work out the memory size of most
of the variables in your program.

This is some what different to what we where discussing.  This is about
moving external calls around so that SaC makes the smallest demands on
memory.

We could take this back to the disk memory discussion.

In this case you have a "database"/disk that you put your arrays into
when they will not be needed for a while then take them back out later
when they are needed again.  Do you have an example of a program that
needs to compute large arrays, does something that depends on the values
of the arrays that takes a long time and then needs the original array
again, where the time to compute them is greater than the time to save
them to disk and load them back again.

Carl

On Fri, 2010-08-27 at 05:08 -0700, Salem Reyen wrote:
> 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 <MailScanner has
>         detected a possible fraud attempt from
>         "us.mc343.mail.yahoo.com" claiming to be MailScanner has
>         detected a possible fraud attempt from
>         "us.mc343.mail.yahoo.com" claiming to be
>         carl.joslin at joslinfamily.co.uk>
>         > wrote:
>         >         
>         >         From: Carl Alan Joslin <MailScanner has detected a
>         possible fraud attempt from "us.mc343.mail.yahoo.com" claiming
>         to be MailScanner has detected a possible fraud attempt from
>         "us.mc343.mail.yahoo.com" claiming to be
>         carl.joslin at joslinfamily.co.uk>
>         >         Subject: Re: [sac-user] My wish list for Release 2.0
>         >         To: "sac user mailing list" <MailScanner has
>         detected a possible fraud attempt from
>         "us.mc343.mail.yahoo.com" claiming to be MailScanner has
>         detected a possible fraud attempt from
>         "us.mc343.mail.yahoo.com" claiming to be
>         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
>         >         > MailScanner has detected a possible fraud attempt
>         from "us.mc343.mail.yahoo.com" claiming to be MailScanner has
>         detected a possible fraud attempt from
>         "us.mc343.mail.yahoo.com" claiming to be sac-user at sac-home.org
>         >         >
>         http://lists.sac-home.org/mailman/listinfo.cgi/sac-user
>         >         
>         >         _______________________________________________
>         >         sac-user mailing list
>         >         MailScanner has detected a possible fraud attempt
>         from "us.mc343.mail.yahoo.com" claiming to be MailScanner has
>         detected a possible fraud attempt from
>         "us.mc343.mail.yahoo.com" claiming to be sac-user at sac-home.org
>         >
>            http://lists.sac-home.org/mailman/listinfo.cgi/sac-user
>         >         
>         > 
>         > _______________________________________________
>         > sac-user mailing list
>         > MailScanner has detected a possible fraud attempt from
>         "us.mc343.mail.yahoo.com" claiming to be MailScanner has
>         detected a possible fraud attempt from
>         "us.mc343.mail.yahoo.com" claiming to be sac-user at sac-home.org
>         > http://lists.sac-home.org/mailman/listinfo.cgi/sac-user
>         
>         _______________________________________________
>         sac-user mailing list
>         MailScanner has detected a possible fraud attempt from
>         "us.mc343.mail.yahoo.com" claiming to be MailScanner has
>         detected a possible fraud attempt from
>         "us.mc343.mail.yahoo.com" claiming to be 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/d6d0284b/attachment-0002.html>


More information about the sac-user mailing list