Comparison of quality of generated code by the compilers
One important attribute of compilers is the quality of the generated code . To assess the difference between the quality of the generated codes of the compilers an experimental design may be used . Assume the following design is used . Select n distinct ( large as much as possible ) programs in such a way that any source file in a program does not appear in another program ( except compiler libraries ) to prevent correlation between programs where programs should be independent from each other . If sample size is not computed from power of the tests formulas , select a sample size at least greater than 15 . A sample size greater than 60 is extremely valuable . Only two compilers are compared . All of the programs are compilable by the compilers . Execute programs and record their success or failure in the following structure : ProgramCLang GCC --- 1 0 or 10 or 1 2 0 or 10 or 1 . . . n 0 or 10 or 1 where 0 is success ( only correct results without a crash ) 1 is failure ( crash or incorrect results ) . When there are failures , generate a cross tabulation of the above table : GCCGCC Success ( 0 ) Failure ( 1 ) | |--- CLang Success | count of ( 0 , 0 )| count of ( 0 , 1 ) | pairs| pairs | |--- CLang Failure | count of ( 1 , 0 ) | count of ( 1 , 1 ) | pairs | pairs | -| One of the following tests with respect to table structure ( especially number of programs ) may be applied . http://en.wikipedia.org/wiki/Barnard%27s_exact_test ( Barnard's test ) http://en.wikipedia.org/wiki/Fisher%27s_exact_test ( Fisher's exact test ) http://en.wikipedia.org/wiki/Chi-square_test ( Chi-square test ) http://en.wikipedia.org/wiki/Pearson%27s_chi-square_test ( Pearson's chi-square test ) If the difference ( the contingency coefficient ) is significant , one compiler is best ( small number of failures ), the other is worst ( large number of failures ) . -- Assume there is no any failure , and execution times are available . ProgramCLang GCC --- 1 t t 2 t t . . . n t t where t is the execution time of the program . Apply paired t test . If the paired differences are significant , one compiler is best ( short execution time , small mean ) , the other is worst ( long execution time , large mean ) . - The above paired t test may be used for the generated program sizes . If the paired differences are significant , one compiler is best ( small program size , small mean ) , the other is worst ( large program size , large mean ) . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [ath] AR9285/AR2427 users - please test -HEAD
Al 14/03/11 01:46, En/na Adrian Chadd ha escrit: > Hi all, > > I've been working on AR9285 and AR2427 specific fixes. I seem to have > fixed the issues I've seen with my AR9285 and AR2427 (and my AR2427 > actually performs better under FreeBSD than Linux. Hah!) > > Just to be clear - the AR2427 support now seems to work and be stable. > I'm seeing 24mbit in iperf TCP tests in both TX and RX test. > > Would people please give -head a test and report back to the list(s) ? > Will this also support AR9287 ? Regards and thanks for your work, Gustau ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT][patch]cfi driver support for NOR flash arrays
Hi Andrew, Marcel and list readers, On Tue, 15 Mar 2011 14:41:09 -0400 Andrew Duane wrote: > Marcel Moolenaar wrote: > > On Mar 14, 2011, at 8:09 AM, Aleksandr Rybalko wrote: > > > >> Hi, all. > >> > >> proposed patch add support of NOR flash arrays to cfi driver > >> http://my.ddteam.net/files/2011-03-11_cfi_flash_array_support.patch > > > > Hi Aleksandr, > > > > The patch is interesting, but combines a whole bunch of different > > changes. Some of the changes are similar to the fixes we have at > > Juniper ourselves, so getting the driver sync'd up is a good idea. > > Not to mention that we have added support for the SPI interface. > > > > Just a quick question: is an array different from 2 independent > > CFI devices on the same bus? I mean: can we support an array by > > having 2 driver instances? > > > > Thanks, > > Arrays can be horizontal or vertical. A vertical array is just two > chips, 0->X and X+1->YY. This would work with 2 driver > instances. > > Horizontal (interleaved) is two chips that share a single address > space and provide alternating bits/bytes/words. This would not work > with two instances. > > -- > > Andrew Duane Juniper Networks > 978-589-0551 10 Technology Park Dr > adu...@juniper.net Westford, MA 01886-3418 > Driver designed to handle "any" array configuration (limitation only 1,2,4,8 for interleaved), only one rule must be applied - flash chips must be same type, since driver don't handle different timing or sizes of other chips. So if for example we have: chip 1 at 0x1f00 size 4M - CS rise on A22=0 and A23=0 chip 2 at 0x1f40 size 4M - CS rise on A22=1 and A23=0 chip 3 at 0x1f80 size 4M - CS rise on A22=0 and A23=1 as result we get 12M array. If Marcel question in "can driver support more than one flash chip" - answer yes, that why I wrote this patch. But if you need join two devices located not back-to-back on bus - answer is no. For that case I think best choice strip down one of geom RAID modules like geom_strip or geom_concat. Maybe I misunderstand something, sorry for my English then. :) -- Aleksandr Rybalko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
I want to put together a new server with 9.0 that I will use as a prototype
I want to put together a new server with 9.0 that I will use as a prototype for hardware and OS updating. By the time I finish I'm sure 9 will be out;) I will use them to replace my 7.4 servers. The only doubt that I have relates to disks. I would like to use GPT and ZFS for the disks and have never used either but my real concern is ZFS and problems that I could have due to my ignorance in choosing the correct configuration for installing and then maintaining once in production. I like to think that I am not a total idiot and should be able to. I am also concerned with ZFS life expectancy (oracle). I'm assuming the GPT will be around for a while and don't see it as a problem. I would appreciate any support as to any errors my logic and which ZFS setup is the most practical, up-time and maintenance wise. If there is something better that I've missed, I would love to here it. ZFS is my "raid" solution and I find it cool. Thanks for any and all suggestions, slaps on the wrist, etc, etc. ed ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: [CFT][patch]cfi driver support for NOR flash arrays
Marcel Moolenaar wrote: > On Mar 14, 2011, at 8:09 AM, Aleksandr Rybalko wrote: > >> Hi, all. >> >> proposed patch add support of NOR flash arrays to cfi driver >> http://my.ddteam.net/files/2011-03-11_cfi_flash_array_support.patch > > Hi Aleksandr, > > The patch is interesting, but combines a whole bunch of different > changes. Some of the changes are similar to the fixes we have at > Juniper ourselves, so getting the driver sync'd up is a good idea. > Not to mention that we have added support for the SPI interface. > > Just a quick question: is an array different from 2 independent > CFI devices on the same bus? I mean: can we support an array by > having 2 driver instances? > > Thanks, Arrays can be horizontal or vertical. A vertical array is just two chips, 0->X and X+1->YY. This would work with 2 driver instances. Horizontal (interleaved) is two chips that share a single address space and provide alternating bits/bytes/words. This would not work with two instances. -- Andrew Duane Juniper Networks 978-589-0551 10 Technology Park Dr adu...@juniper.net Westford, MA 01886-3418 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT][patch]cfi driver support for NOR flash arrays
On Mar 14, 2011, at 8:09 AM, Aleksandr Rybalko wrote: > Hi, all. > > proposed patch add support of NOR flash arrays to cfi driver > http://my.ddteam.net/files/2011-03-11_cfi_flash_array_support.patch Hi Aleksandr, The patch is interesting, but combines a whole bunch of different changes. Some of the changes are similar to the fixes we have at Juniper ourselves, so getting the driver sync'd up is a good idea. Not to mention that we have added support for the SPI interface. Just a quick question: is an array different from 2 independent CFI devices on the same bus? I mean: can we support an array by having 2 driver instances? Thanks, -- Marcel Moolenaar xcl...@mac.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: sysinstall is no longer the default installer
On Mar 14, 2011, at 7:13 AM, Nathan Whitehorn wrote: > I just committed (r219641) changes that make the release infrastructure > (src/release/Makefile) use bsdinstall by default instead of sysinstall on > install media. A big thank you is in order to everyone who provided advice, > criticism, and testing for this project over the last few months! Thanks Nathan, I checked ia64 and it works well enough. I may come back with a tweak here and there after the dust settles, but so far it's more reliable (and a while lot simpler) than sysinstall is. Great work! -- Marcel Moolenaar xcl...@mac.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: sysinstall is no longer the default installer
On Mon, Mar 14, 2011 at 5:38 PM, Nathan Whitehorn wrote: > On 03/14/11 10:38, Giorgos Keramidas wrote: >> Naturally, I volunteer to *make* the mdoc changes. As long as someone >> (e.g. you Nathan?) who is acquainted with the new release building >> Makefile can hepl me by reviewing the updates and making sure they look >> reasonably close to the new state of everything. > > Sure. I have the feeling that there are going to be a lot of feature and > change requests today with regard to release infrastructure, so I'll let the > dust clear for a day or two and we can start hashing out the documentation. Sounds like a plan to me. Thanks :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
