<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Carl,<br><br>  I am more than grateful for you to patiently reply every one of my emails.  I think that I owe you an explanation of why I keep dragging you into this annoyingly long discussion.  From a user's perspective in array programming, there are two major "bottlenecks" which mostly ignored by computer scientists (especially in compiler group):<br><br>1. Memory Optimization:  "Out of memory" is perhaps the most scary message for a user because this usually indicates that he/she has to rewrite the program entirely in order to refit the data into memory.  Rewriting is a very bad thing for a language to be used for fast prototyping.  The current "solution" (in most statistical packages for example) is to either provide user some functions to manually dump (partial) memory image to a disk or an automatically scheme of dumping the
 result back to a disk after each function call.  This "solution" of course generates insane amout of I/O overhead.  I agree that O/S paging to an array of  fast disks could be the simplest solution but it still cannot prevent paging from inside of a loop.<br><br>2. Loop Vectorization/Parallization:  I've been using MKL since its first release and I'm currently learning to write SaC without using any for-do-while loop.  Unfortunately, although writing code in a vectorized fashion will give the compiler/hardware the best chance to optimize, there is a practical pitfall associated with this.  That is, by overly vectorizing the code, it often makes the code very counterintuitive, unreadable or even error prone.  And this is the reason why many users (especially in science/engineering communities) still prefer to write code in a traditional for-do-while loops fashion.  There are literatures proposing using loop pattern
 matching where the patterns are stored in a dictionay.  However, I have not yet seen an actual implementation on this.  And this is the reason why I ask if SaC provides a transformation from a for-do-while loop to a with-loop.<br><br>I apologize for sending you another long email.<br><br>Salem<br><br>P.S. I'll wait until I finish the translator and I hope by then I can provide you more concrete examples to show memory optimization and serial loop transformation can drastically boost performance in many cases. <br>   <br>--- On <b>Fri, 8/27/10, Carl Alan Joslin <i><carl.joslin@joslinfamily.co.uk></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><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, 9:57
 AM<br><br><div class="plainMail">This still has no need for SaC to know the difference between memory and<br>disk.<br><br>The function SQL could be anything. In your example all that matters is<br>that the function returns a large result and takes a long time.  It<br>could read something from a network, from sensors, or even just perform<br>some large calculation.<br><br>All you have is a need for functional concurrency.  Work is even<br>underway to add functional concurrency to SaC.<br><br>There is however one problem that are planed implementation of<br>functional concurrency will is not planed to support and that is<br>bounding the exposed concurrency based on available memory.<br><br>Carl<br><br>On Fri, 2010-08-27 at 06:28 -0700, Salem Reyen wrote:<br>> Carl,<br>>  <br>>   Here is even simplier example:<br>>  <br>>   for (i = 0; i < 100; i++) {<br>>      A =
 SQL(Database[i]); /* Loading data from the database i (which<br>> is stored at a disk)  based on some SQL statement and, say, it takes 1<br>> hour */<br>>      B  = roots_of_linear_equation(A); /* O(n^3) operations and, say,<br>> it takes 1 hour */<br>>    }<br>>  <br>> Now, without I/O optimization, it will take 200 hours to complete.<br>> However, with I/O<br>> optimization, the loop can transformed into (using OpenMP for<br>> example);<br>>  <br>>   for(i = 0; i < 100; i++) {<br>>      A = SQL(Database[i]);<br>>      /* OpenMP parallel region */<br>>     #pragma omp sections { <br>>        #pragma omp section {<br>>          if (i < 100) A = SQL(Database[i + 1]);<br>>       }<br>>   
    #pragma omp section {<br>>          B  = roots_of_linear_equation(A);<br>>       }<br>>   }<br>>  <br>>   And the time is reduced to 101 hours.  <br>>  <br>> Salem<br>> <br>> --- On Fri, 8/27/10, Carl Alan Joslin <<a ymailto="mailto:carl.joslin@joslinfamily.co.uk" href="/mc/compose?to=carl.joslin@joslinfamily.co.uk">carl.joslin@joslinfamily.co.uk</a>><br>> wrote:<br>> <br>>         <br>>         From: Carl Alan Joslin <<a ymailto="mailto:carl.joslin@joslinfamily.co.uk" href="/mc/compose?to=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 ymailto="mailto:sac-user@sac-home.org" href="/mc/compose?to=sac-user@sac-home.org">sac-user@sac-home.org</a>><br>>         Date: Friday, August 27, 2010, 8:39 AM<br>>         <br>>         Where are you using the disk?  Are you saying that the<br>>         compiler adds the<br>>         load_from_database() its self?<br>>         <br>>         I can see that there is the potential to reduce memory usage<br>>         by delaying<br>>         the load_from_database() rather than having it at the start.<br>>         There is<br>>         no technical reason I can think of that SaC
 could not move<br>>         load_from_database() calls around.  However to be able to do<br>>         this it<br>>         must be statically possible for SaC to work out the memory<br>>         size of most<br>>         of the variables in your program.<br>>         <br>>         This is some what different to what we where discussing.  This<br>>         is about<br>>         moving external calls around so that SaC makes the smallest<br>>         demands on<br>>         memory.<br>>         <br>>         We could take
 this back to the disk memory discussion.<br>>         <br>>         In this case you have a "database"/disk that you put your<br>>         arrays into<br>>         when they will not be needed for a while then take them back<br>>         out later<br>>         when they are needed again.  Do you have an example of a<br>>         program that<br>>         needs to compute large arrays, does something that depends on<br>>         the values<br>>         of the arrays that takes a long time and then needs the<br>>         original array<br>>         again, where
 the time to compute them is greater than the time<br>>         to save<br>>         them to disk and load them back again.<br>>         <br>>         Carl<br>>         <br>>         On Fri, 2010-08-27 at 05:08 -0700, Salem Reyen wrote:<br>>         > Carl,<br>>         >  <br>>         >   Let me use an (over-simplified) example for prefetching:<br>>         >  <br>>         > /* Say, the system has 3TB RAM and for matrices A, B, C<br>>         > and D, each has size 1TB */<br>>     
    > /* Assume simu takes a long time for large data size */<br>>         >  <br>>         > A = load_from_database();<br>>         > B = simu(A);<br>>         > C = simu(B); /* With explicit prefetch support, it can start<br>>         swaping<br>>         > out A while it computes simu(B)  */                        <br>>         > D = load_from_database(); /* An OS paging is avoided because<br>>         A is<br>>         > already out */<br>>         > ...<br>>         > 
 <br>>         > BTW, D can also be loaded during the computation of simu(B).<br>>         >  <br>>         > Salem<br>>         >  <br>>         >  <br>>         >  <br>>         >  <br>>         >  <br>>         >  <br>>         > <br>>         > <br>>         > --- On Fri, 8/27/10, Carl Alan Joslin <MailScanner has<br>>         detected a possible fraud attempt from<br>>         "us.mc343.mail.yahoo.com" claiming to be
 MailScanner has<br>>         detected a possible fraud attempt from<br>>         "us.mc343.mail.yahoo.com" claiming to be<br>>         <a ymailto="mailto:carl.joslin@joslinfamily.co.uk" href="/mc/compose?to=carl.joslin@joslinfamily.co.uk">carl.joslin@joslinfamily.co.uk</a>><br>>         > wrote:<br>>         > <br>>         >         <br>>         >         From: Carl Alan Joslin <MailScanner has detected a<br>>         possible fraud attempt from "us.mc343.mail.yahoo.com" claiming<br>>         to be MailScanner has detected a possible fraud attempt from<br>>     
    "us.mc343.mail.yahoo.com" claiming to be<br>>         <a ymailto="mailto:carl.joslin@joslinfamily.co.uk" href="/mc/compose?to=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" <MailScanner has<br>>         detected a possible fraud attempt from<br>>         "us.mc343.mail.yahoo.com" claiming to be MailScanner has<br>>         detected a possible fraud attempt from<br>>         "us.mc343.mail.yahoo.com" claiming to be<br>>         <a
 ymailto="mailto:sac-user@sac-home.org" href="/mc/compose?to=sac-user@sac-home.org">sac-user@sac-home.org</a>><br>>         >         Date: Friday, August 27, 2010, 7:19 AM<br>>         >         <br>>         >         Well the short answer is no, SaC can not tell the<br>>         difference<br>>         >         between<br>>         >         swap/disk and memory so it will not make 20 memory<br>>         copies over<br>>         >         1 disk<br>>     
    >         copy.<br>>         >         <br>>         >         SaC does do a good job at reducing random access to<br>>         memory.<br>>         >         This was<br>>         >         done not to help with swap but to help higher up on<br>>         the memory<br>>         >         hierarchy<br>>         >         at the cache level.  Random access to memory can<br>>         also be<br>>   
      >         expensive, as<br>>         >         when you read just a byte from memory the processor<br>>         reads at<br>>         >         least the<br>>         >         entire cache line into its cache, this then results<br>>         in another<br>>         >         line<br>>         >         having to be moved out of the way. <br>>         >         <br>>         >     
    I do agree with you that controlling things<br>>         explicitly does<br>>         >         tend to<br>>         >         result in improved performance.  However I still can<br>>         not see a<br>>         >         use case<br>>         >         yet on how explicit handling of the disk/memory<br>>         boundary will<br>>         >         significantly help performance.<br>>         >         <br>>     
    >         Avoiding disk usage does seem to have the potential<br>>         for huge<br>>         >         benefits in<br>>         >         performance for large working set problems, however<br>>         I am not<br>>         >         sure how<br>>         >         yet.<br>>         >         <br>>         >         <br>>         >         Carl<br>>     
    >         <br>>         >         On Thu, 2010-08-26 at 20:59 -0700, Salem Reyen<br>>         wrote:<br>>         >         > Carl,<br>>         >         > <br>>         >         >   Since I did not actually test the Roomy, I will<br>>         not claim<br>>         >         it will<br>>         >         > provide a better performance. I used Roomy as (not<br>>         >   
      necessarily the<br>>         >         > best) example for explicit swap control.  I think<br>>         the<br>>         >         difference<br>>         >         > between implicit swap (via OS paging) and explicit<br>>         swap (via<br>>         >         dumping<br>>         >         > to a file) is that the explicit swap provides the<br>>         compiler a<br>>         >         total<br>>     
    >         > control of data location (to reduce random disk<br>>         access) and<br>>         >         disk swap<br>>         >         > minimization.  I agree that SaC provides very<br>>         aggressive<br>>         >         optimization<br>>         >         > techniques to reduce the number of memory copies.<br>>         But my<br>>         >         question is<br>>         >         >
 that can SaC distiguishes between disk copy and<br>>         memory copy?<br>>         >         More<br>>         >         > precisely, if there is a choice between 1 disk<br>>         copy and 20<br>>         >         memory<br>>         >         > copies, can SaC select the later one for a large<br>>         size data?<br>>         >         > <br>>         >         > Salem <br>>         >     
    > <br>>         >         > <br>>         >         > --- On Thu, 8/26/10, Carl Alan Joslin <MailScanner<br>>         has<br>>         >         detected a possible fraud attempt from<br>>         >         "us.mc343.mail.yahoo.com" claiming to be MailScanner<br>>         has<br>>         >         detected a possible fraud attempt from<br>>         >         "us.mc343.mail.yahoo.com" claiming to be<br>>         >     
    MailScanner has detected a possible fraud attempt<br>>         from "us.mc343.mail.yahoo.com" claiming to be MailScanner has<br>>         detected a possible fraud attempt from<br>>         "us.mc343.mail.yahoo.com" claiming to be<br>>         <a ymailto="mailto:carl.joslin@joslinfamily.co.uk" href="/mc/compose?to=carl.joslin@joslinfamily.co.uk">carl.joslin@joslinfamily.co.uk</a>><br>>         >         > wrote:<br>>         >         >         <br>>         >         >         From: Carl Alan Joslin <MailScanner has<br>>   
      detected a<br>>         >         possible fraud attempt from<br>>         "us.mc343.mail.yahoo.com" claiming<br>>         >         to be MailScanner has detected a possible fraud<br>>         attempt from<br>>         >         "us.mc343.mail.yahoo.com" claiming to be<br>>         >         MailScanner has detected a possible fraud attempt<br>>         from "us.mc343.mail.yahoo.com" claiming to be MailScanner has<br>>         detected a possible fraud attempt from<br>>         "us.mc343.mail.yahoo.com"
 claiming to be<br>>         <a ymailto="mailto:carl.joslin@joslinfamily.co.uk" href="/mc/compose?to=carl.joslin@joslinfamily.co.uk">carl.joslin@joslinfamily.co.uk</a>><br>>         >         >         Subject: Re: [sac-user] My wish list for<br>>         Release 2.0<br>>         >         >         To: "sac user mailing list" <MailScanner<br>>         has<br>>         >         detected a possible fraud attempt from<br>>         >         "us.mc343.mail.yahoo.com" claiming to be MailScanner<br>>     
    has<br>>         >         detected a possible fraud attempt from<br>>         >         "us.mc343.mail.yahoo.com" claiming to be<br>>         >         MailScanner has detected a possible fraud attempt<br>>         from "us.mc343.mail.yahoo.com" claiming to be MailScanner has<br>>         detected a possible fraud attempt from<br>>         "us.mc343.mail.yahoo.com" claiming to be<br>>         <a ymailto="mailto:sac-user@sac-home.org" href="/mc/compose?to=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<br>>         roomy.  Could<br>>         >         you explain<br>>         >         >         in more<br>>         >         >         detail why not just using a 64bit system<br>>         with a very<br>>         > 
        large<br>>         >         >         amount swap<br>>         >         >         spread over several disks, will not solve<br>>         the<br>>         >         problem.  SaC<br>>         >         >         tries hard<br>>         >         >         to minimises access to arrays to a few<br>>         sequential<br>>         >     
    passes of<br>>         >         >         each array.<br>>         >         >         Because of this I am unsure how you expect<br>>         to get<br>>         >         extra<br>>         >         >         performance from<br>>         >         >         using roomy over the swap system of your<br>>         operating<br>>         >     
    system.<br>>         >         >         After just a<br>>         >         >         couple of minutes looking at this I can<br>>         only see<br>>         >         2^64bits of<br>>         >         >         address<br>>         >         >         space as the main limitation.<br>>         >         >         <br>>     
    >         >         Perhaps you could explain what I am not<br>>         getting with<br>>         >         the<br>>         >         >         problem.<br>>         >         >         <br>>         >         >         Carl<br>>         >         >         <br>>         >         >     
    On Thu, 2010-08-26 at 06:23 -0700, Salem<br>>         Reyen<br>>         >         wrote:<br>>         >         >         > I understand that SaC is just at version<br>>         1.0 and<br>>         >         there are<br>>         >         >         more things<br>>         >         >         > which can be added.  I don't mind that<br>>         SaC doesn't<br>>     
    >         provide<br>>         >         >         object<br>>         >         >         > oriented classes (a useful features for<br>>         having a<br>>         >         cleaner<br>>         >         >         design for<br>>         >         >         > its graphic library),<br>>         >         >     
    > lazy evaluation (to avoid loading<br>>         gigantic object<br>>         >         before its<br>>         >         >         actual<br>>         >         >         > usage) or eval function (to generate<br>>         complex math<br>>         >         function<br>>         >         >         on the fly)<br>>         >         >     
    > because they can be done at user level<br>>         if SaC is<br>>         >         used as an<br>>         >         >         > intermediate language.  However, there<br>>         is one<br>>         >         missing<br>>         >         >         feature that<br>>         >         >         > cannot be done at user level:  implicit<br>>         out of<br>>     
    >         core support.<br>>         >         >         That is,<br>>         >         >         > the user doesn't have to worry about<br>>         "out of<br>>         >         memory"<br>>         >         >         message.  To<br>>         >         >         > reduce overhead, the compiler can<br>>         minimize I/O by<br>>     
    >         generating<br>>         >         >         code that<br>>         >         >         > can prefetch large data from the disk<br>>         before its<br>>         >         use and<br>>         >         >         reuse the<br>>         >         >         > data from a "cache" to avoid reloading.<br>>         Since the<br>>     
    >         speed of<br>>         >         >         solid<br>>         >         >         > state drives have increased so<br>>         dramatically<br>>         >         (250MB/s to<br>>         >         >         1.5GB/s per<br>>         >         >         > drive), it may be practical to re-visit<br>>         the "old"<br>>     
    >         topics<br>>         >         >         such as I/O<br>>         >         >         > minimization and parallel I/O (eg, like<br>>         the Roomy<br>>         >         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>>         _______________________________________________<br>>         >         >         > sac-user mailing list<br>>         >         >         > MailScanner has detected a possible<br>>         fraud attempt<br>>         >         from "us.mc343.mail.yahoo.com" claiming to be<br>>         MailScanner has<br>>         >         detected a possible fraud attempt from<br>>     
    >         "us.mc343.mail.yahoo.com" claiming to be MailScanner<br>>         has detected a possible fraud attempt from<br>>         "us.mc343.mail.yahoo.com" claiming to be MailScanner has<br>>         detected a possible fraud attempt from<br>>         "us.mc343.mail.yahoo.com" claiming to be <a ymailto="mailto:sac-user@sac-home.org" href="/mc/compose?to=sac-user@sac-home.org">sac-user@sac-home.org</a><br>>         >         >         ><br>>         ><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>>         >         >         MailScanner has detected a possible fraud<br>>         attempt<br>>         >         from "us.mc343.mail.yahoo.com" claiming to be<br>>     
    MailScanner has<br>>         >         detected a possible fraud attempt from<br>>         >         "us.mc343.mail.yahoo.com" claiming to be MailScanner<br>>         has detected a possible fraud attempt from<br>>         "us.mc343.mail.yahoo.com" claiming to be MailScanner has<br>>         detected a possible fraud attempt from<br>>         "us.mc343.mail.yahoo.com" claiming to be <a ymailto="mailto:sac-user@sac-home.org" href="/mc/compose?to=sac-user@sac-home.org">sac-user@sac-home.org</a><br>>         >         ><br>>         ><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>>         >         > MailScanner has detected a possible fraud attempt<br>>         from<br>>         >         "us.mc343.mail.yahoo.com" claiming to
 be MailScanner<br>>         has<br>>         >         detected a possible fraud attempt from<br>>         >         "us.mc343.mail.yahoo.com" claiming to be MailScanner<br>>         has detected a possible fraud attempt from<br>>         "us.mc343.mail.yahoo.com" claiming to be MailScanner has<br>>         detected a possible fraud attempt from<br>>         "us.mc343.mail.yahoo.com" claiming to be <a ymailto="mailto:sac-user@sac-home.org" href="/mc/compose?to=sac-user@sac-home.org">sac-user@sac-home.org</a><br>>         >         ><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>>         >         MailScanner has detected a possible fraud attempt<br>>         from<br>>         >         "us.mc343.mail.yahoo.com" claiming to be MailScanner<br>>         has<br>>         >         detected a possible
 fraud attempt from<br>>         >         "us.mc343.mail.yahoo.com" claiming to be MailScanner<br>>         has detected a possible fraud attempt from<br>>         "us.mc343.mail.yahoo.com" claiming to be MailScanner has<br>>         detected a possible fraud attempt from<br>>         "us.mc343.mail.yahoo.com" claiming to be <a ymailto="mailto:sac-user@sac-home.org" href="/mc/compose?to=sac-user@sac-home.org">sac-user@sac-home.org</a><br>>         ><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>>         > MailScanner has detected a possible fraud attempt from<br>>         "us.mc343.mail.yahoo.com" claiming to be MailScanner has<br>>         detected a possible fraud attempt from<br>>         "us.mc343.mail.yahoo.com" claiming to be <a ymailto="mailto:sac-user@sac-home.org" href="/mc/compose?to=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>>         MailScanner has detected a possible fraud attempt from<br>>         "us.mc343.mail.yahoo.com" claiming to be MailScanner has<br>>         detected a possible fraud attempt from<br>>         "us.mc343.mail.yahoo.com" claiming to be <a ymailto="mailto:sac-user@sac-home.org" href="/mc/compose?to=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 ymailto="mailto:sac-user@sac-home.org" href="/mc/compose?to=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 ymailto="mailto:sac-user@sac-home.org" href="/mc/compose?to=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>