Hi, We have compiled a h.264 decoder with or32 gcc. The option we used are O2 and rename-register. When compared with ARM binary, which only consists of 32-bit instructions, the code size is about 1.6 times of ARM's and the execution time is 1.5x~2x of ARM's. Many reference claims the GCC is very competitive when compared with commerical compiler. So, the result seems not reasonable. Is there something wrong with the option I used? Or is it just because the porting of OR32 is not efficient enough? Best regards, Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/openrisc/attachments/20060208/d455e63b/attachment.htm

Hi Ron, There are many factors that could be affecting your performance. First, what compiler did you use for compiling the ARM code? If you had used any specialized compiler made for ARM (e.g. something that you bought from ARM), it will definitely put some ARM specific optimization that generic GCC cannot take care of. These compilers generally can outperform GCC. Let's say you are also using an ARM port of GCC and you are comparing it with or32-gcc. In ARM-GCC [if my memory serves correctly], they do some machine specific optimization (called machine_dependent_reorganisation) which takes care of optimizing the code. OR32 doesn't do it. This could affect both code size and execution time. GCC is as competitive as you want to make it. You can use gcc and put enough machine specific optimizations in it to make it good. I really doubt it will be as good as a compiler that a processor vendor might supply (e.g. ECC by Intel), but GCC can get close. If you want some example of these machine specific optimizations, please take a look at an IA64 port (Inside the directory: gcc-4.0.0/gcc/config/ia64). There are different optimizations you can try that will improve the scheduling window. You can try to use -O3 if you like. O3 will turn on function inlining and also register renaming (which I think you are explicitly doing anyway). I have not had too much experience with this, but you can try -fsched2-use-traces which will attempt to do an extended basic block scheduling and I have found slight improvement in some architectures. Also you also try -fsched2-use-superblocks which will attempt to do superblock scheduling. I hope this helps. Thanking You, Yours Sincerely, Balaji V. Iyer. _____ From: openrisc-bounces at opencores.org [mailto:openrisc-bounces at opencores.org] On Behalf Of Ron Hui Sent: Wednesday, February 08, 2006 8:13 AM To: openrisc at opencores.org Subject: [openrisc] question about OR32 compiler efficiency Hi, We have compiled a h.264 decoder with or32 gcc. The option we used are O2 and rename-register. When compared with ARM binary, which only consists of 32-bit instructions, the code size is about 1.6 times of ARM's and the execution time is 1.5x~2x of ARM's. Many reference claims the GCC is very competitive when compared with commerical compiler. So, the result seems not reasonable. Is there something wrong with the option I used? Or is it just because the porting of OR32 is not efficient enough? Best regards, Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/openrisc/attachments/20060208/403093d3/attachment.htm

Hi, Unfortunately, I don't know how to do the optimization of GCC. Is there any plan to add machine_dependent_reorganisation for OR32? Best regards, Ron ----- Original Message ----- From: Balaji V. Iyer To: 'List about OpenRISC project' Sent: Wednesday, February 08, 2006 10:00 PM Subject: RE: [openrisc] question about OR32 compiler efficiency Hi Ron, There are many factors that could be affecting your performance. First, what compiler did you use for compiling the ARM code? If you had used any specialized compiler made for ARM (e.g. something that you bought from ARM), it will definitely put some ARM specific optimization that generic GCC cannot take care of. These compilers generally can outperform GCC. Let's say you are also using an ARM port of GCC and you are comparing it with or32-gcc. In ARM-GCC [if my memory serves correctly], they do some machine specific optimization (called machine_dependent_reorganisation) which takes care of optimizing the code. OR32 doesn't do it. This could affect both code size and execution time. GCC is as competitive as you want to make it. You can use gcc and put enough machine specific optimizations in it to make it good. I really doubt it will be as good as a compiler that a processor vendor might supply (e.g. ECC by Intel), but GCC can get close. If you want some example of these machine specific optimizations, please take a look at an IA64 port (Inside the directory: gcc-4.0.0/gcc/config/ia64). There are different optimizations you can try that will improve the scheduling window. You can try to use -O3 if you like. O3 will turn on function inlining and also register renaming (which I think you are explicitly doing anyway). I have not had too much experience with this, but you can try -fsched2-use-traces which will attempt to do an extended basic block scheduling and I have found slight improvement in some architectures. Also you also try -fsched2-use-superblocks which will attempt to do superblock scheduling. I hope this helps. Thanking You, Yours Sincerely, Balaji V. Iyer. ------------------------------------------------------------------------------ From: openrisc-bounces at opencores.org [mailto:openrisc-bounces at opencores.org] On Behalf Of Ron Hui Sent: Wednesday, February 08, 2006 8:13 AM To: openrisc at opencores.org Subject: [openrisc] question about OR32 compiler efficiency Hi, We have compiled a h.264 decoder with or32 gcc. The option we used are O2 and rename-register. When compared with ARM binary, which only consists of 32-bit instructions, the code size is about 1.6 times of ARM's and the execution time is 1.5x~2x of ARM's. Many reference claims the GCC is very competitive when compared with commerical compiler. So, the result seems not reasonable. Is there something wrong with the option I used? Or is it just because the porting of OR32 is not efficient enough? Best regards, Ron ------------------------------------------------------------------------------ _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/openrisc/attachments/20060208/9349781d/attachment.html

Damjan, Can you please give me an approximate figure as to when these improved tools and architecture will be available? Thanks, Balaji V. Iyer. -----Original Message----- From: openrisc-bounces at opencores.org [mailto:openrisc-bounces at opencores.org] On Behalf Of Damjan Lampret Sent: Wednesday, February 08, 2006 10:12 AM To: List about OpenRISC project Subject: Re: [openrisc] question about OR32 compiler efficiency Ron, the second generation openrisc architecture is in the works, with many optimizations for code size and performance both in the architecture as well as in the GCC compiler. regards Damjan ----- Original Message ----- From: "Ron Hui" ronald at interqos.com> To: "List about OpenRISC project" openrisc at opencores.org> Sent: Wednesday, February 08, 2006 3:41 PM Subject: Re: [openrisc] question about OR32 compiler efficiency Hi, Unfortunately, I don't know how to do the optimization of GCC. Is there any plan to add machine_dependent_reorganisation for OR32? Best regards, Ron ----- Original Message ----- From: Balaji V. Iyer To: 'List about OpenRISC project' Sent: Wednesday, February 08, 2006 10:00 PM Subject: RE: [openrisc] question about OR32 compiler efficiency Hi Ron, There are many factors that could be affecting your performance. First, what compiler did you use for compiling the ARM code? If you had used any specialized compiler made for ARM (e.g. something that you bought from ARM), it will definitely put some ARM specific optimization that generic GCC cannot take care of. These compilers generally can outperform GCC. Let's say you are also using an ARM port of GCC and you are comparing it with or32-gcc. In ARM-GCC [if my memory serves correctly], they do some machine specific optimization (called machine_dependent_reorganisation) which takes care of optimizing the code. OR32 doesn't do it. This could affect both code size and execution time. GCC is as competitive as you want to make it. You can use gcc and put enough machine specific optimizations in it to make it good. I really doubt it will be as good as a compiler that a processor vendor might supply (e.g. ECC by Intel), but GCC can get close. If you want some example of these machine specific optimizations, please take a look at an IA64 port (Inside the directory: gcc-4.0.0/gcc/config/ia64). There are different optimizations you can try that will improve the scheduling window. You can try to use -O3 if you like. O3 will turn on function inlining and also register renaming (which I think you are explicitly doing anyway). I have not had too much experience with this, but you can try -fsched2-use-traces which will attempt to do an extended basic block scheduling and I have found slight improvement in some architectures. Also you also try -fsched2-use-superblocks which will attempt to do superblock scheduling. I hope this helps. Thanking You, Yours Sincerely, Balaji V. Iyer. ---------------------------------------------------------------------------- -- From: openrisc-bounces at opencores.org [mailto:openrisc-bounces at opencores.org] On Behalf Of Ron Hui Sent: Wednesday, February 08, 2006 8:13 AM To: openrisc at opencores.org Subject: [openrisc] question about OR32 compiler efficiency Hi, We have compiled a h.264 decoder with or32 gcc. The option we used are O2 and rename-register. When compared with ARM binary, which only consists of 32-bit instructions, the code size is about 1.6 times of ARM's and the execution time is 1.5x~2x of ARM's. Many reference claims the GCC is very competitive when compared with commerical compiler. So, the result seems not reasonable. Is there something wrong with the option I used? Or is it just because the porting of OR32 is not efficient enough? Best regards, Ron ---------------------------------------------------------------------------- -- _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc ---------------------------------------------------------------------------- ---- _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

Ron, the second generation openrisc architecture is in the works, with many optimizations for code size and performance both in the architecture as well as in the GCC compiler. regards Damjan ----- Original Message ----- From: "Ron Hui" ronald at interqos.com> To: "List about OpenRISC project" openrisc at opencores.org> Sent: Wednesday, February 08, 2006 3:41 PM Subject: Re: [openrisc] question about OR32 compiler efficiency Hi, Unfortunately, I don't know how to do the optimization of GCC. Is there any plan to add machine_dependent_reorganisation for OR32? Best regards, Ron ----- Original Message ----- From: Balaji V. Iyer To: 'List about OpenRISC project' Sent: Wednesday, February 08, 2006 10:00 PM Subject: RE: [openrisc] question about OR32 compiler efficiency Hi Ron, There are many factors that could be affecting your performance. First, what compiler did you use for compiling the ARM code? If you had used any specialized compiler made for ARM (e.g. something that you bought from ARM), it will definitely put some ARM specific optimization that generic GCC cannot take care of. These compilers generally can outperform GCC. Let's say you are also using an ARM port of GCC and you are comparing it with or32-gcc. In ARM-GCC [if my memory serves correctly], they do some machine specific optimization (called machine_dependent_reorganisation) which takes care of optimizing the code. OR32 doesn't do it. This could affect both code size and execution time. GCC is as competitive as you want to make it. You can use gcc and put enough machine specific optimizations in it to make it good. I really doubt it will be as good as a compiler that a processor vendor might supply (e.g. ECC by Intel), but GCC can get close. If you want some example of these machine specific optimizations, please take a look at an IA64 port (Inside the directory: gcc-4.0.0/gcc/config/ia64). There are different optimizations you can try that will improve the scheduling window. You can try to use -O3 if you like. O3 will turn on function inlining and also register renaming (which I think you are explicitly doing anyway). I have not had too much experience with this, but you can try -fsched2-use-traces which will attempt to do an extended basic block scheduling and I have found slight improvement in some architectures. Also you also try -fsched2-use-superblocks which will attempt to do superblock scheduling. I hope this helps. Thanking You, Yours Sincerely, Balaji V. Iyer. ------------------------------------------------------------------------------ From: openrisc-bounces at opencores.org [mailto:openrisc-bounces at opencores.org] On Behalf Of Ron Hui Sent: Wednesday, February 08, 2006 8:13 AM To: openrisc at opencores.org Subject: [openrisc] question about OR32 compiler efficiency Hi, We have compiled a h.264 decoder with or32 gcc. The option we used are O2 and rename-register. When compared with ARM binary, which only consists of 32-bit instructions, the code size is about 1.6 times of ARM's and the execution time is 1.5x~2x of ARM's. Many reference claims the GCC is very competitive when compared with commerical compiler. So, the result seems not reasonable. Is there something wrong with the option I used? Or is it just because the porting of OR32 is not efficient enough? Best regards, Ron ------------------------------------------------------------------------------ _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc --------------------------------------------------------------------------------

Balaji, I don't want to make any public statements when exactly it is going to be available due to amount of work. But I'd say time frame is probably around 6 months - but don't hold my word for it. regards Damjan ----- Original Message ----- From: "Balaji V. Iyer" bviyer at ncsu.edu> To: "'List about OpenRISC project'" openrisc at opencores.org> Sent: Wednesday, February 08, 2006 4:10 PM Subject: RE: [openrisc] question about OR32 compiler efficiency

Hi Rish_d, Your experience is very informative. Depending on what architecture you are using, the bottleneck can be different. For example, if you use an 8-issue VLIW to do CABAC, you'll waste most of issue slots. If you use RISC, it does not consume too much cycles. But you are right, the first step of optimization is performance profiling to find the bottleneck. Regarding my previous post about OR32 compiler performance, I found one of the possible reason is that the compiler doesn't generate SIMD instruction. Any one know when the compiler will support SIMD? Best regards, Ron ----- Original Message ----- From: rich_d To: List about OpenRISC project Sent: Thursday, February 09, 2006 2:52 PM Subject: Re: [openrisc] question about OR32 compiler efficiency Hi, These comparisons can be tricky as others have suggested. You might try and determine those areas that are resource intensive (say like CABAC --if I remember correctly) and hand optimize those portions of the code. I worked on an early H.264 decoder SOC for one of the big guys a couple of years ago that used ARC processors with a commercial compiler(lot of optimization options that seemed destined for use). However the trade-offs for the compiler's optimizations(and there are usually tradeoffs) became costly when the code hit real hardware and selective hand optimization ended up being required anyhow. Regards, Rich D Ron Hui wrote: Hi, Unfortunately, I don't know how to do the optimization of GCC. Is there any plan to add machine_dependent_reorganisation for OR32? Best regards, Ron ----- Original Message ----- From: Balaji V. Iyer To: 'List about OpenRISC project' Sent: Wednesday, February 08, 2006 10:00 PM Subject: RE: [openrisc] question about OR32 compiler efficiency Hi Ron, There are many factors that could be affecting your performance. First, what compiler did you use for compiling the ARM code? If you had used any specialized compiler made for ARM (e.g. something that you bought from ARM), it will definitely put some ARM specific optimization that generic GCC cannot take care of. These compilers generally can outperform GCC. Let's say you are also using an ARM port of GCC and you are comparing it with or32-gcc. In ARM-GCC [if my memory serves correctly], they do some machine specific optimization (called machine_dependent_reorganisation) which takes care of optimizing the code. OR32 doesn't do it. This could affect both code size and execution time. GCC is as competitive as you want to make it. You can use gcc and put enough machine specific optimizations in it to make it good. I really doubt it will be as good as a compiler that a processor vendor might supply (e.g. ECC by Intel), but GCC can get close. If you want some example of these machine specific optimizations, please take a look at an IA64 port (Inside the directory: gcc-4.0.0/gcc/config/ia64). There are different optimizations you can try that will improve the scheduling window. You can try to use -O3 if you like. O3 will turn on function inlining and also register renaming (which I think you are explicitly doing anyway). I have not had too much experience with this, but you can try -fsched2-use-traces which will attempt to do an extended basic block scheduling and I have found slight improvement in some architectures. Also you also try -fsched2-use-superblocks which will attempt to do superblock scheduling. I hope this helps. Thanking You, Yours Sincerely, Balaji V. Iyer. -------------------------------------------------------------------------- From: openrisc-bounces at opencores.org [mailto:openrisc-bounces at opencores.org] On Behalf Of Ron Hui Sent: Wednesday, February 08, 2006 8:13 AM To: openrisc at opencores.org Subject: [openrisc] question about OR32 compiler efficiency Hi, We have compiled a h.264 decoder with or32 gcc. The option we used are O2 and rename-register. When compared with ARM binary, which only consists of 32-bit instructions, the code size is about 1.6 times of ARM's and the execution time is 1.5x~2x of ARM's. Many reference claims the GCC is very competitive when compared with commerical compiler. So, the result seems not reasonable. Is there something wrong with the option I used? Or is it just because the porting of OR32 is not efficient enough? Best regards, Ron -------------------------------------------------------------------------- _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc ---------------------------------------------------------------------------- _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc ------------------------------------------------------------------------------ _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/openrisc/attachments/20060209/24cc3151/attachment.html

Hi,
These comparisons can be tricky as others have suggested.

You might try and determine those areas that are resource intensive (say
like CABAC --if I remember correctly) and hand optimize those portions
of the code.

I worked on an early H.264 decoder SOC for one of the big guys a couple
of years ago that used ARC processors with a commercial compiler(lot of
optimization options that seemed destined for use).

However the trade-offs for the compiler's optimizations(and there are
usually tradeoffs) became costly when the code hit real hardware and
selective hand optimization ended up being required anyhow.

Regards,

Rich D

Ron Hui wrote:

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/openrisc/attachments/20060209/de07a549/attachment-0001.html

Hi ! FYI recently we have made some comparison against the 32-bit MIPS code. OR32 turned out to be much bigger than MIPS, until we realized that the code was compiled in one case with hard floating point and in the other with soft floating point. When code was compiled the same way for both MIPS and OR32, size was about the same. regards Damjan ----- Original Message ----- From: "Ron Hui" ronald at interqos.com> To: openrisc at opencores.org> Sent: Wednesday, February 08, 2006 2:13 PM Subject: [openrisc] question about OR32 compiler efficiency Hi, We have compiled a h.264 decoder with or32 gcc. The option we used are O2 and rename-register. When compared with ARM binary, which only consists of 32-bit instructions, the code size is about 1.6 times of ARM's and the execution time is 1.5x~2x of ARM's. Many reference claims the GCC is very competitive when compared with commerical compiler. So, the result seems not reasonable. Is there something wrong with the option I used? Or is it just because the porting of OR32 is not efficient enough? Best regards, Ron --------------------------------------------------------------------------------

Hi Ron, You are correct. You need to write a lot of assembly to use SIMD instructions. There are very few commercial compilers (for other architechtures) which can generate SIMD instructions. You have to hand-code SIMD instructions in assembly, which will require a lot of time and effort. And for a complex code like H.264, it will take time and efforts to achieve the advantage of SIMD instructions. I would like to ask one thing: Are there anySIMD instrinsics which we can call from C code, just like in case of commercial processors. BTW, let us know if you find any other solution or some good commercial compiler for OR32. Regards, Mish -- View this message in context: http://www.nabble.com/question-about-OR32-compiler-efficiency-t1082680.html#a3531157 Sent from the OpenCores - RISC forum at Nabble.com.

hello rich, can u plz send me the design ideas for h264 decoder?? ----- Original Message ----- From: rich_drdaddio at a...> To: Date: Thu Feb 9 07:52:36 CET 2006 Subject: [openrisc] question about OR32 compiler efficiency
-----

attachment-0001.html >

------

>attachment-0001.html > -------------- next part

Hi, It has been a few years for me on h.264 stuff, but I will go back and look at my notes and see if I have anything useful and non-proprietary. Best Regards, Rich D ----- Original Message ----- From: Nishant_ashok2003 at yahoo.comNishant_ashok2003 at y...> To: Date: Tue Oct 31 09:15:19 CET 2006 Subject: [openrisc] question about OR32 compiler efficiency