[9fans] Plan 9 on Blue Gene - Plan9

This is a discussion on [9fans] Plan 9 on Blue Gene - Plan9 ; > Obviously Plan 9's compiler > isn't optimal.. but what really are the requirements people really? that depends on your definition of optimal. by my definition which heavily rates speed of compliation and correctness, it's sure closer than the competition. ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 37 of 37

Thread: [9fans] Plan 9 on Blue Gene

  1. Re: [9fans] Plan 9 on Blue Gene

    > Obviously Plan 9's compiler
    > isn't optimal.. but what really are the requirements people


    really? that depends on your definition of optimal.
    by my definition which heavily rates speed of compliation
    and correctness, it's sure closer than the competition.

    - erik


  2. Re: [9fans] Plan 9 on Blue Gene

    On Wed, Jul 30, 2008 at 8:36 AM, Eric Van Hensbergen wrote:

    > On Wed, Jul 30, 2008 at 10:25 AM, wrote:
    > >
    > > i'm asking from a technical point of view, i suppose dealing with the

    > current users and customers is the real issue, right?
    > >

    >
    > and tens of millions of lines of fortran that no one understands
    > anymore....
    >
    > Its not that we aren't promoting other paradigms, its just we also
    > need to be able to support existing code bases.
    >
    > -eric
    >


    So is there any traction to use the new platform, or is it mostly just
    people running their familiar apps and writing new apps for their familiar
    programming environment?

    Dave


  3. Re: [9fans] Plan 9 on Blue Gene

    On Wed, Jul 30, 2008 at 4:36 PM, David Leimbach wrote:

    > So is there any traction to use the new platform, or is it mostly just
    > people running their familiar apps and writing new apps for their familiar
    > programming environment?


    There are always users who are adventurous. I'm counting on it. First
    we have to show "no penalty". Then, I hope to be able to say: "hey,
    here's a nifty feature" and get them hooked.

    I don't think that second step will be hard. The work is in the first
    step. The great thing about BG/L and /P is that they got people out of
    the mindset that "everything is a Linux". Once you cross that Rubicon
    life gets much easier.


    ron


  4. Re: [9fans] Plan 9 on Blue Gene

    > the mindset that "everything is a Linux". Once you cross that Rubicon
    > life gets much easier.


    only if it's the rubicon and not the styx.



    - erik



  5. Re: [9fans] Plan 9 on Blue Gene

    On Wed, Jul 30, 2008 at 5:02 PM, ron minnich wrote:

    > On Wed, Jul 30, 2008 at 4:36 PM, David Leimbach wrote:
    >
    > > So is there any traction to use the new platform, or is it mostly just
    > > people running their familiar apps and writing new apps for their

    > familiar
    > > programming environment?

    >
    > There are always users who are adventurous. I'm counting on it. First
    > we have to show "no penalty". Then, I hope to be able to say: "hey,
    > here's a nifty feature" and get them hooked.
    >
    > I don't think that second step will be hard. The work is in the first
    > step. The great thing about BG/L and /P is that they got people out of
    > the mindset that "everything is a Linux". Once you cross that Rubicon
    > life gets much easier.
    >


    Does Plan 9 Port help? I mean, libthread on Plan 9 Port alone could be
    worth a ton to me in some situations.

    Concurrent programming for the win?


    >
    >
    > ron
    >
    >



  6. Re: [9fans] Plan 9 on Blue Gene

    On Wed, Jul 30, 2008 at 6:48 PM, David Leimbach wrote:

    > Does Plan 9 Port help? I mean, libthread on Plan 9 Port alone could be
    > worth a ton to me in some situations.
    > Concurrent programming for the win?


    probably not for this community. When we had plan9port in xcpu we got
    nothing but complaints. This in spite of the fact that some things are
    impossible to scale with 5000 posix threads, and easy to scale with
    5000 plan 9 style threads.

    ron


  7. Re: [9fans] Plan 9 on Blue Gene

    Can you tell us why some things are impossible to scale with 5000 posix
    threads (and easy to scale with 5000 plan 9 style threads) ?
    Is this specific to posix or linux ? Or maybe you will write a paper on this
    ?

    Phil;

    ----- Original Message -----
    From: "ron minnich"
    To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
    Sent: Thursday, July 31, 2008 4:23 AM
    Subject: Re: [9fans] Plan 9 on Blue Gene


    > On Wed, Jul 30, 2008 at 6:48 PM, David Leimbach wrote:
    >
    >> Does Plan 9 Port help? I mean, libthread on Plan 9 Port alone could be
    >> worth a ton to me in some situations.
    >> Concurrent programming for the win?

    >
    > probably not for this community. When we had plan9port in xcpu we got
    > nothing but complaints. This in spite of the fact that some things are
    > impossible to scale with 5000 posix threads, and easy to scale with
    > 5000 plan 9 style threads.
    >
    > ron
    >
    >




  8. Re: [9fans] Plan 9 on Blue Gene

    hello

    thanks for the clarifications Eric and Ron ☺,

    btw, if you're planning to go to Greece to the 3rd. iwp9, i would love to see a real
    sheet of these ones:

    http://www.atkielski.com/PDF/data/fortran.pdf



    slds.

    gabi


    > On Wed, Jul 30, 2008 at 10:25 AM, wrote:
    >>
    >> i'm asking from a technical point of view, i suppose dealing with the current users and customers is the real issue, right?
    >>

    >
    > and tens of millions of lines of fortran that no one understands anymore....
    >
    > Its not that we aren't promoting other paradigms, its just we also
    > need to be able to support existing code bases.
    >
    > -eric




  9. Re: [9fans] Plan 9 on Blue Gene

    hello

    thanks for the clarifications Eric and Ron ☺,

    btw, if you're planning to go to Greece to the 3rd. iwp9, i would love to see a real
    sheet of these ones:

    http://www.atkielski.com/PDF/data/fortran.pdf



    slds.

    gabi


    > On Wed, Jul 30, 2008 at 10:25 AM, wrote:
    >>
    >> i'm asking from a technical point of view, i suppose dealing with the current users and customers is the real issue, right?
    >>

    >
    > and tens of millions of lines of fortran that no one understands anymore....
    >
    > Its not that we aren't promoting other paradigms, its just we also
    > need to be able to support existing code bases.
    >
    > -eric




  10. Re: [9fans] Plan 9 on Blue Gene

    On Thu, Jul 31, 2008 at 5:53 AM, Philippe Anel wrote:

    > Can you tell us why some things are impossible to scale with 5000 posix
    > threads (and easy to scale with 5000 plan 9 style threads) ?
    > Is this specific to posix or linux ? Or maybe you will write a paper on
    > this ?
    >
    > Phil;



    I think it's because plan 9 style threads are more like coroutines, and
    don't initiate a new kernel-schedulable process.

    If you use libthread from plan 9 port on a unix deployed system the
    threadcreate function doesn't make a pthread. proccreate, on the other
    hand, does. (on the platforms I've used).

    As a result you get no chance at parallelism with threadcreate, which uses
    more compute resources to schedule, and proccreate "might" cause two threads
    to run in parallel, if the code is arranged such that the two libthread
    processes can run independently or at least overlapping.

    This duality is one of the reasons I find libthread interesting in general,
    even outside of Plan 9.

    I've been writing a lot of Erlang code lately, and I keep thinking about,
    but not having too much time to do much about, wanting to have a runtime for
    the libthread "threads" that could auto-schedule them to libthread "procs",
    in much the same way Haskell "sparks" may end up real threads, or Erlang
    processes, might run in parallel.

    Dave


    >
    >
    > ----- Original Message ----- From: "ron minnich"
    > To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
    > Sent: Thursday, July 31, 2008 4:23 AM
    > Subject: Re: [9fans] Plan 9 on Blue Gene
    >
    >
    >
    > On Wed, Jul 30, 2008 at 6:48 PM, David Leimbach
    >> wrote:
    >>
    >> Does Plan 9 Port help? I mean, libthread on Plan 9 Port alone could be
    >>> worth a ton to me in some situations.
    >>> Concurrent programming for the win?
    >>>

    >>
    >> probably not for this community. When we had plan9port in xcpu we got
    >> nothing but complaints. This in spite of the fact that some things are
    >> impossible to scale with 5000 posix threads, and easy to scale with
    >> 5000 plan 9 style threads.
    >>
    >> ron
    >>
    >>
    >>

    >
    >



  11. Re: [9fans] Plan 9 on Blue Gene

    That's almost what they do with KSE in FreeBSD (or Scheduler Activation in NetBSD) right ?

    Phil;



    I've been writing a lot of Erlang code lately, and I keep thinking about, but not having too much time to do much about, wanting to have a runtime for the libthread "threads" that could auto-schedule them to libthread "procs", in much the same way Haskell "sparks" may end up real threads, or Erlang processes, might run in parallel.


    Dave



    ----- Original Message ----- From: "ron minnich"
    To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
    Sent: Thursday, July 31, 2008 4:23 AM
    Subject: Re: [9fans] Plan 9 on Blue Gene




    On Wed, Jul 30, 2008 at 6:48 PM, David Leimbach wrote:


    Does Plan 9 Port help? I mean, libthread on Plan 9 Port alone could be
    worth a ton to me in some situations.
    Concurrent programming for the win?


    probably not for this community. When we had plan9port in xcpu we got
    nothing but complaints. This in spite of the fact that some things are
    impossible to scale with 5000 posix threads, and easy to scale with
    5000 plan 9 style threads.

    ron









  12. Re: [9fans] Plan 9 on Blue Gene

    On Thu, Jul 31, 2008 at 7:11 AM, Philippe Anel wrote:

    > That's almost what they do with KSE in FreeBSD (or Scheduler Activation
    > in NetBSD) right ?
    >
    > Phil;
    >


    KSEs were a way to make things that were not processes or threads in
    particular cooperatively scheduled with user-space callbacks. Basically the
    kernel signaled user-space to make a decision on what the next context would
    be. This is not the same a cooperatively scheduled coroutines where the
    re-scheduling happens as the result of making certain library calls to
    certain I/O routines (libtask does this, thanks again Russ!)

    KSEs were a mechanism to implement true-pre-emptive M:N threading for Posix
    threads... allowing M pthreads to be scheduled on N user processes. (I may
    have my M's and N's backwards).

    Usually what I've been seeing is the more popular thread implementations are
    1:1, where each pthread is a user process as well. I'm not sure if KSE
    based threads or M:N in general, are a win in every situation people had
    hoped (or any for that matter). But then again I've not looked terribly
    deeply at this. 1:1 seems easier to reason about and keep track of :-)

    Dave


    >
    >
    >
    >
    > I've been writing a lot of Erlang code lately, and I keep thinking about,
    > but not having too much time to do much about, wanting to have a runtime for
    > the libthread "threads" that could auto-schedule them to libthread "procs",
    > in much the same way Haskell "sparks" may end up real threads, or Erlang
    > processes, might run in parallel.
    >
    > Dave
    >
    >
    >>
    >>
    >> ----- Original Message ----- From: "ron minnich"
    >> To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
    >> Sent: Thursday, July 31, 2008 4:23 AM
    >> Subject: Re: [9fans] Plan 9 on Blue Gene
    >>
    >>
    >>
    >> On Wed, Jul 30, 2008 at 6:48 PM, David Leimbach
    >>> wrote:
    >>>
    >>> Does Plan 9 Port help? I mean, libthread on Plan 9 Port alone could be
    >>>> worth a ton to me in some situations.
    >>>> Concurrent programming for the win?
    >>>>
    >>>
    >>> probably not for this community. When we had plan9port in xcpu we got
    >>> nothing but complaints. This in spite of the fact that some things are
    >>> impossible to scale with 5000 posix threads, and easy to scale with
    >>> 5000 plan 9 style threads.
    >>>
    >>> ron
    >>>
    >>>
    >>>

    >>
    >>

    >



  13. Re: [9fans] Plan 9 on Blue Gene

    On Thu, Jul 31, 2008 at 5:53 AM, Philippe Anel wrote:
    > Can you tell us why some things are impossible to scale with 5000 posix
    > threads (and easy to scale with 5000 plan 9 style threads) ?


    the trivial stuff you deal with first, like the default 8MB thread
    stack which makes the machine fall over.

    But it still seems to very hard on a linux box to spawn 5k threads and
    run them, one thread to a socket. The whole machine just starts to bog
    down.

    I did not write this particular code, was only a victim of it.

    ron


  14. Re: [9fans] Plan 9 on Blue Gene

    > Correct me if I'm wrong here, but don't these require extensive run-time
    > support, in addition to compiler support? Will the run-time libraries
    > also be linux libraries running under a compatibility layer?


    yes, but the final answer to the second question is unclear,
    depending on the library. the further up you go, the more likely
    it will be left unchanged, if only because there are so many more of them.
    if a higher-level library uses a lower-level one and cheats, by being written
    to a particular implementation of that library not to a supposedly agreed interface,
    then there is less flexibility for replacing the latter, too.



  15. Re: [9fans] Plan 9 on Blue Gene

    you could change the subject line to continue this discussion
    for other reasons, but for this particular work on plan 9,
    it's not worth getting into a discussion of aspects of belief
    in particular C implementations. (just to add a contrasting data point,
    at my previous employment we had examples of important scientific code on power where gcc
    compiled faster(!) and compiled vastly faster code than xlc, for instance.)
    it doesn't matter. it isn't relevant to this plan 9 project, so i think there's not much point
    in spending time on it here, at least once we've satisfactorily explained why it doesn't matter.
    compilers are programs. once you know or can guess what another program does
    that's clever in your case, you can do it too (subject perhaps to patents).
    in fact, you can often do it simpler and better because you can work out what
    really made the difference in the earlier case, or (better) deal with it at a higher level
    of abstraction.

    improving qc/9c code on power/power64 is likely to happen in the course
    of this project, where needed to make the kernel and plan 9-specific applications run better.
    it probably isn't worth the effort (at least for the current project)
    to do that for arbitrary scientific code, and is certainly
    outside the scope of the agreed specification of the project.

    speaking of higher levels of abstraction:
    given some scientific code i've seen (before this, nothing to do with the things
    running on Blue Gene), i'd observe that fixing some of the algorithms used (which
    is compiler and platform independent activity) will often yield much bigger results
    than (say) compiling it with gcc, xlc, xlf, etc. you'd be amazed (or perhaps not)
    how naive some of the code can be.

    then there's the bigger question about which language to use to produce much
    faster code easily, and i'd hazard a moderately informed guess that C is not the language
    of choice for a lot of that. again, that's outside the scope of our project.



  16. Re: [9fans] Plan 9 on Blue Gene

    On Thu, Jul 31, 2008 at 3:03 PM, Charles Forsyth wrote:

    > speaking of higher levels of abstraction:
    > given some scientific code i've seen (before this, nothing to do with the things
    > running on Blue Gene), i'd observe that fixing some of the algorithms used (which
    > is compiler and platform independent activity) will often yield much bigger results
    > than (say) compiling it with gcc, xlc, xlf, etc. you'd be amazed (or perhaps not)
    > how naive some of the code can be.


    Excellent point. Some of the app code is terrible. I am hoping we'll
    prove that we can "go native" and do as well as or better than the
    existing apps. At the same time, having just gotten badly burned on
    Clustermatic because people wanted to run xemacs on compute nodes and
    got unhappy when we said no, I've gotten sensitized to the "wants" of
    users. How you respond to stupid demands can make or break your
    project. It's hard to take but we're a service industry.

    ron


  17. Re: [9fans] Plan 9 on Blue Gene

    On Thu, Jul 31, 2008 at 4:23 AM, ron minnich wrote:
    > On Wed, Jul 30, 2008 at 6:48 PM, David Leimbach wrote:
    >
    >> Does Plan 9 Port help? I mean, libthread on Plan 9 Port alone could be
    >> worth a ton to me in some situations.
    >> Concurrent programming for the win?

    >
    > probably not for this community. When we had plan9port in xcpu we got
    > nothing but complaints. This in spite of the fact that some things are
    > impossible to scale with 5000 posix threads, and easy to scale with
    > 5000 plan 9 style threads.


    Why not use rsc's libtask instead? It would avoid most of the p9p
    baggage (which certainly it is not designed to make it easy for people
    to build apps that depend on it).

    libtask is small enough that it could easily be distributed together with xcpu.

    Just an ignorant suggestion by someone that is not even clear on what xcpu does.

    uriel


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2