| View previous topic :: View next topic |
| Author |
Message |
Mardok45
n00b
Joined: 21 Jun 2008
Posts: 59
Location: Right behind you
|
 Posted: Wed Dec 12, 2012 1:12 am Post subject: [-fomg-optimized] Has anyone tried out x32 yet? |
 |
|
I've upgraded my desktop and decided to give x32 a try for shits and giggles. I wasn't expecting anything to work, but was surprised that, at the very least, I was able to successfully upgrade the base system and was functioning properly. Installing Xen was a different story.
Right off the bat, the first dependency, dev-lang/ocaml failed with some error in the assembly. I thought about unmasking GCC and binutils, but didn't fancy that idea. So I mkfs.ext4'd the root and did a regular amd64 install. I'll give it another shot some other time.
What's been everyone else's experience so far? |
|
| Back to top |
|
 |
Amaranatha
n00b
Joined: 30 Nov 2004
Posts: 48
Location: Spain, Europe
|
| Posted: Wed Dec 12, 2012 9:57 am Post subject: |
|
|
I haven't tried it and am not familiar with this particular implementation, but experimented with the idea a few years ago.
In my (limited) experience, it's OK but nothing revolutionary. At most, you can halve the memory usage, and that only for programs with a massive pointer overhead -- which should trigger your code smell alarms, btw. Dynamic Libraries have to be 64 bits or must be replicated, which IMHO is not worth the effort.
Proper use of embedded libraries (such as musl), static linking, and refactoring your code to use denser data structures (intrusive lists*, external packed lists, B-trees, closed hash tables, and most importantly, plain old arrays) lead to greater benefits in most cases.
* Denser once you account for malloc's overhead.
_________________
"Freedom incurs responsibility; that is why so many men fear it." - George Bernard Shaw |
|
| Back to top |
|
|
energyman76b
Advocate
Joined: 26 Mar 2003
Posts: 2022
Location: Germany
|
| Posted: Wed Dec 12, 2012 7:46 pm Post subject: |
|
|
it was 'invented' by intel because Atom's suck with true 64bit... and since I don't own intel crap I haven't tried it nor do I want to try it.
_________________
| AidanJT wrote: |
Libertardian denial of reality is wholly unimpressive and unconvincing, and simply serves to demonstrate what a bunch of delusional fools they all are.
|
Satan's got perfectly toned abs and rocks a c-cup. |
|
| Back to top |
|
|
Prenj
n00b
Joined: 20 Nov 2011
Posts: 7
Location: Mostar, BiH
|
| Posted: Wed Dec 12, 2012 7:56 pm Post subject: |
|
|
| Amaranatha wrote: | Proper use of embedded libraries (such as musl), static linking, and refactoring your code to use denser data structures (intrusive lists*, external packed lists, B-trees, closed hash tables, and most importantly, plain old arrays) lead to greater benefits in most cases.
* Denser once you account for malloc's overhead. |
Meh, just use glib for strings, containers and memory allocation. It has its own memory pool management. |
|
| Back to top |
|
|
genstorm
Advocate
Joined: 05 Apr 2007
Posts: 2251
Location: Austria
|
| Posted: Wed Dec 12, 2012 8:03 pm Post subject: |
|
|
Doesn't really make sense speed-wise.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic |
|
| Back to top |
|
|
Amaranatha
n00b
Joined: 30 Nov 2004
Posts: 48
Location: Spain, Europe
|
| Posted: Wed Dec 12, 2012 10:11 pm Post subject: |
|
|
| Prenj wrote: | | Meh, just use glib for strings, containers and memory allocation. It has its own memory pool management. |
External data structures (i.e. containers) are adequate for some solutions, and are indeed more powerful from a theoretical perspective, but they usually associate with suboptimal cache performance and ill-defined memory management semantics. A good use of intrusive data structures can improve performance, simplify code, and reduce bugs. The kernel list is a very good example of this.
Regarding memory management, a proper user of regions, for example, can introduce a notable reduction in costs and latency. I'm not familiar with glib's memory management techniques, but I can assure you that GNU libc malloc() is quite wasteful. Any allocation will take 8 or 16 bytes just in metadata. With an external data structure, this translates to an overhead of 32 bytes (16 per node + 16 per item) per element in the collection. That's huge.
_________________
"Freedom incurs responsibility; that is why so many men fear it." - George Bernard Shaw |
|
| Back to top |
|
|
energyman76b
Advocate
Joined: 26 Mar 2003
Posts: 2022
Location: Germany
|
| Posted: Wed Dec 12, 2012 10:19 pm Post subject: |
|
|
https://blog.flameeyes.eu/tag/x32
_________________
| AidanJT wrote: |
Libertardian denial of reality is wholly unimpressive and unconvincing, and simply serves to demonstrate what a bunch of delusional fools they all are.
|
Satan's got perfectly toned abs and rocks a c-cup. |
|
| Back to top |
|
|
Prenj
n00b
Joined: 20 Nov 2011
Posts: 7
Location: Mostar, BiH
|
| Posted: Wed Dec 12, 2012 10:40 pm Post subject: |
|
|
| Amaranatha wrote: | | I'm not familiar with glib's memory management techniques, but I can assure you that GNU libc malloc() is quite wasteful. Any allocation will take 8 or 16 bytes just in metadata. With an external data structure, this translates to an overhead of 32 bytes (16 per node + 16 per item) per element in the collection. That's huge. |
Yeah, it really is, we had issues with it, which is among the reasons we chose Glib. It originally started with me being lazy and not having energy to write some collections from scratch, so I used linked lists and binary trees from different libraries and benchmarked results for comparison, and Glib came out on top.
Then I started reading about it, and got hooked.
To not dig too deeply into how glib does memory pools, it can be simplified as following: all allocations you do are not done by (c)malloc's, instead you use glib's g_new(). Strings are allocated with g_string_new(), queues with g_queue_new() and so on. All of them get their memory from already allocated memory pool, which not only reduces metadata overhead, but since the real allocation is in fixed size blocks, behind the scenes, "allocation" in your code is not fragmented, and execution time is constant. |
|
| Back to top |
|
|
Amaranatha
n00b
Joined: 30 Nov 2004
Posts: 48
Location: Spain, Europe
|
| Posted: Wed Dec 12, 2012 11:21 pm Post subject: |
|
|
| Prenj wrote: | | All of them get their memory from already allocated memory pool, which not only reduces metadata overhead, but since the real allocation is in fixed size blocks, behind the scenes, "allocation" in your code is not fragmented, and execution time is constant. |
This is generally a very good strategy. We use it in our hodgepodge library, with some variations. 
_________________
"Freedom incurs responsibility; that is why so many men fear it." - George Bernard Shaw |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Off the Wall
