Philip Herron wrote: > whoops forgot to reply to all :) > > Hey > > Thats pretty cool are you compiling all of them under gcc? Or > different compilers also! I am looking to try and benchmark gcc vs sun > compilers (compiling drizzle :) ) on linux and on solaris. maby use > qemu to emulate sparc to see how it works too would be nice too :). >
One solaris we're only compiling with Sun Studio, as GCC on Solaris is too old to compile drizzle. (Oldest GCC we support - which is itself too old, but it's all OSX ships and everyone things OSX is "cool" - is 4.0.2) I was going to put in support for compiling with Intel's compiler, but I gave up when the Intel compiler only came in RPM packages. (and the "general linux" installer was a shell script with embedded RPMs that it failed to install on my Ubuntu box... Mike, you wanna kick someone for me?) I also wanted to try compiling drizzle with Sun Studio on linux (it exists, why not?) but there are massive header file problems. Sun Studio finds the GCC header files which contain constructs it doesn't support, so it either spits gobs of warnings or just plain fails. So thus far, an apples to apples compiler comparison has turned out to be particularly difficult... welcome to the battle, however! I do take patches... Monty > >> 2009/3/6 Monty Taylor <[email protected]>: >>> Stewart Smith wrote: >>>> I've been looking into various issues that show up in non-intel >>>> architectures (i.e. SPARC and PowerPC). >>>> >>>> I've been using these platforms: >>>> - Linux/Sparc (Debian) >>>> - Linux/PowerPC (Debian) >>>> - Solaris/Sparc (Solaris 10) >>>> >>>> SPARC 32 and 64 bit may be different in some cases... so that's fun too.. >>>> >>>> A large number of issues are common across all three. (and PowerPC is >>>> really useful due to having a Valgrind port). >>>> >>>> There is a bug in sorting that i'm tracking down that seems to be >>>> responsible for a lot of test failures (so close there). >>>> >>>> Some more alignment issues on SPARC (due to memory alloc calls that >>>> allocate multiple things at once, and the non-first one ends up being >>>> incorrectly aligned and you end up with SIGBUS). Some systems will trap >>>> SIGBUS and just give you slow memory access instead. >>> <troll> >>> But Stewart - allocating multiple things at a time is better! >>> </troll> >>> >>>> The whole getopt/variables thing is so fundamentally broken when it >>>> comes to type safety (subtly break at runtime, not even warn during >>>> build) that I want to rewrite hunks of it so that these bugs (like >>>> assuming size_t is the same as uint64_t which is the same as ulong) are >>>> build errors, not runtime breakage. >>> ++ >>> >>> Sync with me before you do - this has been a todo item for me for a >>> while, and I've got a tree somewhere with an idea sketched out on how to >>> make this work sensibly. >>> >>>> Time estimate: maybe another week or two to get all combinations of the >>>> above up to the same level as 32/64bit intel). (it largely depends on >>>> difficulty of some things hit). >>> Whee! >>> >>> /me looks forward to less pain >>> >>> Monty >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~drizzle-discuss >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~drizzle-discuss >>> More help : https://help.launchpad.net/ListHelp >>> > _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
