Improve cache_line alignment on x86_64

[Firstyear]

On x86_64 the cache_alignment is 64bytes. To accomodate dwcas, you need 128
bytes. The cache_line alignment therefore should be 18 * usize, which is 128
bytes wide. Other systems still default to 256 bytes (32 * 8).

[schets]

I think from the comment in the code you're confusing bits and bytes here. The x86 cache line is 64 bytes, not bits, and the alignment here is changed to 16 bytes. I'm not sure why it was ever 32 in the first place

[ghost]

This repository will soon be split into multiple crates (crossbeam-epoch, crossbeam-utils, crossbeam-deque, and so on).

The implementation of CachePadded now actually lives in crossbeam-utils (but will be re-exported in crossbeam as well). There's a PR that revamps CachePadded - could you please take a look at it instead?

[fitzgen]

The implementation of CachePadded now actually lives in crossbeam-utils (but will be re-exported in crossbeam as well). There's a PR that revamps CachePadded - could you please take a look at it instead?

Idea: This seems like something useful outside of just crossbeam, and its annoying to track down cache line sizes for different architectures, therefore it seems like CachePadded could be useful as a standalone crate.

[jeehoonkang]

@fitzgen There are two aspects to discuss on the nature of the crossbeam-utils crate: scope and name.

The idea of crossbeam-utils is providing utilities for concurrent programming in general, which isn't necessarily coupled with Crossbeam. I prefer not to split crossbeam-utils into smaller ones because it will add managerial costs.

In my opinion, the primary reason we named it crossbeam-utils is that the repository is maintained in the Crossbeam organization. While I prefer the current nomenclature, I understand that maybe someone wants to give a name that better reflects the nature of the crate, e.g. concurrency-base.

[Firstyear]

Hi,

The alignment is actually multiple of width, that's why the numbers look funny. It was odd to me too until I read the code and did some testing.

I don't think that splitting every crate into micro-crates is a good idea, because this makes it really hard for system packagers to use these things. Having one crate that handles this is a good thing because it's easier for a distro to distribute (and this is very imprortant to me as I want to use crossbeam in a major open source application). Were this crate split to many smaller crates it may become impractical for us to use this software :( Please keep this as one crate focused on lockfree/parallel datastructures,

Thanks!

[jeehoonkang]

For the same reason as in #168, I'd like to use crossbeam-utils instead.