<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;"><DIV>Carl,</DIV>
<DIV> </DIV>
<DIV>  Let me use an (over-simplified) example for prefetching:</DIV>
<DIV> </DIV>
<DIV>/* Say, the system has 3TB RAM and for matrices A, B, C and D, each has size 1TB */</DIV>
<DIV>/* Assume simu takes a long time for large data size */</DIV>
<DIV> </DIV>
<DIV>A = load_from_database();</DIV>
<DIV>B = simu(A);</DIV>
<DIV>C = simu(B); /* With explicit prefetch support, it can start swaping out A while it computes simu(B)  */                        </DIV>
<DIV>D = load_from_database(); /* An OS paging is avoided because A is already out */</DIV>
<DIV>...</DIV>
<DIV> </DIV>
<DIV>BTW, D can also be loaded during the computation of simu(B).</DIV>
<DIV> </DIV>
<DIV>Salem</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><BR><BR>--- On <B>Fri, 8/27/10, Carl Alan Joslin <I><carl.joslin@joslinfamily.co.uk></I></B> wrote:<BR></DIV>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(16,16,255) 2px solid"><BR>From: Carl Alan Joslin <carl.joslin@joslinfamily.co.uk><BR>Subject: Re: [sac-user] My wish list for Release 2.0<BR>To: "sac user mailing list" <sac-user@sac-home.org><BR>Date: Friday, August 27, 2010, 7:19 AM<BR><BR>
<DIV class=plainMail>Well the short answer is no, SaC can not tell the difference between<BR>swap/disk and memory so it will not make 20 memory copies over 1 disk<BR>copy.<BR><BR>SaC does do a good job at reducing random access to memory.  This was<BR>done not to help with swap but to help higher up on the memory hierarchy<BR>at the cache level.  Random access to memory can also be expensive, as<BR>when you read just a byte from memory the processor reads at least the<BR>entire cache line into its cache, this then results in another line<BR>having to be moved out of the way. <BR><BR>I do agree with you that controlling things explicitly does tend to<BR>result in improved performance.  However I still can not see a use case<BR>yet on how explicit handling of the disk/memory boundary will<BR>significantly help performance.<BR><BR>Avoiding disk usage does seem to have the potential for huge benefits in<BR>performance for large working set
 problems, however I am not sure how<BR>yet.<BR><BR><BR>Carl<BR><BR>On Thu, 2010-08-26 at 20:59 -0700, Salem Reyen wrote:<BR>> Carl,<BR>> <BR>>   Since I did not actually test the Roomy, I will not claim it will<BR>> provide a better performance. I used Roomy as (not necessarily the<BR>> best) example for explicit swap control.  I think the difference<BR>> between implicit swap (via OS paging) and explicit swap (via dumping<BR>> to a file) is that the explicit swap provides the compiler a total<BR>> control of data location (to reduce random disk access) and disk swap<BR>> minimization.  I agree that SaC provides very aggressive optimization<BR>> techniques to reduce the number of memory copies.  But my question is<BR>> that can SaC distiguishes between disk copy and memory copy?  More<BR>> precisely, if there is a choice between 1 disk copy and 20 memory<BR>> copies, can SaC
 select the later one for a large size data?<BR>> <BR>> Salem <BR>> <BR>> <BR>> --- On Thu, 8/26/10, Carl Alan Joslin <<A href="http://us.mc343.mail.yahoo.com/mc/compose?to=carl.joslin@joslinfamily.co.uk" ymailto="mailto:carl.joslin@joslinfamily.co.uk">carl.joslin@joslinfamily.co.uk</A>><BR>> wrote:<BR>>         <BR>>         From: Carl Alan Joslin <<A href="http://us.mc343.mail.yahoo.com/mc/compose?to=carl.joslin@joslinfamily.co.uk" ymailto="mailto:carl.joslin@joslinfamily.co.uk">carl.joslin@joslinfamily.co.uk</A>><BR>>         Subject: Re: [sac-user] My wish list for Release 2.0<BR>>         To: "sac user mailing list" <<A href="http://us.mc343.mail.yahoo.com/mc/compose?to=sac-user@sac-home.org" ymailto="mailto:sac-user@sac-home.org">sac-user@sac-home.org</A>><BR>>     
    Date: Thursday, August 26, 2010, 11:21 AM<BR>>         <BR>>         I have only had a very quick look at roomy.  Could you explain<BR>>         in more<BR>>         detail why not just using a 64bit system with a very large<BR>>         amount swap<BR>>         spread over several disks, will not solve the problem.  SaC<BR>>         tries hard<BR>>         to minimises access to arrays to a few sequential passes of<BR>>         each array.<BR>>         Because of this I am unsure how you expect to get extra<BR>>         performance from<BR>>     
    using roomy over the swap system of your operating system.<BR>>         After just a<BR>>         couple of minutes looking at this I can only see 2^64bits of<BR>>         address<BR>>         space as the main limitation.<BR>>         <BR>>         Perhaps you could explain what I am not getting with the<BR>>         problem.<BR>>         <BR>>         Carl<BR>>         <BR>>         On Thu, 2010-08-26 at 06:23 -0700, Salem Reyen wrote:<BR>>         > I understand that SaC is just at version 1.0 and there are<BR>>     
    more things<BR>>         > which can be added.  I don't mind that SaC doesn't provide<BR>>         object<BR>>         > oriented classes (a useful features for having a cleaner<BR>>         design for<BR>>         > its graphic library),<BR>>         > lazy evaluation (to avoid loading gigantic object before its<BR>>         actual<BR>>         > usage) or eval function (to generate complex math function<BR>>         on the fly)<BR>>         > because they can be done at user level if SaC is used as an<BR>>         > intermediate language. 
 However, there is one missing<BR>>         feature that<BR>>         > cannot be done at user level:  implicit out of core support.<BR>>         That is,<BR>>         > the user doesn't have to worry about "out of memory"<BR>>         message.  To<BR>>         > reduce overhead, the compiler can minimize I/O by generating<BR>>         code that<BR>>         > can prefetch large data from the disk before its use and<BR>>         reuse the<BR>>         > data from a "cache" to avoid reloading.  Since the speed of<BR>>         solid<BR>>     
    > state drives have increased so dramatically (250MB/s to<BR>>         1.5GB/s per<BR>>         > drive), it may be practical to re-visit the "old" topics<BR>>         such as I/O<BR>>         > minimization and parallel I/O (eg, like the Roomy project<BR>>         > <A href="http://roomy.sourceforge.net/" target=_blank>http://roomy.sourceforge.net/</A>). <BR>>         > <BR>>         > Well, I am just rambling ... <BR>>         > <BR>>         > Salem <BR>>         > <BR>>         > <BR>>         > 
 <BR>>         > <BR>>         > _______________________________________________<BR>>         > sac-user mailing list<BR>>         > <A href="http://us.mc343.mail.yahoo.com/mc/compose?to=sac-user@sac-home.org" ymailto="mailto:sac-user@sac-home.org">sac-user@sac-home.org</A><BR>>         > <A href="http://lists.sac-home.org/mailman/listinfo.cgi/sac-user" target=_blank>http://lists.sac-home.org/mailman/listinfo.cgi/sac-user</A><BR>>         <BR>>         _______________________________________________<BR>>         sac-user mailing list<BR>>         <A href="http://us.mc343.mail.yahoo.com/mc/compose?to=sac-user@sac-home.org"
 ymailto="mailto:sac-user@sac-home.org">sac-user@sac-home.org</A><BR>>         <A href="http://lists.sac-home.org/mailman/listinfo.cgi/sac-user" target=_blank>http://lists.sac-home.org/mailman/listinfo.cgi/sac-user</A><BR>>         <BR>> <BR>> _______________________________________________<BR>> sac-user mailing list<BR>> <A href="http://us.mc343.mail.yahoo.com/mc/compose?to=sac-user@sac-home.org" ymailto="mailto:sac-user@sac-home.org">sac-user@sac-home.org</A><BR>> <A href="http://lists.sac-home.org/mailman/listinfo.cgi/sac-user" target=_blank>http://lists.sac-home.org/mailman/listinfo.cgi/sac-user</A><BR><BR>_______________________________________________<BR>sac-user mailing list<BR><A href="http://us.mc343.mail.yahoo.com/mc/compose?to=sac-user@sac-home.org" ymailto="mailto:sac-user@sac-home.org">sac-user@sac-home.org</A><BR><A
 href="http://lists.sac-home.org/mailman/listinfo.cgi/sac-user" target=_blank>http://lists.sac-home.org/mailman/listinfo.cgi/sac-user</A><BR></DIV></BLOCKQUOTE></td></tr></table><br>