headers
Schloegl Alois | 4 Jan 2004 21:15
Picon
Favicon

Re: file offsets used by fseek and ftell

Zitat von "John W. Eaton" <jwe <at> bevo.che.wisc.edu>:

> On 21-Nov-2003, JD Cole <listguy <at> transientresearch.com> wrote:
>
> | Could this be accomplished using a 64-bit (long long). If I'm
> | not totally off base, that may be a better solution.
>
> With gcc 3.4, streamoff and streampos are classes that hold 64-bit
> ints (either long long or int64_t).  But they are not simple typedefs
> for either of these types, so it is still not possible to write
> something like
>
>   streampos pos = ...;
>
>   long long ftell_retval = (long long) pos;
>
> because there is no way to cast a streampos or streamoff type to an
> integer.
>
> For portability, we can't assume that these types are any particular
> integer value.  Different systems are free to implement streamoff and
> streampos (or fpos_t if you are using C) in any way they choose
> (provided that they meet the rather limited constraints of the
> respective standards).

According to your suggestion in
http://www.octave.org/mailing-lists/bug-octave/2003/474
, I'd like to continue the discussion.

In summary the above statement says, it is not possible to check the position of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Kienzle | 6 Jan 2004 04:30
Picon

benchmarks


Paul Thomas pointed me to these benchmarks.  Anybody want to do
something about them?

	http://www.sciviews.org/other/benchmark.htm

Speed is relative to R.  Note that he didn't test on a variety of 
matrices,
so the result may represent random perturbations in the generated
matrices rather than any real difference between the systems.

============================
I.A   Matlab 0.48 : Octave 2.01

   tic;
     a = abs(randn(1500, 1500)/10);
     b = a';
     a = reshape(b, 750, 3000);
     b = a';
   timing = toc;

Octave's random number generators are slower than they need
to be.  octave-forge helps, but there are even better ones available.
E.g., http://www.jstatsoft.org/v05/i08/

I've written to the author asking for permission to release it under
an GPL compatible license, but didn't get a response.  I haven't
had time to recode it in my own words.  It'll be tricky since the paper
contains the source code.
(Continue reading)

Permalink | Reply | 29 comments |
headers
David Bateman | 6 Jan 2004 10:16

Re: benchmarks

Paul,

> ============================
> I.A   Matlab 0.48 : Octave 2.01
> 
>   tic;
>     a = abs(randn(1500, 1500)/10);
>     b = a';
>     a = reshape(b, 750, 3000);
>     b = a';
>   timing = toc;
> 
> Octave's random number generators are slower than they need
> to be.  octave-forge helps, but there are even better ones available.
> E.g., http://www.jstatsoft.org/v05/i08/
> 
> I've written to the author asking for permission to release it under
> an GPL compatible license, but didn't get a response.  I haven't
> had time to recode it in my own words.  It'll be tricky since the paper
> contains the source code.

I don't think these tests will take octave-forge into account, so speed 
increases in octave-forge won't show up in these tests. This is a good
justification to get the randon generator code from octave-forge into 
octave itself.

> I.D Matlab 0.73 - Octave 0.35 -  R 0.24
>     b = a'*a;
> 
> Octave could be faster if it skipped the transpose and used blas
(Continue reading)

Permalink | Reply | 2 comments |
headers
Schloegl Alois | 6 Jan 2004 11:21
Picon
Favicon

Re: benchmarks - sort

Zitat von Paul Kienzle <pkienzle <at> users.sourceforge.net>:

>
> Paul Thomas pointed me to these benchmarks.  Anybody want to do
> something about them?
>
> 	http://www.sciviews.org/other/benchmark.htm
>

...

>
> I.C Matlab 0.89  - Octave 7.77
>      b = sort(a);
>
> Octave's sort is surprisingly slow.  3x worse than any other package
> mentioned.  Anyone know a fast stable sort algorithm?
>

One reason, for the bad performance of the sort algorithm might be the exception
handling of NaNs. See also
http://www.octave.org/octave-lists/archive/bug-octave.2001/msg00047.html

Sorting on the binary level might be helpful, because the bit patterns of the
IEEE754 numbers provide the correct sorting order. This is
-inf < -1 < 0 < 1 < inf < NaN

Just my few thougths.

Alois
(Continue reading)

Permalink | Reply | 3 comments |
headers
John W. Eaton | 6 Jan 2004 16:33
Picon

Re: benchmarks (rand)

On  6-Jan-2004, David Bateman <David.Bateman <at> motorola.com> wrote:

| I don't think these tests will take octave-forge into account, so speed 
| increases in octave-forge won't show up in these tests. This is a good
| justification to get the randon generator code from octave-forge into 
| octave itself.

People will likely complain if we change the default generator since
it may change the results of some simulations.  So I think we either
need to keep the current generator as the default or at least keep it
as an alternative to support old code that needs to generate the same
set of numbers for reproducible results.

jwe
Permalink | Reply | 0 comments |
headers
John W. Eaton | 6 Jan 2004 16:39
Picon

Re: benchmarks

On  6-Jan-2004, David Bateman <David.Bateman <at> motorola.com> wrote:

| > I.D Matlab 0.73 - Octave 0.35 -  R 0.24
| >     b = a'*a;
| > 
| > Octave could be faster if it skipped the transpose and used blas
| > directly with the appropriate transpose code.   Note, the tester
| > did not use a self-generated atlas, so these results don't mean
| > much.
| 
| This is a lot of work and cruft foe a small gain. You'd have to pass
| ', *, and '* differently. Then you'd have to create a new function for
| the transpose multiply. Is it worth it?

You don't have to recognize the sequence of operators.  Instead, you
can just tag a matrix as transposed without actually doing the
operation until it is really needed, then you can pass that
information to the LAPACK and BLAS routines, or simply access the
elements differently when indexing (or displaying).  But this means
adding significant complexity to the matrix and array classes (and any
code using them that asks for the data directly), which is why I
decided early on that it was probably better to have transpose do the
operation immediately by copying.

jwe
Permalink | Reply | 0 comments |
headers
John W. Eaton | 6 Jan 2004 16:43
Picon

benchmarks

On  5-Jan-2004, Paul Kienzle <pkienzle <at> users.sourceforge.net> wrote:

| I.B Matlab 0.42  - Octave 1.22
|      b = a.^1000;
| 
| Looking at the source, Octave is using indexing for every element.
| Try replacing the nested for loop and indexing with a call to
| data and directly walking the array.  Bonus, it automatically works
| for n-D arrays.

Yes.  It would be helpful if people could identify the places like
this that need changing and either submit patches or at least report
the location of the code that needs to be updated.

Thanks,

jwe
Permalink | Reply | 0 comments |
headers
John W. Eaton | 6 Jan 2004 16:47
Picon

packages (was: benchmarks)

On  5-Jan-2004, Paul Kienzle <pkienzle <at> users.sourceforge.net> wrote:

| BTW, moving more stuff from octave-forge to octave,
| and providing a CRAN-like list of available packages
| will help make octave look more complete.  This has
| to be linked directly from the octave home page so that
| people can find it.

Agreed.  It would help if someone with some experience with packaging
systems could help design and possibly implement something for
Octave.  I don't think it needs to be complicated, and doesn't have to
handle binary packages.  If you want to install a package that uses
.oct files, then I think it is OK to expect that you will have to
build them when you install the package.  Anything else will be too
difficult for us to maintain (too many different
version/OS/etc. combinations to expect success).

jwe
Permalink | Reply | 1 comment |
headers
John W. Eaton | 6 Jan 2004 16:50
Picon

Re: benchmarks - sort

On  6-Jan-2004, Schloegl Alois <alois.schloegl <at> tugraz.at> wrote:

| One reason, for the bad performance of the sort algorithm might be the exception
| handling of NaNs. See also
| http://www.octave.org/octave-lists/archive/bug-octave.2001/msg00047.html
| 
| Sorting on the binary level might be helpful, because the bit patterns of the
| IEEE754 numbers provide the correct sorting order. This is
| -inf < -1 < 0 < 1 < inf < NaN

Can you explain precisely what you mean by sorting on the binary
level?

jwe
Permalink | Reply | 1 comment |
headers
Schloegl Alois | 6 Jan 2004 20:38
Picon
Favicon

Re: benchmarks - sort

Zitat von "John W. Eaton" <jwe <at> bevo.che.wisc.edu>:

> On  6-Jan-2004, Schloegl Alois <alois.schloegl <at> tugraz.at> wrote:
>
> | One reason, for the bad performance of the sort algorithm might be the
> exception
> | handling of NaNs. See also
> | http://www.octave.org/octave-lists/archive/bug-octave.2001/msg00047.html
> |
> | Sorting on the binary level might be helpful, because the bit patterns of
> the
> | IEEE754 numbers provide the correct sorting order. This is
> | -inf < -1 < 0 < 1 < inf < NaN
>
> Can you explain precisely what you mean by sorting on the binary
> level?
>
> jwe
>

Instead of floating point comparison, one could use integer comparision.
Because the exponent is in the Most Significant Bytes, a comparison based

This would require casting floating point numbers into integers (signed long
long should do), and casting does not take any effort in C.

Alois
Permalink | Reply | 0 comments |

Gmane