2009 Update

[Marcel Moolenaar-4]

All,

Anton Shterenlikht reported various problems when he tried ia64
and I'm pleased to announce some updates:

1.  The kernel panic relating to inconsistent high FP registers
     has been fixed. This also means that the following message
     will not appear on the console anymore:
        XXX: bogusly disabled high FP regs

     Versions fixed: 9-CURRENT
     Fix will be merged to 8-STABLE after 8.0-RELEASE

2.  The failures in perl when threading has been enabled have
     been identified as a compiler bug relating to the use of
     statements in expressions. In other words, the expressions
     of the form:
        ({ ... })

     All test failures were eliminated when these were recoded
     as proper inline functions. The perl port has not been
     fixed at this time. A definite confidence booster for the
     threading support on ia64 and yet another nail in GCC's
     coffin.

3.  I'm working on getting KDE 4 to build again. It's currently
     failing in optional packages. The base KDE 4 infrastructure
     is up and running and Konqueror (the web browser) seems to
     work quite well, though tends to dump core after a while.
     It would be looked into.

4.  GNOME built and ran fine before, but it's possible that
     things have changed. I'll keep playing with it.

Future work:

1.  I got a VNC server for ia64 building and running, but I can't
     reproduce it at this time, so no fixes for the ports yet. With
     a VNC server, a whole set of new programs can be ported and
     tested better.

2.  I'm planning to change PAGE_SIZE to 16K instead of 8K. It be
     good for performance. More on this later.

3.  More compiler and debugger work. GCC is really not good for
     ia64. I'm planning on refocusing some of my attention towards
     compiler work. Related to this is the debugger. GDB is not
     lacking severely on ia64. Note that I don't plan to fix GDB.
     Neither will I fix GCC. I'll be looking elsewhere.

Overall good news. However, the state of GCC and GDB for ia64 is
still a big problem in my opinion.

FYI,

--
Marcel Moolenaar
xcllnt@...



_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

[ToyoRunner]

Marcel,

Glad to hear that your efforts are paying off. Thanks for all your hard work.

On Fri, Nov 6, 2009 at 10:52 AM, Marcel Moolenaar <xcllnt@...> wrote:

> All,
>
> Anton Shterenlikht reported various problems when he tried ia64
> and I'm pleased to announce some updates:
>
> 1.  The kernel panic relating to inconsistent high FP registers
>    has been fixed. This also means that the following message
>    will not appear on the console anymore:
>        XXX: bogusly disabled high FP regs
>
>    Versions fixed: 9-CURRENT
>    Fix will be merged to 8-STABLE after 8.0-RELEASE
>
> 2.  The failures in perl when threading has been enabled have
>    been identified as a compiler bug relating to the use of
>    statements in expressions. In other words, the expressions
>    of the form:
>        ({ ... })
>
>    All test failures were eliminated when these were recoded
>    as proper inline functions. The perl port has not been
>    fixed at this time. A definite confidence booster for the
>    threading support on ia64 and yet another nail in GCC's
>    coffin.
>
> 3.  I'm working on getting KDE 4 to build again. It's currently
>    failing in optional packages. The base KDE 4 infrastructure
>    is up and running and Konqueror (the web browser) seems to
>    work quite well, though tends to dump core after a while.
>    It would be looked into.
>
> 4.  GNOME built and ran fine before, but it's possible that
>    things have changed. I'll keep playing with it.
>
> Future work:
>
> 1.  I got a VNC server for ia64 building and running, but I can't
>    reproduce it at this time, so no fixes for the ports yet. With
>    a VNC server, a whole set of new programs can be ported and
>    tested better.
>
> 2.  I'm planning to change PAGE_SIZE to 16K instead of 8K. It be
>    good for performance. More on this later.
>
> 3.  More compiler and debugger work. GCC is really not good for
>    ia64. I'm planning on refocusing some of my attention towards
>    compiler work. Related to this is the debugger. GDB is not
>    lacking severely on ia64. Note that I don't plan to fix GDB.
>    Neither will I fix GCC. I'll be looking elsewhere.
>
> Overall good news. However, the state of GCC and GDB for ia64 is
> still a big problem in my opinion.
>
> FYI,
>
> --
> Marcel Moolenaar
> xcllnt@...
>
>
>
> _______________________________________________
> freebsd-ia64@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
> To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."
>

_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

[Anton Shterenlikht]

On Fri, Nov 06, 2009 at 09:52:25AM -0800, Marcel Moolenaar wrote:
>
> 3.  More compiler and debugger work. GCC is really not good for
>      ia64. I'm planning on refocusing some of my attention towards
>      compiler work. Related to this is the debugger. GDB is not
>      lacking severely on ia64. Note that I don't plan to fix GDB.
>      Neither will I fix GCC. I'll be looking elsewhere.

This seems a major undertaking. Also, what will happen to
a miriad of GCC-dependent ports?

many thanks
anton

--
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: [phone]
Fax: [phone]
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

["C. Bergström"-2]

Anton Shterenlikht wrote:

> On Fri, Nov 06, 2009 at 09:52:25AM -0800, Marcel Moolenaar wrote:
>  
>> 3.  More compiler and debugger work. GCC is really not good for
>>      ia64. I'm planning on refocusing some of my attention towards
>>      compiler work. Related to this is the debugger. GDB is not
>>      lacking severely on ia64. Note that I don't plan to fix GDB.
>>      Neither will I fix GCC. I'll be looking elsewhere.
>>    
>
> This seems a major undertaking. Also, what will happen to
> a miriad of GCC-dependent ports?
>  

I'm willing to make PathScale's PathDB CDDL or possibly BSD licensed.  
I've been planning this for months, it has the green light and I'm the
bottleneck.  If there's interest it could serve a dual purpose of
building a providing a more liberal licensed debugger for the BSD
community/open source and share the workload beyond the ia64 community.  
I've not reviewed the code to know the quality, but I'm happy to give
anyone access to the source.  Once the headers are updated and there's a
plan going forward we can make it publicly available.

http://hg.pathscale.com
Just let me know your username and I'll give you access.


It may also be possible for PathScale's compiler to be getting a major
improvement in the near future that would benefit IA64 and other
targets.  It's still uncertain, but I'd love to see it happen.  Parts of
our fully open source compiler project are being held up by some legal
issues beyond my control.  The parts that are pending wouldn't inhibit
finishing our BSD port and or get in the way of anything ia64 related.

Between now and after SC09 (SuperComputing) I apologize if I'm slow to
respond to emails.  irc is best for quick questions or to say hi..


Christopher

CTO PathScale
#pathscale irc.freenode.net

(Sent from my open source email)
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

[Anton Shterenlikht]

On Sat, Nov 07, 2009 at 05:26:27PM -0500, "C. Bergström" wrote:

> Anton Shterenlikht wrote:
> > On Fri, Nov 06, 2009 at 09:52:25AM -0800, Marcel Moolenaar wrote:
> >  
> >> 3.  More compiler and debugger work. GCC is really not good for
> >>      ia64. I'm planning on refocusing some of my attention towards
> >>      compiler work. Related to this is the debugger. GDB is not
> >>      lacking severely on ia64. Note that I don't plan to fix GDB.
> >>      Neither will I fix GCC. I'll be looking elsewhere.
> >>    
> >
> > This seems a major undertaking. Also, what will happen to
> > a miriad of GCC-dependent ports?
> >  
> I'm willing to make PathScale's PathDB CDDL or possibly BSD licensed.  
> I've been planning this for months, it has the green light and I'm the
> bottleneck.  If there's interest it could serve a dual purpose of
> building a providing a more liberal licensed debugger for the BSD
> community/open source and share the workload beyond the ia64 community.  
> I've not reviewed the code to know the quality, but I'm happy to give
> anyone access to the source.  Once the headers are updated and there's a
> plan going forward we can make it publicly available.
>
> http://hg.pathscale.com
> Just let me know your username and I'll give you access.
>
>
> It may also be possible for PathScale's compiler to be getting a major
> improvement in the near future that would benefit IA64 and other
> targets.  It's still uncertain, but I'd love to see it happen.  Parts of
> our fully open source compiler project are being held up by some legal
> issues beyond my control.  The parts that are pending wouldn't inhibit
> finishing our BSD port and or get in the way of anything ia64 related.
>
> Between now and after SC09 (SuperComputing) I apologize if I'm slow to
> respond to emails.  irc is best for quick questions or to say hi..

There are 6 ia64 systems on top500 list (details below). All
run linux, of course. But these organisations must use
very good compilers, and, at least for nuclear codes (systems 71
and 96), these will be f90-f95 or even f2003 (I don't know of
any f2008) compilers. Perhaps they do use PathScale and
forget about GCC..

anton

################

Rank Site System Cores Rmax Rpeak
58 NASA/Ames Research Center/NAS
United States SGI Altix 1.5/1.6/1.66 GHz, Voltaire Infiniband
SGI 13824 66.57 82.94

66 Leibniz Rechenzentrum
Germany Altix 4700 1.6 GHz
SGI 9728 56.52 62.26

71 Commissariat a l'Energie Atomique (CEA)
France NovaScale 5160, Itanium2 1.6 GHz, Quadrics
Bull SA 9968 52.84 63.8

75 Wright-Patterson Air Force Base/DoD ASC
United States Altix 4700 1.6 GHz
SGI 9216 51.44 58.98

96 Commissariat a l'Energie Atomique (CEA)
France Novascale 3045, Itanium2 1.6 GHz, Infiniband
Bull SA 7680 42.13 49.15

325 Government Classified
United States Cluster Platform 6000 rx1620, Itanium2 1.6 GHz, Quadrics
Hewlett-Packard 4096 20.45 26.21te

--
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: [phone]
Fax: [phone]
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

[Peter Chubb-2]

>>>>> "Anton" == Anton Shterenlikht <mexas@...> writes:

Anton> On Sat, Nov 07, 2009 at 05:26:27PM -0500, "C. Bergström" wrote:

Anton> There are 6 ia64 systems on top500 list (details below). All
Anton> run linux, of course. But these organisations must use very
Anton> good compilers, and, at least for nuclear codes (systems 71 and
Anton> 96), these will be f90-f95 or even f2003 (I don't know of any
Anton> f2008) compilers. Perhaps they do use PathScale and forget
Anton> about GCC..

Most use the Intel compiler, and heavy hand-optimization of inner
loops using tools like vTune.

Gelato put a lot of effort into imprving gcc for IA64 -- gcc 4.x is
miles better than gcc 3.x -- but there's still a lot that could be done
with low-level instruction scheduling.

Peter C

--
Dr Peter Chubb www.nicta.com.au    peter DOT chubb AT nicta.com.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

["C. Bergström"-2]

Peter Chubb wrote:

>>>>>> "Anton" == Anton Shterenlikht <mexas@...> writes:
>>>>>>            
>
> Anton> On Sat, Nov 07, 2009 at 05:26:27PM -0500, "C. Bergström" wrote:
>
> Anton> There are 6 ia64 systems on top500 list (details below). All
> Anton> run linux, of course. But these organisations must use very
> Anton> good compilers, and, at least for nuclear codes (systems 71 and
> Anton> 96), these will be f90-f95 or even f2003 (I don't know of any
> Anton> f2008) compilers. Perhaps they do use PathScale and forget
> Anton> about GCC..
>
> Most use the Intel compiler, and heavy hand-optimization of inner
> loops using tools like vTune.
>
> Gelato put a lot of effort into imprving gcc for IA64 -- gcc 4.x is
> miles better than gcc 3.x -- but there's still a lot that could be done
> with low-level instruction scheduling.
>
>  

I do not normally discourage people to work on other compilers, but
working on GCC for IA64 is a complete waste of time.  With that I do
agree the current situation for IA64 is less than ideal.. I'm happy to
hear complaints and do what is within my resources and capability to fix..

Small notes..
    a) PathScale doesn't currently support IA64
    b) I would like to merge in some code that would give us a near
optimal CG for IA64.  That in combination with a couple other things
would hopefully bring us in the same ballpark as the Intel IA64
compiler.  (Pure speculation as I don't know this target very well or
current state of Intel compiler)
    c) We're happy to help test and verify changes for IA64 with the
PathScale QA harness, but need to acquire hardware.  This is something I
may personally have money for and can put in our datacenter, but there
is currently no company budget.


./C

_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

[Peter Chubb-2]

>>>>> "C" == C Bergström <codestr0m@...> writes:

C> Peter Chubb wrote:
>>>>>>> "Anton" == Anton Shterenlikht <mexas@...> writes:
>>>>>>>
>>
Anton> On Sat, Nov 07, 2009 at 05:26:27PM -0500, "C. Bergström" wrote:
>>
Anton> There are 6 ia64 systems on top500 list (details below). All
Anton> run linux, of course. But these organisations must use very
Anton> good compilers, and, at least for nuclear codes (systems 71 and
Anton> 96), these will be f90-f95 or even f2003 (I don't know of any
Anton> f2008) compilers. Perhaps they do use PathScale and forget
Anton> about GCC..
>> Most use the Intel compiler, and heavy hand-optimization of inner
>> loops using tools like vTune.
>>
>> Gelato put a lot of effort into imprving gcc for IA64 -- gcc 4.x is
>> miles better than gcc 3.x -- but there's still a lot that could be
>> done with low-level instruction scheduling.
>>
>>
C> I do not normally discourage people to work on other compilers, but
C> working on GCC for IA64 is a complete waste of time.  With that I
C> do agree the current situation for IA64 is less than ideal.. I'm
C> happy to hear complaints and do what is within my resources and
C> capability to fix..


The reason we put so much effort into attempting to improve things is
that most people will just try to run their code with the compiler(s)
they already know.  And the code generated by gcc was appalling, so
Itanium appeared to suck badly.  Fixing GCC meant that users could
continue to use the toolchains they already knew, and maybe they'd get
halfway decent results.    The stuff we did is documented at
http://gcc.gelato.org/



People can still do better, by using the Intel compiler, but even it
was non-optimal for system code (although I haven't tried it recently:
it may have improved), and needed (again, I haven't looked recently,
this may be out of date) careful tuning to get good performance for
enterprise workloads.

--
Dr Peter Chubb www.nicta.com.au    peter DOT chubb AT nicta.com.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

["C. Bergström"-2]

Peter Chubb wrote:
> ...
> The reason we put so much effort into attempting to improve things is
> that most people will just try to run their code with the compiler(s)
> they already know.
We have a GCC front-end to make the learning curve much easier for
exactly the reason you stated above.  I'm happy to work with the gelato
community if there's interest and I can help in some way.
_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."

[Marcel Moolenaar-4]

[combined response]

On Nov 7, 2009, at 5:08 PM, Peter Chubb wrote:

> Gelato put a lot of effort into imprving gcc for IA64 -- gcc 4.x is
> miles better than gcc 3.x -- but there's still a lot that could be done
> with low-level instruction scheduling.

My immediate concern is correctness. Improving SPECcpu20xx looks good
academically, but means nothing to me in the context of FreeBSD if it
means spending a lot time finding work-arounds for correctness bugs.

At this time we can't compile the kernel correctly when all debugging
options are removed and I think we actually have a more optimal OS
with a compiler that generates less-optimal, but correct code than
what we now have with GCC 4.2.1. I find that bizarre..

I would probably stick with GCC much more longer if it would at least
generate correct code. Nonetheless, any future improvements that people
may make, may not be usable by FreeBSD due to licensing anyway, so to
me it's not as simple as "just fix what's broken"...


On Nov 7, 2009, at 9:16 PM, C. Bergström wrote:

> Small notes..
>   a) PathScale doesn't currently support IA64

Another aspect, again specifically in the context of FreeBSD, is that
architecture support in PathScale (or Open64) is limited. As such,
it won't easily be the next system compiler. At this time LLVM has
the best chance of replacing GCC, if GCC is ever being replaced.
Alas, the LLVM project recently removed the ia64 backend due to lack
of support. Just my luck :-)

While PathScale (and Open64) are great compilers for in the ports
collection and I would be very happy to see that happen, I do need
to keep an eye out for any developments involving the system compiler
and I may be forced to work on that just to keep FreeBSD on ia64
viable without forking off...

>   b) I would like to merge in some code that would give us a near optimal CG for IA64.  That in combination with a couple other things would hopefully bring us in the same ballpark as the Intel IA64 compiler.  (Pure speculation as I don't know this target very well or current state of Intel compiler)

Speculation is the correct word: the Intel compiler utilizes data
and control speculation and achieves good results in certain cases
because of it. The use of explicit prefetch operations also helps
to prime the cache with good results.

The CG for Itanium in PathScale should utilize this as well to be
in the same ballpark as the Intel compiler. At least, that's what
I assume it should do. If the code comes from Open64, then I think
you'll be in the same ballpark. People (including Intel as part of
the ORC project) have done a great job.


On Nov 7, 2009, at 10:43 PM, Peter Chubb wrote:

> The reason we put so much effort into attempting to improve things is
> that most people will just try to run their code with the compiler(s)
> they already know.

I can see that. Then again, I also fail to see it. With autoconf
and libtool, compiler differences should be non-issues and the
only thing developers should do is actually write portable code.

I believe that there's an even deeper and darker consequence to
the statement that people just try with the compiler they already
know and that is that the assumptions embedded in the code about
the architecture are not expected to cause problems.

Itanium did cause a lot of code churn while porting code from
i386 to ia64 and it wasn't just for being 64-bit. Still a lot
of code uses 'int' for variables that are never negative when
'unsigned int' yields more optimal code simply because it avoids
an unnecessary sign-extension.

What I'm trying to say is that assumptions about the compiler are
just a part of the problem and it's probably a smaller problem
than assumptions embedded in the code that cause unique problems
on Itanium. Assumptions about the architecture may have a bigger
impact on the resulting performance than assumptions about the
compiler will have.

It's good to keep as much the same if so many things change, so
Gelato's work has been good and beneficial. I was more in touch
when I worked @HP then I am now, so I don't know all the good
Gelato has done.

--
Marcel Moolenaar
xcllnt@...



_______________________________________________
freebsd-ia64@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@..."