tag:blogger.com,1999:blog-5246987755651065286.post2270596852251547550..comments2024-02-22T16:15:42.388-08:00Comments on cbloom rants: 02-25-09 - Low Level Threading - Part 4.3cbloomhttp://www.blogger.com/profile/10714564834899413045noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-5246987755651065286.post-32540554224515115532009-02-26T14:46:00.000-08:002009-02-26T14:46:00.000-08:00Not exactly. I've been trying stuff using align a...Not exactly. I've been trying stuff using align and it's a bit of a mess.<BR/><BR/>align(64) on the *typedef* would cause the type to get padded up to a multiple of 64 bytes. If that's acceptable to you then things are pretty easy.<BR/><BR/>align(64) on the instance will align its address to 64 but won't prevent other objects from being directly after you.<BR/><BR/>So, yes if you align both the type and the instance it will get its own cache line.<BR/><BR/>But there doesn't seem to be any way to mark at the instance that it should be aligned and that the *next* value should also be aligned so that I get the whole line.cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-91351358533395987642009-02-26T14:35:00.000-08:002009-02-26T14:35:00.000-08:00Well, I suppose for static/auto allocated stuff, y...Well, I suppose for static/auto allocated stuff, you could just use the "align" declspec/attribute?won3dhttps://www.blogger.com/profile/09787472194187459747noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-42630650905825075122009-02-26T13:59:00.000-08:002009-02-26T13:59:00.000-08:00Yeah I don't actually suggest that you have a "g_s...Yeah I don't actually suggest that you have a "g_stack" global at file scope. I just thought it would be simpler to pretend you were talking through a global variable rather than setting up a ThreadSystem Singleton or whatever.cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-61264744519673186172009-02-26T13:52:00.000-08:002009-02-26T13:52:00.000-08:00On recent versions of gcc/ld, you can try adding -...On recent versions of gcc/ld, you can try adding -fdata-sections to gcc and --gc-sections to ld and see if it strips the unreferenced data like it is supposed to.won3dhttps://www.blogger.com/profile/09787472194187459747noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-38755314335795801002009-02-26T11:12:00.000-08:002009-02-26T11:12:00.000-08:00"There is no guarantee that pad1, g_stack and pad2..."There is no guarantee that pad1, g_stack and pad2 are contiguous, right? You probably want to wrap that in a struct..."<BR/><BR/>I don't know if C actually says they are contiguous but in practice I believe they are 100% of the time.<BR/><BR/>But yeah I agree I wouldn't want to rely on that. (like for example I dunno if LTCG or some other weird linkages might screw this up)cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-65310636705417373212009-02-25T22:09:00.000-08:002009-02-25T22:09:00.000-08:00> int _pad1[CACHE_LINE_SIZE];> LFStack g_sta...> int _pad1[CACHE_LINE_SIZE];<BR/>> LFStack g_stack;<BR/>> int _pad2[CACHE_LINE_SIZE];<BR/><BR/>There is no guarantee that pad1, g_stack and pad2 are contiguous, right? You probably want to wrap that in a struct...Anonymousnoreply@blogger.com