All times are UTC-06:00




Post new topic  Reply to topic  [ 15 posts ] 
Author Message
PostPosted: Fri Oct 27, 2006 10:15 am 
Offline

Joined: Thu Feb 02, 2006 7:08 am
Posts: 4
Location: Cologne, Germany
Hi,

I'd be interested to adjust/write some sophisticated AltiVec code for MorphOS, but ran into the problem that without GCC 4.x it'd be quite... well, impossible, to for example compile an AltiVec-optimized DCT algorithm for e.g. JPEG decoding.

Is anyone aware of progress in this direction, i.e. a truly AltiVec-enabled GCC port, which can be used under MorphOS?

Thanks & Regards.


Top
   
 Post subject:
PostPosted: Fri Oct 27, 2006 12:33 pm 
Offline

Joined: Fri Sep 24, 2004 1:39 am
Posts: 429
Location: Secure Networks / Sweden
Well, first of all you would need an AltiVec-enabled
kernel which hasn't been released yet. (MorphOS 1.5)

Second, the MorphOS Team have repeatidly told us
that everything above GCC 2.95 "sucks" and is "full
of bugs".

So don't hold your breath on having GCC 4 to MorphOS.
Chose Gentoo Linux instead. There you have full
AltiVec support and the latest GCC.


Last edited by ironfist on Fri Oct 27, 2006 3:42 pm, edited 1 time in total.

Top
   
 Post subject:
PostPosted: Fri Oct 27, 2006 1:52 pm 
Offline

Joined: Tue Jan 31, 2006 1:18 am
Posts: 49
Location: Bialystok, Poland
Quote:
Second, the MorphOS Team have repeatidly told us that everything above GCC 2.96 "sucks" and is "full of bugs".
And it seems this is unfortunately true for AltiVec support in GCC4. I've got some unofficial GCC4 port from Morgoth (Marcin Kurek). I've compiled fir.filter (a Reggae class) with it and it was 40% slower in tests than version compiled with 2.95.3 + Altivec support. I've looked at disassembled executable and I must say GCC4 generated code is a total disaster, it is three times longer and has some brain-damaged instruction [dis]ordering. Of course it can be broken port, but I doubt it given that the compiler generates working code (but inefficient in case of AltiVec). It may be also caused by some weird optimizations, but I have no time to check every one option out of thousands. At least 2.95.3 compiles exactly what I code :wink:.

It seems that there is no publicly available port of GCC 2.95.x for MOS with AltiVec support. Threre was one on Marcin Kurek projects page, but the link is broken now. Anyway the main obstacle is lack of AltiVec support in public MOS kernels, the only way to get the one with AltiVec enabled is to ask MorphOS Team for one.

_________________
http://krashan.ppa.pl


Top
   
PostPosted: Fri Oct 27, 2006 1:56 pm 
Offline

Joined: Tue Jan 31, 2006 1:18 am
Posts: 49
Location: Bialystok, Poland
Quote:
without GCC 4.x it'd be quite... well, impossible, to for example compile an AltiVec-optimized DCT algorithm for e.g. JPEG decoding.
It is not true. GCC 2.95.3 (with enabled AltiVec) is enough. I've verified it myself compiling many of Reggae classes for MorphOS.

_________________
http://krashan.ppa.pl


Top
   
 Post subject:
PostPosted: Fri Oct 27, 2006 1:59 pm 
Offline

Joined: Fri Sep 24, 2004 1:39 am
Posts: 297
But as long as the mos-kernel itself doesn't support altivec, there's no need for a altivec-support in mos-gcc...

btw gcc-4.1.1 works very good under my altivec-gentoo...


Top
   
 Post subject:
PostPosted: Fri Oct 27, 2006 3:41 pm 
Offline

Joined: Fri Sep 24, 2004 1:39 am
Posts: 429
Location: Secure Networks / Sweden
Frostwork:
Same here. No problems at all with GCC 4.1.1 on
all my Gentoo machines.


Top
   
 Post subject:
PostPosted: Sat Oct 28, 2006 4:02 am 
Offline

Joined: Tue Jan 31, 2006 1:18 am
Posts: 49
Location: Bialystok, Poland
Update: AltiVec enabled GCC 2.95.4-6.

_________________
http://krashan.ppa.pl


Top
   
PostPosted: Wed Dec 06, 2006 1:32 pm 
Offline

Joined: Thu Feb 02, 2006 7:08 am
Posts: 4
Location: Cologne, Germany
Quote:
Quote:
without GCC 4.x it'd be quite... well, impossible, to for example compile an AltiVec-optimized DCT algorithm for e.g. JPEG decoding.
It is not true. GCC 2.95.3 (with enabled AltiVec) is enough. I've verified it myself compiling many of Reggae classes for MorphOS.
That's an interesting statement. I've also tried with the GCC from the MOS SDK but none of the documented AltiVec switches did work. Besides there's no <altivec.h> present. The vector datatype is not known.


Top
   
 Post subject:
PostPosted: Wed Dec 06, 2006 1:35 pm 
Offline

Joined: Thu Feb 02, 2006 7:08 am
Posts: 4
Location: Cologne, Germany
Quote:
Quote:
Second, the MorphOS Team have repeatidly told us that everything above GCC 2.96 "sucks" and is "full of bugs".
And it seems this is unfortunately true for AltiVec support in GCC4. I've got some unofficial GCC4 port from Morgoth (Marcin Kurek). I've compiled fir.filter (a Reggae class) with it and it was 40% slower in tests than version compiled with 2.95.3 + Altivec support. I've looked at disassembled executable and I must say GCC4 generated code is a total disaster, it is three times longer and has some brain-damaged instruction [dis]ordering. Of course it can be broken port, but I doubt it given that the compiler generates working code (but inefficient in case of AltiVec). It may be also caused by some weird optimizations, but I have no time to check every one option out of thousands. At least 2.95.3 compiles exactly what I code :wink:.

It seems that there is no publicly available port of GCC 2.95.x for MOS with AltiVec support. Threre was one on Marcin Kurek projects page, but the link is broken now. Anyway the main obstacle is lack of AltiVec support in public MOS kernels, the only way to get the one with AltiVec enabled is to ask MorphOS Team for one.
Ah, now I see. Sorry, but who cares about unofficial versions anyway? That's exactly the problem, if everyone has to build his own compiler (2.95.x or 4.x) in order to get things working - who knows which other bugs or missing features they have...


Top
   
 Post subject:
PostPosted: Wed Dec 06, 2006 2:38 pm 
Offline

Joined: Thu Feb 02, 2006 7:08 am
Posts: 4
Location: Cologne, Germany
Quote:
But as long as the mos-kernel itself doesn't support altivec, there's no need for a altivec-support in mos-gcc...

btw gcc-4.1.1 works very good under my altivec-gentoo...
Oops. It's surely a problem if AltiVec is not considered in the current ABI and if the MorphOS scheduler does not know about it. Good point.

Besides, as far as I can tell, there are significant differences between how GCC 2.95.x and 3.x/4.x handle AltiVec respectively Motorola and FSF.

When porting/coding AltiVec stuff - let's say with some libjpeg patches as result - of course I'd prefer to do this against the most recent API, for later re-use...


Top
   
 Post subject:
PostPosted: Thu Dec 07, 2006 1:45 am 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1589
Location: Austin, TX
Quote:
Hi Grzegorz,

I would love to expand somewhere on Power Developer about why gcc 4.x (and 3.x) sucks maybe with an example of bad code generation. It would be nice for us (and maybe a nudge for the GCC guys) to put it on a semi-high-profile website and explain which GCC is the best for producing the most optimized code, especially for AltiVec and especially a comparison between AltiVec hand-tuned code, and GCC 4.x's autovectorisation :)

Okay I am not asking you to go into all of that on your own, but this is what Power Developer is for; we should all sit down and work on something, since documenting these kinds of quirks is fairly important. The next Debians, Ubuntus and Fedoras etc. are all compiled with GCC 4 and if they are producing awful code it will not be very good for Power Architecture performance in general.

_________________
Matt Sealey


Top
   
 Post subject:
PostPosted: Mon Dec 11, 2006 2:39 pm 
Offline

Joined: Tue Jan 31, 2006 1:18 am
Posts: 49
Location: Bialystok, Poland
Quote:
I would love to expand somewhere on Power Developer about why gcc 4.x (and 3.x) sucks maybe with an example of bad code generation. It would be nice for us (and maybe a nudge for the GCC guys) to put it on a semi-high-profile website and explain which GCC is the best for producing the most optimized code, especially for AltiVec and especially a comparison between AltiVec hand-tuned code, and GCC 4.x's autovectorisation :)
We should separate two things here, the first one is what GCC 4 does with hand-tuned code (an this is the subject of the paper below), the second one (beyond my scope for now, as autovectorisation is still poor compared to a code written specifically for SIMD operators) is autovectorisation of scalar code.

Anyway here it is: GCC 2 versus GCC 4 compiling AltiVec code, a detailed discussion of a case. Note however this is not a scientific paper in the strict sense - it hasn't undergone peer-review process, it will also not be published neither on any conference, nor journal.

_________________
http://krashan.ppa.pl


Top
   
 Post subject:
PostPosted: Tue Dec 19, 2006 10:08 pm 
Offline

Joined: Thu Feb 16, 2006 8:10 pm
Posts: 98
Quote:
Quote:
I would love to expand somewhere on Power Developer about why gcc 4.x (and 3.x) sucks maybe with an example of bad code generation. It would be nice for us (and maybe a nudge for the GCC guys) to put it on a semi-high-profile website and explain which GCC is the best for producing the most optimized code, especially for AltiVec and especially a comparison between AltiVec hand-tuned code, and GCC 4.x's autovectorisation :)
We should separate two things here, the first one is what GCC 4 does with hand-tuned code (an this is the subject of the paper below), the second one (beyond my scope for now, as autovectorisation is still poor compared to a code written specifically for SIMD operators) is autovectorisation of scalar code.

Anyway here it is: GCC 2 versus GCC 4 compiling AltiVec code, a detailed discussion of a case. Note however this is not a scientific paper in the strict sense - it hasn't undergone peer-review process, it will also not be published neither on any conference, nor journal.
bump:
iv been following a thread http://www.beyond3d.com/forum/showthrea ... post894499
and pointed several of the coders/readers to your post Grzegorz (and Markos) in the hope to get some interesting threads over here as it seems to be almost dead lately, anyway perhaps you might like to pop over there and comment on the reply i just had from a long time games programmer.

the thread itself is intersting since inefficient
'installed the GNU toolchains for Cell development this evening and I'm having too much fun' on his ps3 and started running and investigating Altivec code.
http://www.beyond3d.com/forum/showthrea ... 058&page=7

i find it odd that the ps3/cell sections here arnt better used as yet, it seems noone knows or cared that this place exists ...


Top
   
 Post subject:
PostPosted: Sun Dec 24, 2006 2:25 am 
Offline

Joined: Tue Jan 31, 2006 1:18 am
Posts: 49
Location: Bialystok, Poland
Quote:
iv been following a thread http://www.beyond3d.com/forum/showthrea ... post894499
and pointed several of the coders/readers to your post Grzegorz (and Markos) in the hope to get some interesting threads over here as it seems to be almost dead lately, anyway perhaps you might like to pop over there
Oh, no, not another messy forum. I have enough already... I've read the posts and I can see all they can relpy to me is "GCC4 works with our code". Maybe, but they missed my two main points:

1. The same code compiled with two versions of compiler - an old one and a new one, is significantly slower on a new one - it is unacceptable IMO.

2. GCC4 "advanced" AltiVec instructions scheduling can be easily beaten out with simple hand-tuning (I mean SIMPLE, so no simulations, cycle counting etc.)

_________________
http://krashan.ppa.pl


Top
   
 Post subject:
PostPosted: Sun Dec 24, 2006 11:02 am 
Offline

Joined: Thu Feb 16, 2006 8:10 pm
Posts: 98
:D 'Oh, no, not another messy forum'

true, but its full of the worlds top games industry coders, i also found it interesting that the admission that the bulk of their gaming code isnt optimised and they rely on the compiler to get better results.

happy cristmas :D


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 15 posts ] 

All times are UTC-06:00


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
PowerDeveloper.org: Copyright © 2004-2012, Genesi USA, Inc. The Power Architecture and Power.org wordmarks and the Power and Power.org logos and related marks are trademarks and service marks licensed by Power.org.
All other names and trademarks used are property of their respective owners. Privacy Policy
Powered by phpBB® Forum Software © phpBB Group