[macstl-dev] Opinions wanted about the future directions of macstl

Paul Baxter pauljbaxter at hotmail.com
Wed Feb 16 02:51:01 WST 2005

  • Previous message: [macstl-dev] Opinions wanted about the future directions of macstl
  • Next message: [macstl-dev] linker error on VC7
  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]


> Now that macstl 0.2.1 has reached some measure of stability and we now 
> have a good community of you macstl users in this mailing list, it's time 
> I gathered some feedback about our future direction.
>
> Please rank the top 5 or so things you'd like to see in macstl, discuss 
> it, and I'll see what I can do, time, energy and money permitting :-).
>
Comments attached - heavy PC/Linux bias

See *N where N = priority (1 highest)

> Documentation
> 1. Design of the trig functions.
> 2. Design of the integer division functions.
> 3. How to adapt macstl for your favorite SIMD architecture.
*5 > 4. More examples and samples (suggest?)
Added:
*6 4b) Architecture optimisation guide
     - how to get the best out of macstl on different 
compilers/OS/processors .g. compile flags, tips
>
> Altivec
> 5. The rest of the transcendentals e.g. acos, sinh.
> 6. The complex transcendentals.
> 7. Any other mathematical or other vector-related functions (suggest?)
> 8. long long support -- doubtful whether Altivec will accelerate this 
> much...
> 9. Optimizing mask arrays -- using a bool array to select elements from 
> another array
>
> MMX/SSE/SSE2/SSE3
> 10. Summarizers e.g. min, max, sum.
> 11. operator*, operator/, operator%
*3 > 12. float transcendentals.
> 13. double transcendentals.
*1 > 14. complex float arithmetic.
> 15. complex float transcendentals.
*2 > 16. complex double arithmetic.
> 17. complex double transcendentals.
> 18. memory mapping in Windows
Or in Linux ;) Mem alignment, alternate allocators e.g. 
boost::aligned_storage

Added:
*4 18b) Code optimisation
Biased here but optimisations for Athlon64, P4 (and maybe others)
e.g. Athlon XP (all I have at home) performance in some benchmarks is double 
the P4 (first two functions in benchmark.cpp) and in others horribly slower 
(e.g. polynomial). Can't help feeling there's a lot more still to be done to 
improve the processing optimisation on PC architectures.

>
> General SIMD
> 19. Support for OpenMP parallelizing.

> 20. Distributed valarrays, perhaps through MPI?
Wouldn't you use VSIPL++ if you wanted this?

> 21. Support for your favorite SIMD architecture, perhaps a GPU?
Wanna work with a CELL, Glen ;)

>
> Other areas in macstl
> 22. Other Core Foundation objects e.g. maps, sets.
> 23. Objective-C++ support.
> 24. Improving the COM implementation.
> 25. Improving the Mach vector implementation. Perhaps also a Mach 
> std::string?

Added suggestions:




  • Previous message: [macstl-dev] Opinions wanted about the future directions of macstl
  • Next message: [macstl-dev] linker error on VC7
  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the macstl-dev mailing list