Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[-fomg-optimized] Has anyone tried out x32 yet?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Off the Wall
View previous topic :: View next topic  
Author Message
Mardok45
n00b
n00b


Joined: 21 Jun 2008
Posts: 63
Location: Right behind you

PostPosted: Wed Dec 12, 2012 1:12 am    Post subject: [-fomg-optimized] Has anyone tried out x32 yet? Reply with quote

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
View user's profile Send private message
Amaranatha
n00b
n00b


Joined: 30 Nov 2004
Posts: 48
Location: Spain, Europe

PostPosted: Wed Dec 12, 2012 9:57 am    Post subject: Reply with quote

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
View user's profile Send private message
energyman76b
Advocate
Advocate


Joined: 26 Mar 2003
Posts: 2026
Location: Germany

PostPosted: Wed Dec 12, 2012 7:46 pm    Post subject: Reply with quote

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
View user's profile Send private message
Prenj
n00b
n00b


Joined: 20 Nov 2011
Posts: 13

PostPosted: Wed Dec 12, 2012 7:56 pm    Post subject: Reply with quote

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
View user's profile Send private message
genstorm
Advocate
Advocate


Joined: 05 Apr 2007
Posts: 2463
Location: Austria

PostPosted: Wed Dec 12, 2012 8:03 pm    Post subject: Reply with quote

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
View user's profile Send private message
Amaranatha
n00b
n00b


Joined: 30 Nov 2004
Posts: 48
Location: Spain, Europe

PostPosted: Wed Dec 12, 2012 10:11 pm    Post subject: Reply with quote

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
View user's profile Send private message
energyman76b
Advocate
Advocate


Joined: 26 Mar 2003
Posts: 2026
Location: Germany

PostPosted: Wed Dec 12, 2012 10:19 pm    Post subject: Reply with quote

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
View user's profile Send private message
Prenj
n00b
n00b


Joined: 20 Nov 2011
Posts: 13

PostPosted: Wed Dec 12, 2012 10:40 pm    Post subject: Reply with quote

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
View user's profile Send private message
Amaranatha
n00b
n00b


Joined: 30 Nov 2004
Posts: 48
Location: Spain, Europe

PostPosted: Wed Dec 12, 2012 11:21 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Off the Wall All times are GMT
Page 1 of 1

 
Jump to:  
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