Main Area and Open Discussion > General Software Discussion

Computer blogs that you read?

<< < (2/4) > >>

Shades:
raymond.cc
techrepublic

More directed at professional users, but still interesting enough:
Petri It Knowledgebase
msexchange.org
datamotion

Ct Magazin (in German. They used to have also an English language version, but it seems you need Google translate or something similar or learn German.)

You ask us for many and give only two? Share the love mate... ;)  :D

msteph:
Shades, thanks for those, especially techrepublic and raymondcc. 

The two I mentioned - ghacks and Rick's - are literally the only quality blogs I've known about and Rick's only for the last couple of weeks.  I've read Ghacks for a long, long time. 

So you and MilesAhead have added to my bookmarks significantly.

 :)

Mike S.

mouser:
Here's one I've been reading lately, Daniel Lemire's blog: http://lemire.me/blog/

He had a recent post on the unpredictable and high memory usage of C++ STL containers, something I have long fretted about.

Jibz:
Thanks for the link, looks interesting :Thmbsup:.

I have to note though, that the memory usage of most STL containers can't be too surprising.

List is a doubly linked list, so each node will contain two 8 byte pointers (on 64-bit) as well as the value. Set is probably a binary search tree, so it will need at least left and right pointers. unordered_set might be a hash-table of some sort, which will need to not be full in order to be efficient.

If you change his custom allocator's constructor to print some information:


--- Code: C++ ---MemoryCountingAllocator() : base() {    std::cout << "+ Allocator for " << __PRETTY_FUNCTION__              << ", with size " << sizeof(T) << std::endl;}
You get something like:

Displaying memory usage in bytes.
Filling data structures with 1024 elements and reporting the per element memory usage.
+ Allocator for MemoryCountingAllocator<unsigned int>::MemoryCountingAllocator() [T = unsigned int], with size 4
memory usage per element of a vector<uint32_t> : 4
+ Allocator for MemoryCountingAllocator<std::_List_node<unsigned int> >::MemoryCountingAllocator() [T = std::_List_node<unsigned int>], with size 24
memory usage per element of a list<uint32_t> : 24
+ Allocator for MemoryCountingAllocator<unsigned int>::MemoryCountingAllocator() [T = unsigned int], with size 4
memory usage per element of a deque<uint32_t> : 4.64062
+ Allocator for MemoryCountingAllocator<std::__detail::_Hash_node<unsigned int, false> >::MemoryCountingAllocator() [T = std::__detail::_Hash_node<unsigned int, false>], with size 16
memory usage per element of an unordered_set<uint32_t> : 29.6016
+ Allocator for MemoryCountingAllocator<std::_Rb_tree_node<unsigned int> >::MemoryCountingAllocator() [T = std::_Rb_tree_node<unsigned int>], with size 40
memory usage per element of a set<uint32_t> : 40

--- End quote ---

Which shows that list, set, and unordered_set are allocating nodes for their respective implementations and not just uint32_t.

mouser:
I guess I had forgotten about the ability to create custom allocators to track memory usage -- thats definitely a nice feature of the STL.  Of course linked lists and queues are bound to be pretty space efficient... it's the has tables and trees with fast lookup that one might fear are memory hungry.

Navigation

[0] Message Index

[#] Next page

[*] Previous page