On Thu, Jul 31, 2008 at 4:23 AM, ron minnich [EMAIL PROTECTED] wrote:
On Wed, Jul 30, 2008 at 6:48 PM, David Leimbach [EMAIL PROTECTED] 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?
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 [EMAIL PROTECTED] wrote:
Does Plan 9 Port help? I mean, libthread on Plan 9 Port alone could be
worth a ton to me
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, [EMAIL PROTECTED] wrote:
i'm
, 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 [EMAIL PROTECTED] 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
On Thu, Jul 31, 2008 at 7:01 AM, erik quanstrom [EMAIL PROTECTED]wrote:
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
Just a dumb question, as i'm totally out of this business, it is easier to
write an emulator than translate the applications to plan9 c ? (for example)
or to write (or port) the C++ and Fortran compilers and related tools?
it is easier (in both cases), but it's also not the point.
On Thu, Jul 31, 2008 at 3:03 PM, Charles Forsyth [EMAIL PROTECTED] 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
On Wed, Jul 30, 2008 at 7:32 AM, Roman V. Shaposhnik [EMAIL PROTECTED] wrote:
Do you have any bits and pieces of the software ecosystem not
readily available on Plan9 (dreadful things like a C++ compiler)
covered by these funds or is your intention to use available
Plan9 userland as-is?
In the HPC world, there is lots of conservatism. There is an editor at
LANL, named Fred, written in Fortran, that has been in use for longer
than most of you have been alive. Until very recently, it was a
required part of any HPC system.
So, we're doing a binary compatibility module so we can run
Hello,
Just a dumb question, as i'm totally out of this business, it is easier to
write an emulator than translate the applications to plan9 c ? (for example) or
to write (or port) the C++ and Fortran compilers and related tools?
i'm asking from a technical point of view, i suppose dealing
ron minnich wrote:
In the HPC world, there is lots of conservatism. There is an editor at
LANL, named Fred, written in Fortran, that has been in use for longer
than most of you have been alive. Until very recently, it was a
required part of any HPC system.
So, we're doing a binary compatibility
On Wed, Jul 30, 2008 at 10:25 AM, [EMAIL PROTECTED] 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
On Wed, Jul 30, 2008 at 10:21 AM, Steven D. Vormwald [EMAIL PROTECTED] wrote:
So would developers on this platform be encouraged to use languages and
features currently in plan 9 for HPC development,
It is unlikely that existing features in Plan 9 scale applications (or
system services) to
On Wed, Jul 30, 2008 at 8:21 AM, Steven D. Vormwald [EMAIL PROTECTED] wrote:
So would developers on this platform be encouraged to use languages and
features currently in plan 9 for HPC development, or would they target
existing HPC languages and features, which would be added to plan 9,
On Wed, Jul 30, 2008 at 7:10 AM, ron minnich [EMAIL PROTECTED] wrote:
In the HPC world, there is lots of conservatism. There is an editor at
LANL, named Fred, written in Fortran, that has been in use for longer
than most of you have been alive. Until very recently, it was a
required part of
On Wed, Jul 30, 2008 at 8:25 AM, [EMAIL PROTECTED] wrote:
Hello,
Just a dumb question, as i'm totally out of this business, it is easier to
write an emulator than translate the applications to plan9 c ? (for example)
or to write (or port) the C++ and Fortran compilers and related tools?
ron minnich wrote:
On Wed, Jul 30, 2008 at 8:21 AM, Steven D. Vormwald [EMAIL PROTECTED] wrote:
So would developers on this platform be encouraged to use languages and
features currently in plan 9 for HPC development, or would they target
existing HPC languages and features, which would be
1. rewrite apps in plan 9 c. The Plan 9 C compiler is fine for what we
do on Plan 9. For scientific apps, it's not that great a compiler. The
IBM compilers know all the tricks. The effort to get Plan 9 C up to
the standards of XLC is mind-boggling. And XLF? We're not going to
write a Fortran
What is XLC and where can I find more information on the standard?
XLC is IBM's POWER/PowerPC compiler. It produces great code, but is expensive.
So, does that mean that you guys have a version of XLC that can produce Plan 9
binaries, or are you using some other method to convert it's output?
ron minnich wrote:
On Wed, Jul 30, 2008 at 9:10 AM, Steven D. Vormwald [EMAIL PROTECTED] wrote:
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
Can you elaborate here? What tricks can the IBM compilers use
that the Plan 9 ones can't? Are we talking optimization?
No, really, that's not troll bait. I'm actually interested in
understanding the project's basis for discriminating against
specific compiler capability. Obviously Plan 9's
On Wed, Jul 30, 2008 at 1:03 PM, don bailey [EMAIL PROTECTED] wrote:
Can you elaborate here? What tricks can the IBM compilers use
that the Plan 9 ones can't? Are we talking optimization?
No, really, that's not troll bait. I'm actually interested in
understanding the project's basis for
On Wed, Jul 30, 2008 at 11:03 AM, don bailey [EMAIL PROTECTED] wrote:
Can you elaborate here? What tricks can the IBM compilers use
that the Plan 9 ones can't? Are we talking optimization?
yes. Quite impressive optimization. Which results in very high
measured performance. At least when I've
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
On Wed, Jul 30, 2008 at 8:36 AM, Eric Van Hensbergen [EMAIL PROTECTED]wrote:
On Wed, Jul 30, 2008 at 10:25 AM, [EMAIL PROTECTED] 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
On Wed, Jul 30, 2008 at 4:36 PM, David Leimbach [EMAIL PROTECTED] 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
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
On Wed, Jul 30, 2008 at 6:48 PM, David Leimbach [EMAIL PROTECTED] 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
On Sat, Jul 26, 2008 at 1:37 PM, Steven Vormwald [EMAIL PROTECTED] wrote:
Is there any (public) information about how plan 9 is/was being used on Blue
Gene? The only information I can find seems to be press release-type
papers that just say that it runs on Blue Gene, but not what it was used
29 matches
Mail list logo
