Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Bacterius

Member Since 28 Feb 2011
Offline Last Active Today, 07:55 AM

Topics I've Started

AntTweakBar for C#

22 October 2013 - 03:04 AM

Hello, does anyone know of, or has anyone written a - free - wrapper for the AntTweakBar GUI library for C#? Just asking before I start writing my own, can't find one on the internet at all (which is surprising, I'd imagine someone somewhere would have already created one). The API looks straightforward enough to port, but I'd really hate to reinvent the wheel.

 

Thanks!


Reputation bug?

26 July 2013 - 08:36 PM

Aren't new members supposed to start at 101 points? This recent member (and possibly others) appears to have started at 1 reputation point (making his reputation appear as "bad" despite the fact that he was never downvoted). Perhaps this should be addressed (and see if there is an underlying bug at work)?

 

I just noticed it so heads-up to the staff smile.png


Memory allocation for low-level library

04 July 2013 - 08:58 AM

Hello,

I have a rather low-level C library I'm working hard on, and I've finally gotten to overhauling the memory manager. For now I've been using malloc/free as usual, but because many of my structures are nested and recursively allocated, this leads to a lot of cache misses as all my stuff is scattered all over the address space, subject to the host application's memory patterns. Furthermore, I also need additional features (virtual page locking, notably) which requires an additional kernel call per virtual allocation, and tends to interfere with the host application (page straddling, that kind of thing).

 

I've been looking over various memory allocation techniques, trying to find one that would best fit my library's needs. What I've established is that by design, blocks allocated by my library are either very short-lived, or very long-lived, and are allocated/deallocated in a roughly stack-like fashion. Furthermore, those blocks are typically small (there are many "small" structures of 16-32 bytes, and some "medium" structures around 64-512 bytes, and definitely no massive blocks). Finally, applications using the library are unlikely to accumulate many memory blocks at once, they will instead allocate a few, deallocate them, allocate them again, and so on (or just reuse them directly). There is also no reallocation going on: the library knows how much it needs and never has to resize any blocks it allocates. I've also worked extremely hard to ensure the library functions are using constant memory with respect to user input, so no worries there, all allocations are controlled with well-defined size limits.

 

Finally, I'd like to allow the option of users providing their own custom allocator if they so desire, so my default, optimally tuned allocator would need to follow a proper interface (likely simply a memory allocation function (unaligned and aligned flavours) and a deallocation function). That's probably not too hard, though.

 

I've reduced my choices to two allocation strategies:

1. static/dynamic memory pool allocation hybrid.

2. region-based allocation.

 

The first choice would involve first using a static, small, high-performance pool to store requested blocks, and falling back to a generic dynamic pool strategy whenever the library runs out of space. This option is very attractive to me, because most applications would only ever use the static pool, leading to optimum cache coherency, pretty low overhead, and it also lets the library do all the setup work at the start and never worry about it after. The few more demanding applications won't keel over, either, but will simply revert to the less efficient dynamic pool allocator.

 

The second option is nice as it would fit the memory usage pattern of the library better, but I think region-based allocators need additional information like distinguishing allocating a region and allocating a block inside a given region (imposing additional work on the library's implementation and making it hard to interop with other allocators) and it wouldn't work too well with any "deep copy" functions which can potentially increase the size of a region by modifying the size of a nested structure, since they hold pointers to more structures, not the structures themselves. Overall it sounds like a logistical nightmare.

 

So I am leaning towards the first option, but I am not sure if this "cache-based" allocation strategy has been done before and if it is really beneficial. Of course I don't want something ridiculously complicated either, which is why I'd prefer a simple, "all in one" solution. I really just want something elegant, efficient, and tailored to my library, not a general-purpose malloc-style infrastructure.

 

You may assume the target processors for this allocator are generic consumer-grade CPU's. The library will also have embedded hardware support but obviously that will have a different codepath).

 

What do you guys think?

 

Thanks smile.png


Name of a particular property

22 June 2013 - 04:01 AM

Hello,

in my library I'm working on, I have a few functions which take (among other parameters) a data buffer, with the property that calling such a function twice in succession, with two data buffers, is equivalent to calling it once with the ordered concatenation of both data buffers. In other words:

F("hello")
F(" ")
F("world")

Is strictly equivalent to:

F("hello world")

Is there a name for such a property? For instance a function such that F(F(x)) = F(x) is called idempotent. I'm asking because I'm tired of describing this property in such a long-winded manner in my documentation, and it would be nice if there was a word I could use to sum it all up efficiently.

 

Thanks!


Malware alert!

20 March 2013 - 11:27 PM

I'm getting this cute malware alert in chromium when I hit the website when it's down. I'm guessing it's the pacman flash game.

 

121u0wg.jpg

 

Does anyone else get that?


PARTNERS