[core] Add a util for size literals

[dentiny]

As titled, I think having MB explicitly called out is more readable than 1024 * 1024 or 1<<20
Intended use case: #48262 (comment)

[rynewang]

LGTM, but can we make at least one usage in code base to avoid dead code and to showcase? src/ray/stats/metric_defs.cc can be a good start.

[rynewang]

why do we use long long instead of size_t

[dentiny]

I don't see much difference?

• unsigned long long is the largest unsigned range we could have in C++ natively
• we won't have negative value here

[rynewang]

ofc they are the same: size_t is just typedef of unsigned long long on 64bit system. However it has a clearer semantics: it represents a size, which is what all these "number of bytes" about.

[dentiny]

No strong preference, updated.

[dentiny]

OK, I found size_t doesn't compile

./src/ray/util/size_literals.h:22:18: error: 'constexpr size_t operator""_B(size_t)' has invalid argument list
   22 | constexpr size_t operator""_B(size_t sz) { return sz; }
      |                  ^~~~~~~~

Working version:

constexpr unsigned long long operator""_B(unsigned long long sz) { return sz; }

Non-workable version:

constexpr size_t operator""_B(size_t sz) { return sz; }

[rynewang]

wrap everything in namespace ray::literals so users must opt-in with using

[dentiny]

I don't think putting these function into a namespace is a good idea.
For example, gflag requires all flag values to placed in outmost namespace.
A typical use case is:

DEFINE_int64(some_flag_name, 15_MiB, "some flag description");

[rynewang]

Also since we are here - is it possible to define a class ByteSize { size_t bytes_; static operator""_KiB(...){...} } so we can be more type rich? Just discussion - did not research on how big this is.

[rynewang]

[nit] I'd prefer ordering as B, KB, MB,...., KiB, MiB, ....

[dentiny]

LGTM, but can we make at least one usage in code base to avoid dead code and to showcase? src/ray/stats/metric_defs.cc can be a good start.

Sure, updated one place for metrics defs.

[rynewang]

[nit] why not:

constexpr size_t operator""_PiB(long double sz) {
const long double res = sz * 1_PiB;
return static_cast<size_t>(res);
}

[rynewang]

and these double-to-size_t code are so duplicated, I wonder if we can make it a macro.

// Macro to generate (long double -> size_t) literal from (size_t -> size_t)
#define CREATE_FLOAT_SIZE_LITERAL(suffix) \
  constexpr size_t operator""_##suffix(long double sz) { \
    return static_cast<size_t>(sz * 1_##suffix); \
  }

// Using the macro to define long double -> size_t literals
CREATE_FLOAT_SIZE_LITERAL(KiB)
CREATE_FLOAT_SIZE_LITERAL(MiB)
CREATE_FLOAT_SIZE_LITERAL(GiB)
CREATE_FLOAT_SIZE_LITERAL(TiB)
CREATE_FLOAT_SIZE_LITERAL(PiB)

[dentiny]

[nit] why not:
constexpr size_t operator""_PiB(long double sz) {
const long double res = sz * 1_PiB;
return static_cast<size_t>(res);
}

Updated.

[dentiny]

I'm not a fan of macros.

Using macro is generally not recommended (effective C++ item-1 has a few good arguments):

• Hard to debug, easier to get wrong;
• Purely textual replacement, no compiler check (i.e. what if repeated macro definition);
• Affective, especially in header file.

I almost only use macros at error propagation (i.e. ray/util/logging.h) to save some boilerplate code for unhappy path.
For here, both implementations are just one-liner, don't see much benefit.

[dentiny]

Also since we are here - is it possible to define a class ByteSize { size_t bytes_; static operator""_KiB(...){...} } so we can be more type rich? Just discussion - did not research on how big this is.

Emm could you please give me some examples you think it's better to have such class?
Usually, from my limited experience, size literal seems to be enough.