So I now have a working first-order language that uses conventional boxing to
handle polymorphism and with ints, floats and ('a -> 'a) functions.
After a huge amount of detailed benchmarking in OCaml and F# I have decided
that it is very important to be able to unbox complex numbers but no other
compound types. As LLVM provides a vector type for power-of-two
dimensionalities that compiles to efficient parallel code, I'd like to know
if I can store them unboxed in a way that is equivalent to my ints, floats
and function pointers, i.e. can I cast to and from them or must I add an
indirection via a pointer?
Also, do these vectors give significant performance improvements on x86-64
hardware or are they only good for x86+SSE and relatives?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
On Nov 29, 2007, at 16:06, Jon Harrop wrote:> So I now have a working first-order language that uses conventional > boxing to handle polymorphism and with ints, floats and ('a -> 'a) > functions.Cool.> After a huge amount of detailed benchmarking in OCaml and F# I have > decided that it is very important to be able to unbox complex > numbers but no other compound types. As LLVM provides a vector type > for power-of-two dimensionalities that compiles to efficient > parallel code, I'd like to know if I can store them unboxed in a way > that is equivalent to my ints, floats and function pointers, i.e. > can I cast to and from them or must I add an indirection via a > pointer?Bitcast simply depends on storage size. If two first-class types are of the same size, you can bitcast. If not, you can't. Pointers are the only exception; those require a combination bitcast/inttoptr or ptrtoint/bitcast to cover all possible conversions. On 32-bit platforms, these first-class types are bitcastable to one another: i32, float, any*, <2 x i16>, <4 x i8> On 64-bit platforms: i64, double, any*, <2 x float>, <2 x i32>, <4 x i16>, <8 x i8> So to utilize erasure-based polymorphism (as in Java or Ocaml), only single-precision floating-point complex numbers can be unboxed, and only on 64-bit hosts. If you're only interested in complex, would be to compile two copies of each polymorphic function, one for complex numbers, and the other for all other values. To more generally support unboxing, you'll need to look more towards .NET generics and C++ templates for guidance.> Also, do these vectors give significant performance improvements on > x86-64 hardware or are they only good for x86+SSE and relatives?Are there (m)any x64 processors without SSE? — Gordon
All x86-64 processors support SSE and SSE2 (most have SSE3 as well). On Nov 30, 2007 1:09 AM, Gordon Henriksen <gordonhenriksen at mac.com> wrote:> On Nov 29, 2007, at 16:06, Jon Harrop wrote: > > > So I now have a working first-order language that uses conventional > > boxing to handle polymorphism and with ints, floats and ('a -> 'a) > > functions. > > Cool. > > > After a huge amount of detailed benchmarking in OCaml and F# I have > > decided that it is very important to be able to unbox complex > > numbers but no other compound types. As LLVM provides a vector type > > for power-of-two dimensionalities that compiles to efficient > > parallel code, I'd like to know if I can store them unboxed in a way > > that is equivalent to my ints, floats and function pointers, i.e. > > can I cast to and from them or must I add an indirection via a > > pointer? > > Bitcast simply depends on storage size. If two first-class types are > of the same size, you can bitcast. If not, you can't. Pointers are the > only exception; those require a combination bitcast/inttoptr or > ptrtoint/bitcast to cover all possible conversions. > > On 32-bit platforms, these first-class types are bitcastable to one > another: > > i32, float, any*, <2 x i16>, <4 x i8> > > On 64-bit platforms: > > i64, double, any*, <2 x float>, <2 x i32>, <4 x i16>, <8 x i8> > > So to utilize erasure-based polymorphism (as in Java or Ocaml), only > single-precision floating-point complex numbers can be unboxed, and > only on 64-bit hosts. If you're only interested in complex, would be > to compile two copies of each polymorphic function, one for complex > numbers, and the other for all other values. To more generally support > unboxing, you'll need to look more towards .NET generics and C++ > templates for guidance. > > > Also, do these vectors give significant performance improvements on > > x86-64 hardware or are they only good for x86+SSE and relatives? > > > Are there (m)any x64 processors without SSE? > > — Gordon > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >