run time performance of scientific computing applications - Minix

This is a discussion on run time performance of scientific computing applications - Minix ; Hi all, I am new to minix3. I admired its fast booting and design filosophy. I was searching for alternatives for my everyday developing and computing because I have the feeling that Linux is becoming more and more chaotic. So ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 22

Thread: run time performance of scientific computing applications

  1. run time performance of scientific computing applications

    Hi all,
    I am new to minix3. I admired its fast booting and design filosophy. I
    was searching
    for alternatives for my everyday developing and computing because I
    have the feeling
    that Linux is becoming more and more chaotic. So I installed minix3 and
    went ahead
    to measure its performance on scientific computing codes which are
    really numerically
    intesive codes.

    I tried to run a piece of code I wrote to test how minix3 would
    perform. This piece of code
    is one of the most basic kernels of numerical methods for solving large
    sparse systems
    of equations using iterative methods, and I use it from time to time
    for testing new OS.
    It performs a sparse matrix vector multiplication.

    This forum doesn't give me the opportunity to attach any files so I
    will just copy paste the
    code and the file I used. The minix3 performance was awful as it
    concerns the multiplication,
    part. The reading of the matrix was slighlty worse than that of Linux
    and this is affordable
    because the filesystems have different architecture.

    I compiled with:

    # gcc -O2 sparsematrixbench-minix.c -o run

    and then run the command:

    #./run matrix.txt 1000000

    The last number is the number of iterations the mutliplication should
    be repeated. Below you can
    take a look at the results; the numbers represent milliseconds.

    multiplication
    Linux: 35
    minix3: 1033

    As you see the difference is dramatic. Moreover with a very large
    matrix of 20604953 bytes
    minix spits a memory fault error, while with smaller matrices 5031972
    bytes and less it
    does fine. I am attaching the matrix file I used for the test. If
    somebody is interested could
    you tell me please where can I attach the big matrix .tar.bz2 such that
    you can track the
    problem for yourself?

    ### file matrix.txt ###
    # exclude this header from the file such that the first line in the
    file
    # starts with the numbers below

    3
    3
    5
    0
    2
    4
    5
    0
    2
    1
    2
    2
    1
    1
    2
    2
    3

    And below you can see the code I used:

    // file sparsematrixbench-minix.c
    #include
    #include
    #include "sys/time.h"

    typedef struct
    {
    int nrows;
    int ncols;
    int nonzeros;
    int* pRows;
    int* pCols;
    double* pData;
    } SparseMatrix;

    typedef struct
    {
    struct timeval begin;
    struct timeval end;
    /* struct timezone zone; */
    double timePassed;
    } TimeStruct;

    void tick(TimeStruct* ts)
    {
    /* gettimeofday(&ts->begin, &ts->zone); */
    gettimeofday(&ts->begin, NULL);
    }

    void tack(TimeStruct* ts)
    {
    /* gettimeofday(&ts->end, &ts->zone); */
    gettimeofday(&ts->end, NULL);
    ts->timePassed =
    1000.0 * (ts->end.tv_sec - ts->begin.tv_sec) +
    (ts->end.tv_usec - ts->begin.tv_usec) / 1000.0;
    }

    void timeNeeded(TimeStruct* ts, const char* label)
    {
    printf("%s took %8.4f milliseconds\n", label, ts->timePassed);
    }

    void init(SparseMatrix* pmatrix, char* filename)
    {
    int i;

    /* open the filename */
    FILE* matrixfile;
    matrixfile = fopen(filename, "r");

    if (matrixfile == (FILE*) NULL)
    {
    printf("File I/O Error: Cannot access file %s.\n", filename);
    return ;
    }
    printf("Opening %s ...\n", filename);

    /* read nrows, ncols, nonzeros */
    char numberstr[80];
    fgets(numberstr, 80, matrixfile);
    sscanf(numberstr, "%d", &pmatrix->nrows);
    fgets(numberstr, 80, matrixfile);
    sscanf(numberstr, "%d", &pmatrix->ncols);
    fgets(numberstr, 80, matrixfile);
    sscanf(numberstr, "%d", &pmatrix->nonzeros);

    pmatrix->pRows = (int*) malloc((pmatrix->nrows+1)*sizeof(int));
    pmatrix->pCols = (int*) malloc(pmatrix->nonzeros*sizeof(int));
    pmatrix->pData = (double*)
    malloc(pmatrix->nonzeros*sizeof(double));

    printf("reading row pointers\n");
    /* read the row index pointer pRows */
    for (i = 0; i < pmatrix->nrows+1; i++)
    {
    fgets(numberstr, 80, matrixfile);
    sscanf(numberstr, "%d", &pmatrix->pRows[i]);
    }
    printf("reading columns\n");
    /* read the column index pointer pCols */
    for (i = 0; i < pmatrix->nonzeros; i++)
    {
    fgets(numberstr, 80, matrixfile);
    sscanf(numberstr, "%d", &pmatrix->pCols[i]);
    }
    printf("reading nonzeros\n");
    /* read the data index pointer pData */
    for (i = 0; i < pmatrix->nonzeros; i++)
    {
    fgets(numberstr, 80, matrixfile);
    sscanf(numberstr, "%lf", &pmatrix->pData[i]);
    /* printf("[%d] %lf\n", i, pmatrix->pData[i]);*/
    }
    printf("nonzeros read successfully\n");
    /* close file */
    fclose(matrixfile);
    printf("file read succesfully\n");
    }

    void multiply(SparseMatrix* pmatrix, double* x, double* b)
    {
    double sum;
    int i, j, index, from, to, n;
    n = pmatrix->nrows;

    for (i = 0; i < n; i++)
    {
    from = pmatrix->pRows[i];
    to = pmatrix->pRows[i+1];
    sum = 0.0;
    for (index = from; index < to; index++)
    {
    j = pmatrix->pCols[index];
    sum += pmatrix->pData[index]*x[j];
    }

    b[i] = sum;
    }
    }

    void release(SparseMatrix* pmatrix)
    {
    free(pmatrix->pRows);
    free(pmatrix->pCols);
    free(pmatrix->pData);
    }

    int main(int argc, char** argv)
    {
    if (argc != 3)
    {
    printf("usage: %s sparsematrixfile iterations\n", argv[0]);
    exit(1);
    }

    /* for timing purposes */
    TimeStruct secs;

    /* declare a new SparseMatrix object */
    SparseMatrix matrix;

    /* this is the vector the matrix is applied on */
    double* x;

    /* and this is the vector which holds the result of the */
    /* multiplication */
    double* b;

    /* this variable holds the dimension of the matrix */
    int i, iter, n;

    /* this variable suggest how many times the multiplication will be
    */
    /* repeated */
    int iters;

    /* initialize the matrix from the input file */
    tick(&secs);
    init(&matrix, argv[1]);
    tack(&secs);
    timeNeeded(&secs, "sparse matrix file reading");
    /* retrieve the number of iterations from the command line */
    iters = (int) strtol(argv[2], NULL, 0);

    /* retrieve the leading dimension of the matrix */
    n = matrix.nrows;

    /* allocate memory for the vectors */
    x = (double*) malloc(n*sizeof(double));
    b = (double*) malloc(n*sizeof(double));

    /* initialize the vector x by arbitrary numbers */
    for (i = 0; i < n; i++)
    {
    x[i] = 3.0*(double)i+2.0;
    }

    /* perform multiplication #iter times */

    tick(&secs);
    for (iter = 0; iter < iters; iter++)
    {
    multiply(&matrix, x, b);
    }
    tack(&secs);
    timeNeeded(&secs, "sparse matrix vector multiplication");

    free(b);
    free(x);

    release(&matrix);

    return 0;
    }

    Cheers!
    Archwn.


  2. Re: run time performance of scientific computing applications

    > This forum doesn't give me the opportunity to attach any files so I
    > will just copy paste the
    > code and the file I used. The minix3 performance was awful as it
    > concerns the multiplication,
    > part. The reading of the matrix was slighlty worse than that of Linux
    > and this is affordable
    > because the filesystems have different architecture.


    This is no surprise. Minix does not support floating point operations,
    so every floating point operation is emulated rather than being
    executed on the FPU embeded in your CPU. Performance will therefore be
    only a small fraction of operating systems that do support floating
    point.

    See also http://www.minix3.org/doc/environ.html, section "Q: Why is OS
    support needed for MMX or floating point math?".

  3. Re: run time performance of scientific computing applications


    Avatar Zondertau wrote:
    > > This forum doesn't give me the opportunity to attach any files so I
    > > will just copy paste the
    > > code and the file I used. The minix3 performance was awful as it
    > > concerns the multiplication,
    > > part. The reading of the matrix was slighlty worse than that of Linux
    > > and this is affordable
    > > because the filesystems have different architecture.

    >
    > This is no surprise. Minix does not support floating point operations,
    > so every floating point operation is emulated rather than being
    > executed on the FPU embeded in your CPU. Performance will therefore be
    > only a small fraction of operating systems that do support floating
    > point.
    >
    > See also http://www.minix3.org/doc/environ.html, section "Q: Why is OS
    > support needed for MMX or floating point math?".


    Well, I do care about a realiable operating system with a simple and
    stable Kernel
    (not the chaotic Linux kernel) which I could use for heavy numerical
    stuff. Do you
    think Minix will ever provide support for math387, MMX, SSE, SSE2,
    SSE3, 3DNOW e.t.c,
    as all the OS around?


  4. Re: run time performance of scientific computing applications

    > > This is no surprise. Minix does not support floating point
    > > operations, so every floating point operation is emulated rather
    > > than being executed on the FPU embeded in your CPU. Performance
    > > will therefore be only a small fraction of operating systems that
    > > do support floating point.
    > >
    > > See also http://www.minix3.org/doc/environ.html, section "Q: Why is
    > > OS support needed for MMX or floating point math?".

    >
    > Well, I do care about a realiable operating system with a simple and
    > stable Kernel
    > (not the chaotic Linux kernel) which I could use for heavy numerical
    > stuff. Do you
    > think Minix will ever provide support for math387, MMX, SSE, SSE2,
    > SSE3, 3DNOW e.t.c,
    > as all the OS around?


    The post in the FAQ dates back from 2003, so from before Minix 3. Since
    the goals now are more than just education, perhaps you may be able to
    convince someone (or you could do it yourself) to add FP/MMX/SSE
    support to Minix.

    ISTM the list of stuff to do mentioned in the post is accurate, but i
    suppose that the compilers (ACK, GCC) should also be changed to use
    native FPU instructions rather than calling a software FPU library. I
    suppose this involves only setting a flag and recompiling.


  5. Re: run time performance of scientific computing applications


    Avatar Zondertau wrote:
    > > > This is no surprise. Minix does not support floating point
    > > > operations, so every floating point operation is emulated rather
    > > > than being executed on the FPU embeded in your CPU. Performance
    > > > will therefore be only a small fraction of operating systems that
    > > > do support floating point.
    > > >
    > > > See also http://www.minix3.org/doc/environ.html, section "Q: Why is
    > > > OS support needed for MMX or floating point math?".

    > >
    > > Well, I do care about a realiable operating system with a simple and
    > > stable Kernel
    > > (not the chaotic Linux kernel) which I could use for heavy numerical
    > > stuff. Do you
    > > think Minix will ever provide support for math387, MMX, SSE, SSE2,
    > > SSE3, 3DNOW e.t.c,
    > > as all the OS around?

    >
    > The post in the FAQ dates back from 2003, so from before Minix 3. Since
    > the goals now are more than just education, perhaps you may be able to
    > convince someone (or you could do it yourself) to add FP/MMX/SSE
    > support to Minix.
    >
    > ISTM the list of stuff to do mentioned in the post is accurate, but i
    > suppose that the compilers (ACK, GCC) should also be changed to use
    > native FPU instructions rather than calling a software FPU library. I
    > suppose this involves only setting a flag and recompiling.


    Well, which is the one I should try to convince? As it concerns
    recompiling myself
    I am not an experienced Minix user, I have just begun using minix3. So
    I do not think
    I could do it myself. I would be very interested on going on testing
    though and finding
    bugs. This is easy to do and I am pretty good at it. By the way when
    g++ support
    is going to be added to Minix?

    Cheers,
    Archwn.


  6. Re: run time performance of scientific computing applications

    "archwn" wrote:
    > Do you think Minix will ever provide support for math387, MMX, SSE, SSE2,
    > SSE3, 3DNOW e.t.c, as all the OS around?


    Shameless plug: the TenDRA C/C++ compiler generates floating-point
    code for the 387,

    http://tendra4minix.sourceforge.net

    but not such modern things as MMX, SSE, etc.

    You will have to be careful with concurrent processes, since the kernel
    does not keep the floating-point state.

    Kind regards.
    José Juan Mendoza Rodríguez

    let me=josejuanmr in
    let privacy=iespana in
    let net=es in
    me@privacy.net


  7. Re: run time performance of scientific computing applications

    > Shameless plug: the TenDRA C/C++ compiler generates floating-point
    > code for the 387,
    >
    > http://tendra4minix.sourceforge.net
    >
    > but not such modern things as MMX, SSE, etc.
    >
    > You will have to be careful with concurrent processes, since the
    > kernel does not keep the floating-point state.


    Compilers included by default (such as GCC) can also do this on other
    platforms; choosing between hardware and software FPU is probably as
    simple as setting or unsetting a flag and recompiling.

    The point is, that this is not safe. Like you say, different processes
    will mess with each others results, making them useless. There is
    really no way to prevent this; if the user decides to run two instances
    of the app or to run two applications simulateously (in fact there may
    even be multiple users starting these processes) there isn't much your
    app can do about it.

    Besides this, you will not receive any floating point exceptions when
    needed.

  8. Re: run time performance of scientific computing applications


    > The point is, that this is not safe. Like you say, different processes
    > will mess with each others results, making them useless. There is
    > really no way to prevent this; if the user decides to run two instances
    > of the app or to run two applications simulateously (in fact there may
    > even be multiple users starting these processes) there isn't much your
    > app can do about it.
    >
    > Besides this, you will not receive any floating point exceptions when
    > needed.


    I see your point, but then how Linux, FreeBSD, Windows and other OS
    deal with that? Couldn't you follow the same approach only in what
    has to do with FPU stuff?

    Thanks for the feedback!
    Archwn.


  9. Re: run time performance of scientific computing applications



    "archwn" writes:

    > > The point is, that this is not safe. Like you say, different processes
    > > will mess with each others results, making them useless. There is
    > > really no way to prevent this; if the user decides to run two instances
    > > of the app or to run two applications simulateously (in fact there may
    > > even be multiple users starting these processes) there isn't much your
    > > app can do about it.
    > >
    > > Besides this, you will not receive any floating point exceptions when
    > > needed.

    >


    > I see your point, but then how Linux, FreeBSD, Windows and other OS
    > deal with that?


    Linux, *BSD, Windows do 2 things to support floating point:

    1. Manage floating point processor state as per process state. Mind:
    Any additional register in the CPU (or the numerical coprocessor)
    has to be saved, else it's lost). You might say: The job of
    multitasking support is, to virtualize the 1 hardware CPU a
    machine has into multiple CPUs -- one for every process. Minix
    doesn't "virtualize" the FPU (or the MMX unit) in this sense, so
    it's still there, but every process is using the same unit.

    2. Install a hander for the floating point exception which first
    looks which process has the FPU and saves the exception for that
    process. As far as I understood it, one of the tricks here is,
    that the FPU is really a coprocessor, i.e. it might work for a
    process A while another process is running at the main CPU, so
    during a time slice the FPU might be assigned to another process
    than the CPU.

    (I hope I'm getting this right: I didn't research it properly before
    writing this answer, so if anybody who is reading this, knows better
    ....

    Minix on the other side just ignores fp exceptions and the MMX
    registers: So they are not saved and the next process using them
    during its time slice, trashes them. At least it was like this for
    Minix 2.

    > Couldn't you follow the same approach only in what
    > has to do with FPU stuff?


    I'm not sure about the state of things in Minx 3, but I suspect the
    problem it's still the same as with Minix 2. Consider that Minix
    started as an OS at a time when there were no floating point
    processors and I think the attempt to keep it simple, suitable as
    teaching tool, and to be able to run on cheap hardware precluded the
    developers from including FPU support later when the FPU was merged
    with the CPU in the 486 (FPU was an external option in the 086, 286 an
    386 but AFAIK became part of the 486).

    I cannot speak for the developers, since I'm not affiliated to
    Professor Tanenbaum's team or the VU, but from what I read here in
    c.o.m, I'd expect some FPU handling to turn up soon. The Minix 3
    effort is, after all, hardly a year old :-). I expect that the
    non-support of the FPU is not question of policy, but rather a
    question of what to do first.

    If you need to do numerics NOW, your best bet would be

    - Use Linux or BSD. After all, this OSs are here and they are will
    not be slower with the FPU than Minix will be, so why not?

    - Get somebody who knows how to modify the Minix Kernel to get
    interested and add FPU support. :-) I wouldn't expect that to be
    so complicated.

    Regards -- Markus


  10. Re: run time performance of scientific computing applications

    M E Leypold wrote:

    > Minix on the other side just ignores fp exceptions and the MMX
    > registers: So they are not saved and the next process using them
    > during its time slice, trashes them. At least it was like this for
    > Minix 2.


    And it's still like this for Minix 3. In fact the low-level process
    switching code has changed little since support for the larger register
    set of 32-bit machines was added in Minix 1.6 or 1.7.

    Problems I see with adding support for saving a larger set of registers
    are, first, the size of each process table entry will increase, and,
    second, the time it takes to do a context switch will increase. The
    process table size issue is probably not serious, but the context
    switch speed issue might be. The Minix message passing mechanism
    requires more context switches than a monolithic system requires,
    and switching between processes with different privilege levels is
    harder than switching between processes at the same privilege level.

    A simple approach to adding support for MMX and floating point would
    penalize all processes, most of which don't need this support. That
    would be a logical first step, however, and it would be interesting to
    do this and measure the effect on performance (a good class project).
    A more sophisticated approach would be to mark each process at
    compile time as to whether it needs the extra registers, and skip
    copying these registers when processes that don't need them enter
    or leave the "Running" state of Figure 2-2 (OSDI/3). There would still
    be overhead in deciding whether or not the code to copy these
    registers had to be executed, but this is all done in assembly
    language code and I think that would be minimal.


  11. Re: run time performance of scientific computing applications


    > 1. Manage floating point processor state as per process state. Mind:
    > Any additional register in the CPU (or the numerical coprocessor)
    > has to be saved, else it's lost). You might say: The job of
    > multitasking support is, to virtualize the 1 hardware CPU a
    > machine has into multiple CPUs -- one for every process. Minix
    > doesn't "virtualize" the FPU (or the MMX unit) in this sense, so
    > it's still there, but every process is using the same unit.


    > 2. Install a hander for the floating point exception which first
    > looks which process has the FPU and saves the exception for that
    > process. As far as I understood it, one of the tricks here is,
    > that the FPU is really a coprocessor, i.e. it might work for a
    > process A while another process is running at the main CPU, so
    > during a time slice the FPU might be assigned to another process
    > than the CPU.


    Those approaches seem to induce a performance penalty inherent to the
    need of save/restore FPU status between different processes. If I am
    only interested in one application at a time, then do you think that
    the
    saving/restoring can be safely turned off?

    > Minix on the other side just ignores fp exceptions and the MMX
    > registers: So they are not saved and the next process using them
    > during its time slice, trashes them. At least it was like this for
    > Minix 2.


    Would
    that be a problem if I run only one intensive FPU application at
    a time?

    > If you need to do numerics NOW, your best bet would be
    >
    > - Use Linux or BSD. After all, this OSs are here and they are will
    > not be slower with the FPU than Minix will be, so why not?


    Well, I do you both Linux and FreeBSD. The problem is that I am bit
    fed-up the Chaos of Linux and the bugs in FreeBSD and the huge
    disk space the applications require (FreeBSD port system, Gentoo
    portage).

    I need something simple and safe. Maybe Minix3 is not so safe yet,
    but at least it gave me the impression of real robustness and
    simplicitly
    in construction. Not to mention that there is a book teaching the
    internals
    and I hope I will be able to go through those ideas some day. So if you
    stick to code-developing C/C++ emacs as editor gdb as debugger and
    OpenGL support then you have a new developing platform which I hope
    will be delivered by MINIX3 soon. If only they could fix the FPU
    thing...

    > - Get somebody who knows how to modify the Minix Kernel to get
    > interested and add FPU support. :-) I wouldn't expect that to be
    > so complicated.


    Do you have somebody in mind? I do not know someone ...

    Thanks for the extensive reply!
    Best,
    Archwn.


  12. Re: run time performance of scientific computing applications


    > Al wrote:


    > A simple approach to adding support for MMX and floating point would
    > penalize all processes, most of which don't need this support. That
    > would be a logical first step, however, and it would be interesting to
    > do this and measure the effect on performance (a good class project).


    That should be done. I can help coding really numerically intensive
    applications.
    Moreover if g++ is ported to minix3 then I would perform more tests
    since all my
    developing is written in C++.

    > A more sophisticated approach would be to mark each process at
    > compile time as to whether it needs the extra registers, and skip
    > copying these registers when processes that don't need them enter
    > or leave the "Running" state of Figure 2-2 (OSDI/3). There would still
    > be overhead in deciding whether or not the code to copy these
    > registers had to be executed, but this is all done in assembly
    > language code and I think that would be minimal.


    This is a wonderful idea, it reminds me C++ templates, and it
    definately could be
    implemented if someone could patch a compiler. Of course the first
    thing one should
    try is the first way you suggested to see if the performance impact
    requires more
    sophisticated approaches.

    By the way, I am really wondering if all those "...Minix message
    passing mechanism
    requires more context switches" are really necessary. There must be a
    way around,
    which could provide the same reliablility without hurting performance
    so much. I am
    sure the developers have investigated those alternatives extensively,
    but then, could
    you say that Linux or FreeBSD are not reliable? Anyway I am not the
    most suitable
    person to discuss about OS, but since minix3 is the $100 laptop OS
    choice then I
    suppose that users may want to do some floating point stuff and not
    just browsing or
    painting or document writting. Not to mention that the if the
    FPU/MMX/SSE/SSE2/SSE3
    issue is fixed then minix3 will be able to serve a wider area of users
    which means more
    feedback more bug reports e.t.c.

    To sum up, its only 1 week I am using minix3 and guys I am really
    impressed; minix3
    is something else. A different philosophy. A new world. If only the
    developers could
    address some issues concerning

    1) executables size, (code bloat issues of glibc ...)
    2) simple scripts for the running daemons (avoiding huge scripting
    packages like perl, python ...)
    3) C++, OpenGL, QT3/QT4 porting, NVIDIA drivers porting and stuff like
    that
    4) power management (laptops), wireless and generally better hardware
    support

    I am sure that minix3 would be a great alternative to Linux or FreeBSD.

    Best!
    Archwn.


  13. Re: run time performance of scientific computing applications

    In article <1159541881.426183.70070@h48g2000cwc.googlegroups.c om>,
    Al wrote:
    >A simple approach to adding support for MMX and floating point would
    >penalize all processes, most of which don't need this support. That
    >would be a logical first step, however, and it would be interesting to
    >do this and measure the effect on performance (a good class project).
    >A more sophisticated approach would be to mark each process at
    >compile time as to whether it needs the extra registers, and skip
    >copying these registers when processes that don't need them enter
    >or leave the "Running" state of Figure 2-2 (OSDI/3). There would still
    >be overhead in deciding whether or not the code to copy these
    >registers had to be executed, but this is all done in assembly
    >language code and I think that would be minimal.


    Well, you can just save and restore the FPU state when it is needed
    instead of every context switch. Of course, that will make the
    code in the kernel much more complicated, but the performance penalty
    is close to zero when the FPU is not used, or when it is used by only one
    process.


    --
    That was it. Done. The faulty Monk was turned out into the desert where it
    could believe what it liked, including the idea that it had been hard done
    by. It was allowed to keep its horse, since horses were so cheap to make.
    -- Douglas Adams in Dirk Gently's Holistic Detective Agency

  14. Re: run time performance of scientific computing applications

    archwn wrote:
    > This forum doesn't give me the opportunity to attach any files so I
    > will just copy paste the
    > code and the file I used.


    Get a real USENET provider, and stop using Google Groups, and use a
    newsreader supporting MIME attachments and encodings, such as Mozilla
    Thunderbird.

    Also, Minix 3 isn't very optimized to the hardware. Why? Linux has
    hundreds of thousands of people that have worked on it over the years to
    fine-tune it, Minix has, well, mostly, sat on a self to collect dust,
    using optimizations which, while they worked on the 486s and Pentiums of
    yesteryear, the timings just don't go over too well on machines more
    than 500MHz.

    I think I know where part of the problem is, but I won't start pointing
    fingers until I know for certain if it's in the kernel or the process
    manager.


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.1 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFFHf2XsjeOFtd+nycRAoSbAJ9deTQIeUf+oDErAHpnQC JKnINGNgCfR3gt
    ljCHUhA5y15V2gkLCQzjjog=
    =xt59
    -----END PGP SIGNATURE-----


  15. Re: run time performance of scientific computing applications

    archwn wrote:
    > By the way when
    > g++ support
    > is going to be added to Minix?
    >
    > Cheers,
    > Archwn.
    >

    When you install g++ from packman. Or in other words, It's already there
    (not installed by default, following similar to the Gentoo philosophy),
    you just haven't the ttime to stop crying at us like a 4 year old to
    find out.


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.1 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFFHf5IsjeOFtd+nycRAts7AJ9r4GmI1r1v/0wXTCBa3q+GrzcJ0wCeOsYR
    qY/D7xZXuLOqwbNZ6256qJc=
    =Tt/v
    -----END PGP SIGNATURE-----


  16. Re: run time performance of scientific computing applications

    archwn wrote:
    >
    > I see your point, but then how Linux, FreeBSD, Windows and other OS
    > deal with that? Couldn't you follow the same approach only in what
    > has to do with FPU stuff?
    >
    > Thanks for the feedback!
    > Archwn.
    >


    Meh, probably, but Minix's heyday of development happened with a
    floating-point unit was a actual addon you went out and bought, and also
    cost about as much as a Xbox game console. Most people didn't have a
    floating-point unit back then (remember that was back in the good ol'
    day of Windows 3.1 and the 386 and 486SX). Like I have said, Minix lost
    most of it's development community, and what was left (basically the few
    professors at the VU that were also developers) had more important
    things than floating-point support that had to be done.

    Also, SSE support requires that you set explicit CPU flags, please refer
    to the Wikipedia page on SSE
    [http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions] for more
    information. An excerpt from the page follows:

    Because these 128-bit registers are additional program states that the
    operating system must preserve across task switches, they are disabled
    by default until the operating system explicitly enables them. This
    means that the OS must know how to use the FXSAVE and FXRSTR
    instructions, which is the extended pair of instructions which can save
    all x87 and SSE register states all at once. This support was quickly
    added to all major IA-32 operating systems.

    ACK (the Minix compiler and assembler which is used for compiling the
    kernel, because GCC cannot be used yet) doesn't support the required CPU
    opcodes, so the OS cannot be extended until the underlying source
    compilation system is extended. Hate to say it, but getting the system
    compiled with gcc as opposed to the current system is really not worth
    the effort. Don't believe me? Try making it work yourself, and check
    back with your status in, I'd say, about 6 months. I bet it still
    doesn't work even by then.


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.1 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFFHgDasjeOFtd+nycRAtGEAJ9zrqWXwuqohA9trdxLVs 9kWve87wCghJZz
    DpwrcS25J9Q99uX9BAXTRTM=
    =ICTm
    -----END PGP SIGNATURE-----


  17. Re: run time performance of scientific computing applications

    > By the way, I am really wondering if all those "...Minix message
    > passing mechanism requires more context switches" are really
    > necessary. There must be a way around,
    > which could provide the same reliablility without hurting performance
    > so much. I am sure the developers have investigated those

    alternatives
    > extensively, but then, could you say that Linux or FreeBSD are not
    > reliable?


    The main difference between Linux and Minix is that Minix is a
    microkernel operating system. This is a core design decision and one of
    the main reasons Minix exists: to experiment academically with
    microkernel systems and to teach students how they work.

    The increased number of context switches is inherent to microkernels,
    since everything moved out of the kernel is put in user processes,
    which require context switches to be reached.


  18. Re: run time performance of scientific computing applications


    > Also, Minix 3 isn't very optimized to the hardware. Why? Linux has
    > hundreds of thousands of people that have worked on it over the years to
    > fine-tune it, Minix has, well, mostly, sat on a self to collect dust,
    > using optimizations which, while they worked on the 486s and Pentiums of
    > yesteryear, the timings just don't go over too well on machines more
    > than 500MHz.
    >
    > I think I know where part of the problem is, but I won't start pointing
    > fingers until I know for certain if it's in the kernel or the process
    > manager.


    There is always the option that _you_ do a fork if you think that
    other people are doing it wrong :-).

    Regards -- Markus



  19. Re: run time performance of scientific computing applications



    Segin writes:

    > archwn wrote:
    > > This forum doesn't give me the opportunity to attach any files so I
    > > will just copy paste the
    > > code and the file I used.

    >
    > Get a real USENET provider, and stop using Google Groups, and use a
    > newsreader supporting MIME attachments and encodings, such as Mozilla
    > Thunderbird.


    On the other side, there are the purists who wouldn't consider MIME
    attachements as "real usenet". Actually I hear it's rather frowned
    upon.

    Regards -- Markus

  20. Re: run time performance of scientific computing applications


    A less chaotic alternative to Linux & *BSD to consider is Solaris.
    It's available for download for free as is the complete dvelopment
    suite. The Sun dbx implementation is the best debugger I've used for
    numrical work and I've used quite a few of them.

    That said, Solaris is much more complex than Minix. However, it IS stable.

    I just got my copy of the Minix 3 book and am a bit disappointed that
    floating point is still getting short shrift.

+ Reply to Thread
Page 1 of 2 1 2 LastLast