[sac-user] My wish list for Release 2.0

Salem Reyen salemreyen at yahoo.com
Fri Aug 27 05:59:10 CEST 2010


  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?


--- 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.


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

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

More information about the sac-user mailing list