Large test spreadsheets

Hello,

do you guys know where i can get large spreadsheets (that
take a very
long time to process) so i can use it for profiling? My idea
is to
identify parts of the code that can be changed to exploit
paralellism
(i'm using OpenMP).

Cheers, Lorotta
_______________________________________________
gnumeric-list mailing list
gnumeric-listgnome.org

http://mail.gnome.org/mailman/listinfo/gnumeric-list

On Sun, Jun 8, 2008 at 8:33 PM, bla blabla
<chico.lorottagmail.com> wrote:
> Hello,
>
> do you guys know where i can get large spreadsheets
(that take a very
> long time to process) so i can use it for profiling? My
idea is to
> identify parts of the code that can be changed to
exploit paralellism
> (i'm using OpenMP).

The traditional way of getting such sheets is to take some
formulas and
replicate then hundreds or thousands of times.  That is not
particularly
useful to you as it will tell you that when replicated
enough times, the
functions you use take up a lot of time.

Parallelism in a spreadsheet falls naturally at the level of
cells: different
cells can, in principle, be computed by different threads as
they by and
large are independent.  Actually implementing this will not
be easy.

Morten
_______________________________________________
gnumeric-list mailing list
gnumeric-listgnome.org

http://mail.gnome.org/mailman/listinfo/gnumeric-list

Hello everyone,

you can find a nasty spreadsheet at:
http://www.openoffice.org/issues/show_bug.cgi?id=89976


In general, optimizing a spreadsheet for parallel processing
is not that easy, because
you will likely end waiting most of the time for other cells
to compute first and/or
recomputing various cels multiple times instead of once.

In an effort to move away from puting the burden on the
developers, I began
designing functions that would compute intrinsically faster
by expanding
existing functions to array functions:
 - PERCENTILE():
   http://lists.oasis-open.org/archives/off
ice-comment/200806/msg00011.html

 - LOOKUP() and OFFSET()-functions will follow when I have
some more time

Though, there is still a long way to improve existing
spreadsheets. The ultimate
goal is to make the spreadsheet more vector-like: a good
solution is the
multidimensional spreadsheet model.

Sincerely,

Leonard


-------- Original-Nachricht --------
> Datum: Tue, 10 Jun 2008 11:35:54 -0400
> Von: "Morten Welinder" <mwelindergmail.com>
> An: "bla blabla" <chico.lorottagmail.com>
> CC: gnumeric-listgnome.org
> Betreff: Re: Large test spreadsheets

> On Sun, Jun 8, 2008 at 8:33 PM, bla blabla
<chico.lorottagmail.com>
> wrote:
> > Hello,
> >
> > do you guys know where i can get large
spreadsheets (that take a very
> > long time to process) so i can use it for
profiling? My idea is to
> > identify parts of the code that can be changed to
exploit paralellism
> > (i'm using OpenMP).
> 
> The traditional way of getting such sheets is to take
some formulas and
> replicate then hundreds or thousands of times.  That is
not particularly
> useful to you as it will tell you that when replicated
enough times, the
> functions you use take up a lot of time.
> 
> Parallelism in a spreadsheet falls naturally at the
level of cells:
> different
> cells can, in principle, be computed by different
threads as they by and
> large are independent.  Actually implementing this will
not be easy.
> 
> Morten
> _______________________________________________
> gnumeric-list mailing list
> gnumeric-listgnome.org
> 
http://mail.gnome.org/mailman/listinfo/gnumeric-list

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu
sparen! 
Ideal für Modem und ISDN: http://www.gmx.n
et/de/go/smartsurfer
_______________________________________________
gnumeric-list mailing list
gnumeric-listgnome.org

http://mail.gnome.org/mailman/listinfo/gnumeric-list

> In an effort to move away from puting the burden on the
developers, I began
> designing functions that would compute intrinsically
faster by expanding
> existing functions to array functions:
>  - PERCENTILE():
>   http://lists.oasis-open.org/archives/off
ice-comment/200806/msg00011.html
>
>  - LOOKUP() and OFFSET()-functions will follow when I
have some more time

I went another route with VLOOKUP/HLOOKUP/MATCH in very
recent versions of Gnumeric.  Basically, if the range is
shared --
and that is quite common -- then lots of preprocessing of
the range
is shared between cells.

I do not think there is a need to bother the user of the
spreadsheet
with this.  If we discover (real-life) sheets where such
repetitive
formulas using a common table cause serious problems, then
it is
not hard to fix.

Morten
_______________________________________________
gnumeric-list mailing list
gnumeric-listgnome.org

http://mail.gnome.org/mailman/listinfo/gnumeric-list

Hello Morten, hello everyone,


Morten Welinder wrote:
>> In an effort to move away from puting the burden on
the developers, I began
>> designing functions that would compute
intrinsically faster by expanding
>> existing functions to array functions:
>>  - PERCENTILE():
>>   http://lists.oasis-open.org/archives/off
ice-comment/200806/msg00011.html
>>
>>  - LOOKUP() and OFFSET()-functions will follow when
I have some more time
>>     
>
> I went another route with VLOOKUP/HLOOKUP/MATCH in
very
> recent versions of Gnumeric.  Basically, if the range
is shared --
> and that is quite common -- then lots of preprocessing
of the range
> is shared between cells.
>   

Indeed, the range is most often shared for these functions.
This is the 
reason for my array-function proposal, like:
= { VLOOKUP( array1, range2, ...) }

In essence, my intention is to make existing spreadsheets
more like 
multidimensional spreadsheets so as to benefit from the
advantages of a 
multidimensional model: the user will basically define
generic relations 
between the dimensions (where dimension = column), and not
between 
individual cells.
e.g. [column D] = VLOOKUP( [column A], [sheetX!column X],
... )

Actually, I plan a more powerful replacement to the 
LOOKUP/OFFSET-functions, in order to solve the user's needs
without 
putting the emphasis on the user to solve the problem (let
the 
spreadsheet solve it elegantly and mostly automatically).

Sincerely,

Leonard

> I do not think there is a need to bother the user of
the spreadsheet
> with this.  If we discover (real-life) sheets where
such repetitive
> formulas using a common table cause serious problems,
then it is
> not hard to fix.
>
> Morten
>
>   

_______________________________________________
gnumeric-list mailing list
gnumeric-listgnome.org

http://mail.gnome.org/mailman/listinfo/gnumeric-list