Luabind on Sparc/Solaris

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Luabind on Sparc/Solaris

Tomas Puverle-2
Hey,

I originally put this in the bug tracker on sourceforge but I decided to
repost here:

This is a bug/experience report regarding
building/using Luabind on Solaris.

Here are system specs:
Main Memory is 96 GB
Number of CPUs (Physical) is 12
CPU Type is sparcv9+vis2
CPU Model is UltraSPARC-III+
Kernel Bit Size is 64
OS Name is SunOS
OS Version is 5.8

Using Sun Studio (SunCC) 8.1 and boost 1.32, building
a 64-bit lib and tests, luabind-0.7.

I am not sure whether you are interested in
supporting SunCC since the support for SunCC in boost
is not very good at the moment, even though SunCC 11
is getting much better and Sun are working hard on
making boost work with it.

The compile-time problems were divided into the
following:
- typos (e.g. in luabind/detail/get_signature.hpp,
a lot of the functions have a "};" at the end of
their definitions
- boost issues (mpl/for_each.hpp has a fix for MSVC
6 which breaks the SunCC build)
- SunCC problems (most of the time to do with its
inability to match/deduce arguments). For exaple, I
had to rewrite push_args_from_tuple<>.

Runtime issues: (unfortunately, the debugger is
getting really confused and the debug information
ends up unusable:( )
- SIGBUS (Address alignment) in test_policies.cpp:
pure_out_value_policy ends up deducing the wrong size
of argument. In the tests, it ends up constructing a
pure_out_value_converter<1,..> and calling
apply<float>. It is my guess that this may be an
issue on x86 too, but you just don't notice it
because x86 supports unaligned loads. I was able to
fix this and the test ran fine.

Other issues:
- Other alignment issues:
a) There are other places where you use char[]
arrays for storage. I would recommend using
boost::aligned_storage<> for that purpose.  Not only will this break
on arch that don't support unaligned loading, it will have negative
performance impact on those that do (e.g. x86)
b) in get_holder_alignment<null_type> prefer to
return boost::alignment_of<detail::null_type>::value
instead of 1
- Alignment and sizeof() should be size_t but int
is used in the code. Not a big deal but it makes me
wonder if there are any 64-bit issues.
- luabind/detail/typetraits.hpp: Would it be
perhaps better to fall back more on
Boost.TypeTraits? I have seen a few examples of
reimplementation of functionality that exists in
boost.

Best,

Tom



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user
Reply | Threaded
Open this post in threaded view
|

Re: Luabind on Sparc/Solaris

Arvid Norberg

On Mar 18, 2006, at 21:09, Tomas Puverle wrote:

> Hey,
>
> I originally put this in the bug tracker on sourceforge but I  
> decided to
> repost here:
>
> This is a bug/experience report regarding
> building/using Luabind on Solaris.
>
> Here are system specs:
> Main Memory is 96 GB
> Number of CPUs (Physical) is 12
> CPU Type is sparcv9+vis2
> CPU Model is UltraSPARC-III+
> Kernel Bit Size is 64
> OS Name is SunOS
> OS Version is 5.8
>
> Using Sun Studio (SunCC) 8.1 and boost 1.32, building
> a 64-bit lib and tests, luabind-0.7.
>
> I am not sure whether you are interested in
> supporting SunCC since the support for SunCC in boost
> is not very good at the moment, even though SunCC 11
> is getting much better and Sun are working hard on
> making boost work with it.
>
> The compile-time problems were divided into the
> following:
> - typos (e.g. in luabind/detail/get_signature.hpp,
> a lot of the functions have a "};" at the end of
> their definitions
> - boost issues (mpl/for_each.hpp has a fix for MSVC
> 6 which breaks the SunCC build)
> - SunCC problems (most of the time to do with its
> inability to match/deduce arguments). For exaple, I
> had to rewrite push_args_from_tuple<>.
>
> Runtime issues: (unfortunately, the debugger is
> getting really confused and the debug information
> ends up unusable:( )
> - SIGBUS (Address alignment) in test_policies.cpp:
> pure_out_value_policy ends up deducing the wrong size
> of argument. In the tests, it ends up constructing a
> pure_out_value_converter<1,..> and calling
> apply<float>. It is my guess that this may be an
> issue on x86 too, but you just don't notice it
> because x86 supports unaligned loads. I was able to
> fix this and the test ran fine.

We actually have done testruns on:
Sun Fire V440, Solaris 9.
Processor: 4x UltraSparc IIIi, 1600MHz
Memory: 16384MB

But we use GCC to build.

If you get SIGBUS, there may of course be a bug in luabind causing it.

(We've also run the tests on 64-bit PPC, which doesn't allow  
unaligned memory access either).


> Other issues:
> - Other alignment issues:
> a) There are other places where you use char[]
> arrays for storage. I would recommend using
> boost::aligned_storage<> for that purpose.  Not only will this break
> on arch that don't support unaligned loading, it will have negative
> performance impact on those that do (e.g. x86)
> b) in get_holder_alignment<null_type> prefer to
> return boost::alignment_of<detail::null_type>::value
> instead of 1
> - Alignment and sizeof() should be size_t but int
> is used in the code. Not a big deal but it makes me
> wonder if there are any 64-bit issues.

Of course you're right, we should use aligned_storage instead of  
plain char[]. We'll take a look at this.

When we allocate the userdata object to hold the object_rep and the  
holder type, we actually calculate the byte padding needed to put the  
holder type at an aligned address (class_rep.cpp ::allocate()). We  
also assume that lua_newuserdata() will return an aligned address  
(since that is a requirement of malloc()). So, I assume this is not a  
problem at least.

> - luabind/detail/typetraits.hpp: Would it be
> perhaps better to fall back more on
> Boost.TypeTraits? I have seen a few examples of
> reimplementation of functionality that exists in
> boost.
>
> Best,

Thank you very much for these suggestions!

--
Arvid Norberg




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
luabind-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/luabind-user