RE: [AD] malloc() vs align_malloc() |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: <alleg-developers@xxxxxxxxxx>
- Subject: RE: [AD] malloc() vs align_malloc()
- From: "Robert Ohannessian" <ROhannessian@xxxxxxxxxx>
- Date: Mon, 21 Feb 2005 12:23:13 -0800
- Thread-index: AcUX2Fqh5jB8lhdjTYypvsEF+PZvVQAeqVUQ
- Thread-topic: [AD] malloc() vs align_malloc()
> -----Original Message-----
> From: alleg-developers-admin@xxxxxxxxxx [mailto:alleg-
> developers-admin@xxxxxxxxxx] On Behalf Of AJ
> Sent: Sunday, February 20, 2005 9:44 PM
> To: alleg-developers@xxxxxxxxxx
> Subject: Re: [AD] malloc() vs align_malloc()
>
> > Note that for bitmaps, you'll want to align the line member. You
> > shouldn't care about alignment of the dat member, really.
>
> so if i was to ensure the dat was large enough, then set all the line
> ptrs to aligned addresses, the rest of allegro should work just fine ?
> or do some functions use dat[y*pitch+w] arithmetic?
It should, in theory. I don't think anything in Allegro depends on
dat[], but one can never be too sure. You can just try it and see if you
find corruption in some of the tests.
>
>
>
>
> > In fact, aligned_malloc isn't all that useful to Allegro.
>
>
> it will be, it will be.
Nah. You'll need to manually align the line[] pointers anyway, so
align_malloc() isn't doing anything more for you.
>
>
>
> >>-----Original Message-----
> >>From: alleg-developers-admin@xxxxxxxxxx [mailto:alleg-
> >>developers-admin@xxxxxxxxxx] On Behalf Of AJ
> >>Sent: Saturday, February 19, 2005 11:57 PM
> >>To: alleg-developers@xxxxxxxxxx
> >>Subject: Re: [AD] malloc() vs align_malloc()
> >>
> >>further research for this topic:
> >>
> >>these funcs also exist for msvc7
> >>
> >>_aligned_free()
> >>_aligned_malloc()
> >>_aligned_realloc()
> >>
> >>so i guess we need to match eahc aligned_malloc() with an
> >
> > aligned_free()
> >
> >>
> >>my mingw (gcc 3.4.2) has this:
> >>
> >>
> >>/* These require msvcr70.dll or higher. */
> >>#if __MSVCRT_VERSION__ >= 0x0700
> >>_CRTIMP void * __cdecl _aligned_offset_malloc(size_t, size_t,
size_t);
> >>_CRTIMP void * __cdecl _aligned_offset_realloc(void*, size_t,
size_t,
> >>size_t);
> >>
> >>_CRTIMP void * __cdecl _aligned_malloc (size_t, size_t);
> >>_CRTIMP void * __cdecl _aligned_realloc (void*, size_t, size_t);
> >>_CRTIMP void __cdecl _aligned_free (void*);
> >>#endif /* __MSVCRT_VERSION__ >= 0x0700 */
> >>
> >>
> >>which means it can only be defined for systems that are using the
> >
> > msvc7
> >
> >>runtime. not sure if this is a requirement for MSVC6 as the MSDN
> >>documentaion claims its for systems back to win98.
> >>
> >>this makes if a bit more difficult to implement cleanly, however if
it
> >>potentially can improve things like draw_sprite and masked_blit() by
> >
> > as
> >
> >>much as 50% its worth doing.
> >>
> >>
> >>
> >>
> >>
> >>AJ wrote:
> >>
> >>>before i go to the trouble of patching allegro i would like to hear
> >
> > of
> >
> >>>any arguments against using align_malloc() instead of malloc()
> >>>
> >>>SSE/SSE2 instructions require aligned data for performance reasons.
> >>>
> >>>i'd like to see at minimum all bitmap->dat* mallocs be aligned to
> >
> > 16
> >
> >>>byte boundaries (SSE requirement).
> >>>
> >>>on Windows, its called _aligned_malloc
> >>>details here:
> >>>http://msdn.microsoft.com/library/default.asp?url=/library/en-
> >>
> >>us/vclib/html/vclrf_aligned_malloc.asp
> >>
> >>>
> >>>a quick look through allegro, i found many instances were an
aligned
> >>>malloc *may* improve performace, many of these would not have any
> >
> > side
> >
> >>>effects as they are internally viewable vars, and would not break
> >
> > user
> >
> >>>viewable structs etc.
> >>>
> >>>anyone from linux land able to offer the linux view or this
> >
> > proposal?
> >
> >>>aj
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers