Cudf: [FEA] Improve readability of thread id based branching

Created on 15 Sep 2020  路  5Comments  路  Source: rapidsai/cudf

Improve readability of thread id based branches by giving them more descriptive names.

e.g.

if (!t) // is actually a t == 0

and

https://github.com/rapidsai/cudf/blob/57ef76927373d7260b6a0eda781e59a4c563d36e/cpp/src/io/statistics/column_stats.cu#L285
Is actually a lane_id == 0
As demonstrated in https://github.com/rapidsai/cudf/issues/6241#issuecomment-693125331, prefer cooperative groups for this.

and

https://github.com/rapidsai/cudf/blob/85cd56dfb3449140f18c7cef3a3be01ac976fd14/cpp/src/io/parquet/page_enc.cu#L1256
is actually ~t < 32~ lane_id == 31. (~I think this might be an oversight,~ ignore as it might be fixed in #6238 ).

cuIO feature request good first issue tech debt

Most helpful comment

Also, isn't !(t & 0x1f) actually t % 32 == 0, not t == 0 ?
Edit: confirmed for modulo. Also confirmed that the compiler generates the same code.

https://godbolt.org/z/a9ercr

Note that using CG also generates the same code, but it actually gives you access to the special laneid register.

All 5 comments

Nope: last one is if (lane_id == 31), for those that prefer the "lane id" terminology.

Nope: last one is if (lane_id == 31), for those that prefer the "lane id" terminology.

Thanks. Thus demonstrated that it wasn't so readable for me 馃槅

Also, isn't !(t & 0x1f) actually t % 32 == 0, not t == 0 ?
Edit: confirmed for modulo. Also confirmed that the compiler generates the same code.

Also, isn't !(t & 0x1f) actually t % 32 == 0, not t == 0 ?
Edit: confirmed for modulo. Also confirmed that the compiler generates the same code.

https://godbolt.org/z/a9ercr

Note that using CG also generates the same code, but it actually gives you access to the special laneid register.

Also, isn't !(t & 0x1f) actually t % 32 == 0, not t == 0 ?

That's what I wrote. lane_id == 0

Was this page helpful?
0 / 5 - 0 ratings