I really find it hard to believe that the best intellects in computing
are incapable of stemming the tide.
I'm not sure they're aware it's an issue (CS professor and research types).
As for P9GCC, its scope fairly exceeds (this) one person's
capabilities. Just looking at binutils and bfd,
and take it all in. gcc texi is larger than the kenc source.
i know which is easier to read.
brucee
On Mon, Mar 10, 2008 at 4:53 AM, Aharon Robbins [EMAIL PROTECTED] wrote:
I really find it hard to believe that the best intellects in computing
are incapable of stemming the tide.
I'm not
On Mar 9, 2008, at 1:53 PM, Aharon Robbins wrote:
capabilities. Just looking at binutils and bfd, without having
the slightest idea what their real intent might be and how to
apply it
to P9GCC, then finding wonderful snippets such as
Binutils are the things for dealing with binaries: as,
There was a time when you said
template typename x, typename y
instead of
template class x, class y
(Was it TC++PL 2nd edition?) The former is still allowed.
It is also used when the context that a variable declaration is in is
ambiguous, such as this:
i don't remember typename and checked my copy of the Bjorne's design
and evolution of c++ and it's not there either. apparently it evovled
some more.
you know you're in trouble when you have to add keywords to help the
compiler (not the programmer)
There was a time when you said
i don't remember typename and checked my copy of the Bjorne's design
and evolution of c++ and it's not there either. apparently it evovled
some more.
Pity it didn't notice that it was already estinct. Biological
evolution at least has some checks and balances, computing evolution
instead
On Mon, Mar 3, 2008 at 4:31 AM, Roman V. Shaposhnik [EMAIL PROTECTED] wrote:
On Sun, 2008-03-02 at 12:34 -0800, Paul Lalonde wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
CSP doesn't scale very well to hundreds of simultaneously executing
threads (my claim, not, as far as
On Tue, Mar 4, 2008 at 2:57 AM, Paweł Lasek [EMAIL PROTECTED] wrote:
And there were available methods for routing HT
traffic with number of sockets nearing thousands or tens of thousands.
as in this: http://www.cray.com/products/xt4/
Dunno if they used it directly with cache coherency
no, it does not.
Plan 9 port in progress ... soon we hope.
ron
Are you working on this port Ron ?
Are you planning to have several kernels or just one ?
Phil;
On Tue, 2008-03-04 at 11:57 +0100, Paweł Lasek wrote:
I take it that you really do mean simultaneous. As in: you actually
have hundreds of cores available on the same system. I'm actually
quite curious to find out what's the highest number of cores available
of a single shared memory
On Tue, Mar 4, 2008 at 7:55 AM, Philippe Anel [EMAIL PROTECTED] wrote:
Are you working on this port Ron ?
soon.
I just realized today that, for the part, linuxemu may save our neck
on the XT4. That's because there are proprietary programs that need to
run, and they are only linux programs.
Ron, I thought Paul was talking about cache coherent system on which a
high-contention lock can become a huge problem.
Although the work did by Jim Taft on the NASA project looks very
interesting (and if you have pointers to papers about locking primitive
on such system, I would appreciate),
Please note I'm not an expert in this domain. I am only interested in
this area, and have only read a few papers.
It is interesting to talk with you about this 'real world' problems.
Latency is quite important in the application domain I have to target:
the target is to produce a new image
In fact the more I think about it, the more it seems like having
a direct way of manipulating L1/L2 caches would be more of a benefit
than a curse at this point. Prefetches are nothing but a patchwork
over the fundamental need for programming memory hierarchy in an
efficient way. But, I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 3, 2008, at 4:49 PM, erik quanstrom wrote:
really? to out-predict the cache hardware, you have to have pretty
complete knowlege of everything running on all cores and be pretty
good at guessing what will want scheduling next. not to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 3, 2008, at 1:12 AM, Philippe Anel wrote:
So, does this mean the latency is only required by the I/O system
of your program ? If so, maybe I'm wrong, what you need is to be
able to interrupt working cores and I'm afraid libthread
Yes. Although I work for a company that prides itself on its cache
coherence know-how, I'm very much a believer in networked
multiprocessors, even on a chip. I like Cell better than Opteron,
for example. They are harder to program up front, however, which
causes difficulties in
On 2008-Mar-1, at 08:41 , ron minnich wrote:
very litlle f77 left in my world, maybe somebody else has some.
And also in response to Pietro's comments ...
I have lots of dusty but still valid F77 code I use for antenna and RF
circuit design (i.e. NEC and SPICE). Yes, there are newer
i hope you tell them repeatedly that it makes you want to eat your own vomit.
life is too short too play with badd technology, particularly if you
are trying to make money. (Badd is a TM of Badd Attitude, girlie
dancers of mine you wish you'd seen.)
brucee
On Sun, Mar 2, 2008 at 3:28 PM, ron
Except that all our users code in C++. The complicated kind, with
templates and hideous metaprogramming. And can even show good reason
to do so.
C++ is probably the wrong language for the application, then;
it should appear straightforward.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 2, 2008, at 3:12 AM, Charles Forsyth wrote:
C++ is probably the wrong language for the application, then;
it should appear straightforward.
Almost certainly. And so is C. Programming many-core shared-cache
machines in languages with
On Sun, Mar 2, 2008 at 12:02 AM, [EMAIL PROTECTED] wrote:
Still, one obstacle out of the way
may encourage others to address the next ones.
How close is linuxemu to being able to run gcc?
-sqweek
How close is linuxemu to being able to run gcc?
I'm not sure how much it will help, given that one presumably wants to
produce code that runs on Plan 9, not Linux. That said, I should
think that linux-native gcc is probably already supported by linuxemu.
++L
Almost certainly. And so is C. Programming many-core shared-cache
machines in languages with global state and aliasing is just plain
wrong, in the same way that programming in assembly instead of C is
wrong. Add a highly heterogeneous real-time task mix on top of that,
and you're
i could run gcc and compile hello world with it, but did no
further testing.
cinap
---BeginMessage---
On Sun, Mar 2, 2008 at 12:02 AM, [EMAIL PROTECTED] wrote:
Still, one obstacle out of the way
may encourage others to address the next ones.
How close is linuxemu to being able to run gcc?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
CSP doesn't scale very well to hundreds of simultaneously executing
threads (my claim, not, as far as I've found yet, anyone else's). It
is very well suited to a small number of threads that need to
communicate, and as a model of concurrency
Paul Lalonde wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
CSP doesn't scale very well to hundreds of simultaneously executing
threads (my claim, not, as far as I've found yet, anyone else's). It
is very well suited to a small number of threads that need to
communicate, and as a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 2, 2008, at 2:00 PM, Philippe Anel wrote:
I agree with you, taking care about memory hierarchy is becoming
very important. Especially if you think about the upcoming NUMAcc
systems (Opterons are already there though).
But the fact is
On Sun, 2008-03-02 at 12:34 -0800, Paul Lalonde wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
CSP doesn't scale very well to hundreds of simultaneously executing
threads (my claim, not, as far as I've found yet, anyone else's).
I take it that you really do mean simultaneous. As
On Fri, Feb 29, 2008 at 10:39 PM, Lyndon Nerenberg [EMAIL PROTECTED] wrote:
But none of this code will just work on Plan 9 (especially the
Fortran code), so what's the point?
Why do you say that?
ron
Looking at GCC, there's plenty more effort required before the full
suite of
One way or another, eventually the current flood of software has to
undergo some quality control and at that point it would be good if
there were principles by which to measure such quality.
Perhaps you should look at this page:
http://www.gnu.org/software/reliability.html
It is no fluke
can it compile a working pm?---BeginMessage---
Before I apply some serious effort to bring P9GCC in line with the
latest release, I'd like to convince myself that the effort is worth
it. I'm keen to catch two birds with one stone: (a) make sure that
version 3.0 is sufficiently functional and (b)
can it compile a working pm?
I'll try.
++L
Hello,
At work, most of the users need a fortran compiler (although almost
none of them actually use gfortran, they prefer ifort) and some of them
do parallel computation so they need MPI. If I could have at least
those two items thanks to P9GCC, maybe I could convince some of them to
work on the
Why not just port Version 7 f77 and Version 7 Ratfor?
On Mar 1, 2008, at 9:45 AM, [EMAIL PROTECTED] wrote:
Hello,
At work, most of the users need a fortran compiler (although almost
none of them actually use gfortran, they prefer ifort) and some of
them
do parallel computation so they need
On Sat, Mar 1, 2008 at 12:39 AM, Lyndon Nerenberg [EMAIL PROTECTED] wrote:
On 2008-Feb-29, at 22:02 , Eric Van Hensbergen wrote:
It will no doubt be useful to us folks doing work for the gov't. They
DOE has lots of apps written for GCC or Fortran -- while there may be
other methods
Why not just port Version 7 f77 and Version 7 Ratfor?
Sounds like an idea. Where do I find the source code? Mind you, it's
been tens of years since I programmed in Fortran IV, it's going to be
hard for me to do any testing.
++L
At work, most of the users need a fortran compiler (although almost
none of them actually use gfortran, they prefer ifort) and some of them
do parallel computation so they need MPI. If I could have at least
those two items thanks to P9GCC, maybe I could convince some of them to
work on the
On Sat, Mar 1, 2008 at 9:02 AM, [EMAIL PROTECTED] wrote:
Graphics, networking and multithreading are much bigger issues to
resolve. So your bittorrent client may be difficult to port and damn
easy to redevelop. Any chance you may give it a try?
Networking and multithreading are going
Caldera (now SCO) released the source code a while ago. It has since
been mirrored. The direct links to the f77 and Ratfor are:
http://minnie.tuhs.org/UnixTree/V7/usr/src/cmd/f77
http://minnie.tuhs.org/UnixTree/V7/usr/src/cmd/ratfor
I can get started with it later today.
On Mar 1, 2008, at
On Fri, Feb 29, 2008 at 11:29 PM, Lyndon Nerenberg [EMAIL PROTECTED] wrote:
On 2008-Feb-29, at 23:11 , ron minnich wrote:
But none of this code will just work on Plan 9 (especially the
Fortran code), so what's the point?
Why do you say that?
The lack of a F95 compiler in /bin?
On Sat, Mar 1, 2008 at 7:17 AM, [EMAIL PROTECTED] wrote:
Why not just port Version 7 f77 and Version 7 Ratfor?
Sounds like an idea. Where do I find the source code? Mind you, it's
been tens of years since I programmed in Fortran IV, it's going to be
hard for me to do any testing.
There is a lot of G code that really essentially is only portable to
linux (or close, e.g. BSDs). There is other code that works nearly
everywhere that has a GCC. The why bother pessimism is best
reserved for more suitable occasions. I'm really glad when APE
allows me to compile legacy code and
Also note that neither F77 nor ratfor produced particularly good code.
They did, however, work. Both attributes are required by the Fortran
community.
If the GCC stuff provides this service and you want to do the work
then I won't throw stones.
brucee
On Sun, Mar 2, 2008 at 3:41 AM, ron
On Sat, Mar 01, 2008 at 05:02:59PM +0200, [EMAIL PROTECTED] wrote:
As for me, I'd be pretty happy if I could have a bittorrent client
(especially libtorrent/rtorrent, written in c++) on plan9 so it'd be
rather nice if your P9GCC could achieve building that. But yeah, that
one relies on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If GNU was so reliable we wouldn't see the C compiler generate random
opcodes for architectures we use at my work. And that's *with* the 4x
toolchain.
I think we've all had enough software evangelism. Everyone has bugs. GNU
is absolutely no
If GNU was so reliable we wouldn't see the C compiler generate random
opcodes for architectures we use at my work. And that's *with* the 4x
toolchain.
I think we've all had enough software evangelism. Everyone has bugs. GNU
is absolutely no exception.
they do, with complete reliability,
If GNU was so reliable we wouldn't see the C compiler generate random
opcodes for architectures we use at my work. And that's *with* the 4x
toolchain.
I'm not sure if I read you correctly, but all I'm looking for is some
confidence that P9GCC is worth pursuing. I can't use the supplied
Ron, I think you're confusing ratfor with software tools. There was a
ratfor implementation in C on Unix, and I wrote ratfor when I had to
use Fortran, and others did too, independent of the software tools
effort. The point of Ratfor was to make Fortran bearable; I can't
imagine writing bare
There are a ton of biology tools written in rather simple c++. Those
people are willing to look at p9 if we have two things:
-g++
-python
thanks
ron
On Sat, Mar 1, 2008 at 12:29 PM, [EMAIL PROTECTED] wrote:
Ron, I think you're confusing ratfor with software tools. There was a
ratfor implementation in C on Unix, and I wrote ratfor when I had to
use Fortran, and others did too, independent of the software tools
effort. The point of
I mentioned to skip that you were mistaken but it seemed like
an honest mistake so we had brunch. Where is all the abuse
gone anyway, or are my filters working?
brucee
On Sun, Mar 2, 2008 at 8:36 AM, ron minnich [EMAIL PROTECTED] wrote:
On Sat, Mar 1, 2008 at 12:29 PM, [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have a project on the go that would make an awesome plan9 platform.
Except that all our users code in C++. The complicated kind, with
templates and hideous metaprogramming. And can even show good reason
to do so.
Makes me weep.
Paul
On
On Sat, Mar 1, 2008 at 5:07 PM, Paul Lalonde [EMAIL PROTECTED] wrote:
Except that all our users code in C++. The complicated kind, with
templates and hideous metaprogramming. And can even show good reason
to do so.
welcome to my life.
Lots of holes in the walls around here, roughly the
On Fri, Feb 29, 2008 at 10:55 PM, [EMAIL PROTECTED] wrote:
Please will anybody who has a Plan 9 objective that can only be
attained using GCC/G++ please drop me a line to let me know briefly
what it is? If the whole exercise gets a lot of support, I'll happily
set up more infrastructure
On 2008-Feb-29, at 22:02 , Eric Van Hensbergen wrote:
It will no doubt be useful to us folks doing work for the gov't. They
DOE has lots of apps written for GCC or Fortran -- while there may be
other methods of accommodating these applications, having them just
work with GCC (particularly if
It will no doubt be useful to us folks doing work for the gov't. They
DOE has lots of apps written for GCC or Fortran -- while there may be
other methods of accommodating these applications, having them just
work with GCC (particularly if the GCC fortran could be part of the
port) would help
But none of this code will just work on Plan 9 (especially the
Fortran code), so what's the point?
That is of course true. Thing is, until one moves along, many of
these obvious truths will not be revealed to all interested parties,
nor will alternatives be identified. I really would like
On 2008-Feb-29, at 22:52 , [EMAIL PROTECTED] wrote:
onsider that this has become a non-issue in the world of
Wintel/GNU-Linux by blocking any alternative development paths,
including Plan 9's only slight eccentricities.
But these are the stampeding herd of lemmings that discover, at the
On Fri, Feb 29, 2008 at 10:39 PM, Lyndon Nerenberg [EMAIL PROTECTED] wrote:
But none of this code will just work on Plan 9 (especially the
Fortran code), so what's the point?
Why do you say that?
ron
http://www.mpqc.org/
ron
On 2008-Feb-29, at 23:11 , ron minnich wrote:
But none of this code will just work on Plan 9 (especially the
Fortran code), so what's the point?
Why do you say that?
The lack of a F95 compiler in /bin? (If you have one in house, that's
cheating.)
On 2008-Feb-29, at 23:12 , ron minnich wrote:
http://www.mpqc.org/
Platforms
* Unix Workstations (Intel/Linux, RS/6000, SGI/IRIX)
* Symmetric multi-processors (Intel/Linux, SGI/IRIX)
* Massively parallel (IBM SP, Intel Paragon)
Back to top.
Implementation
* C++ with a few
onsider that this has become a non-issue in the world of
Wintel/GNU-Linux by blocking any alternative development paths,
including Plan 9's only slight eccentricities.
But these are the stampeding herd of lemmings that discover, at the
last minute, they aren't supposed to (and can't) dive
On 2008-Feb-29, at 23:42 , [EMAIL PROTECTED] wrote:
I'm assuming that eventually reason prevails. It would be sad if at
that point there were no options left.
There is a Canadian federal election coming up ...
I'm feeling very depressed.
65 matches
Mail list logo
