rkyv / rend Goto Github PK

View Code? Open in Web Editor NEW

22.0 2.0 11.0 79 KB

Endian-aware primitives for Rust

License: MIT License

Rust 100.00%

rend's People

Contributors

Stargazers

Watchers

Forkers

tobz icodein silwol starkoracles pinkdiamond1 hulthe proffan lantern-chat alxandr novacrazy dotzklab

rend's Issues

rend: Test failed on s390x and armv7hl arch

Hi. Test failed on fedora koji. Latest version 0.3.1. The issue is the same on the two arch.
https://kojipkgs.fedoraproject.org//work/tasks/592/73360592/build.log
https://kojipkgs.fedoraproject.org//work/tasks/597/73360597/build.log

error[E0433]: failed to resolve: use of undeclared type AtomicU16_be
--> src/lib.rs:470:46
|
470 | mem::transmute::<, [u8; 2]>(AtomicU16_be::new(0x0102))
| ^^^^^^^^^^^^ use of undeclared type AtomicU16_be
error[E0433]: failed to resolve: use of undeclared type AtomicU16_le
--> src/lib.rs:474:46
|
474 | mem::transmute::<, [u8; 2]>(AtomicU16_le::new(0x0102))
| ^^^^^^^^^^^^ use of undeclared type AtomicU16_le
error[E0433]: failed to resolve: use of undeclared type AtomicU32_be
--> src/lib.rs:480:46
|
480 | mem::transmute::<, [u8; 4]>(AtomicU32_be::new(0x01020304))
| ^^^^^^^^^^^^ use of undeclared type AtomicU32_be
error[E0433]: failed to resolve: use of undeclared type AtomicU32_le
--> src/lib.rs:484:46
|
484 | mem::transmute::<, [u8; 4]>(AtomicU32_le::new(0x01020304))
| ^^^^^^^^^^^^ use of undeclared type AtomicU32_le
error[E0433]: failed to resolve: use of undeclared type AtomicU64_be
--> src/lib.rs:490:46
|
490 | mem::transmute::<, [u8; 8]>(AtomicU64_be::new(0x0102030405060708))
| ^^^^^^^^^^^^ use of undeclared type AtomicU64_be
error[E0433]: failed to resolve: use of undeclared type AtomicU64_le
--> src/lib.rs:494:46
|
494 | mem::transmute::<, [u8; 8]>(AtomicU64_le::new(0x0102030405060708))
| ^^^^^^^^^^^^ use of undeclared type AtomicU64_le
error: aborting due to 6 previous errors

How can one make a u32_be from a u16_be?

Title says it all, how can I get a u32_be from a u16_be?

SIMD support

While adding rkyv support to glam, the question came up of how to handle SIMD-optimized types. There are a few pieces here:

SIMD types should ideally have the same archived and unarchived representations. Otherwise, the same code would be duplicated many more times to support explicitly-endian types like f32_le and i64_be.
Some types may have different layouts depending on whether SIMD support is enabled. Many SIMD types have higher alignment, for example.
On-demand endianness conversions (for example, reading an i32_be on a little-endian machine) may have negative performance impacts and should be carefully benchmarked.

With those in mind, let's take a look at the following:

Can common types like vectors and matrices be parameterized over rend types? For example type Vec2_le = XY<f32_le> and type Vec2_be = XY<f32_be>?
Should archived types have their alignments artificially raised to the highest common alignment? This may affect packing performance.
Should SIMD types be archived as more basic data types and only be converted to SIMD types on read? This would be sad for performance but good for sanity. Maybe having a wrapper type to allow for either behavior would be best?

With the concrete goals:

Determine the best approach for archiving explicitly-endian data with respect to compatibility, ergonomics, code impact, and performance.
Get some proofs of the concept working with glam and consider looking at other popular vector math libraries like cgmath and uv.
Perform some benchmarking to figure out the performance story.

error: cross-crate traits with a default impl, like `Sync`, should not be specialized

When running build on this crate with

➜  rkyv git:(master) ✗ cargo --version
cargo 1.63.0 (fd9c4297c 2022-07-01)
➜  rkyv git:(master) ✗ rustc --version
rustc 1.63.0 (4b91a6ea7 2022-08-08)
➜  rkyv git:(master) ✗

I'm getting

error: cross-crate traits with a default impl, like `Sync`, should not be specialized
   --> /Users/dev/rend/src/impl_struct.rs:396:9
    |
396 |           unsafe impl Sync for $endian<$ne> {}
    |           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
   ::: /Users/dev/rend/src/lib.rs:338:1
    |
338 | / impl_endian!(
339 | |     @atomic AtomicU64 = u64,
340 | |     AtomicU64_ne = "`NativeEndian<AtomicU64>`",
341 | |     AtomicU64_le = "`LittleEndian<AtomicU64>`",
342 | |     AtomicU64_be = "`BigEndian<AtomicU64>`"
343 | | );
    | |_- in this macro invocation
    |
    = warning: this will change its meaning in a future release!
    = note: for more information, see issue #93367 <https://github.com/rust-lang/rust/issues/93367>
    = note: `AtomicU64` is not a generic parameter
note: try using the same sequence of generic parameters as the struct definition
   --> /Users/dev/rend/src/lib.rs:110:1
    |
110 | / pub struct BigEndian<T> {
111 | |     value: T,
112 | | }
    | |_^
    = note: this error originates in the macro `impl_struct` (in Nightly builds, run with -Z macro-backtrace for more info)

error: could not compile `rend` due to 36 previous errors

would love to hear if you have thoughts why?

Tests on `char` broken on riscv64 and sparc64

Replace mem::transmute::<_, [u8; 4]>(char_{be,le}::new('🎉')) with u32::from('🎉').to_{be,le}_bytes() and the assert passes on riscv64. I don't have a sparc64 environment to test on.

From Debian buildd log: riscv64 sparc64

riscv64:

running 1 test
test tests::endian_representation ... FAILED

failures:

---- tests::endian_representation stdout ----
thread 'tests::endian_representation' panicked at 'assertion failed: `(left == right)`
  left: `[0, 1, 243, 137]`,
 right: `[0, 1, 243, 0]`', src/lib.rs:466:13
stack backtrace:
   0: rust_begin_unwind
             at /usr/src/rustc-1.59.0/library/std/src/panicking.rs:498:5
   1: core::panicking::panic_fmt
             at /usr/src/rustc-1.59.0/library/core/src/panicking.rs:116:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
             at /usr/src/rustc-1.59.0/library/core/src/panicking.rs:154:5
   4: rend::tests::endian_representation
             at /usr/share/cargo/registry/rend-0.3.6/src/lib.rs:466:13
   5: rend::tests::endian_representation::{{closure}}
             at /usr/share/cargo/registry/rend-0.3.6/src/lib.rs:351:5
   6: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.59.0/library/core/src/ops/function.rs:227:5
   7: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.59.0/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.


failures:
    tests::endian_representation

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.08s

error: test failed, to rerun pass '--lib'

sparc64:

running 1 test
test tests::endian_representation ... FAILED

failures:

---- tests::endian_representation stdout ----
thread 'tests::endian_representation' panicked at 'assertion failed: `(left == right)`
  left: `[137, 243, 1, 0]`,
 right: `[0, 243, 1, 0]`', src/lib.rs:470:13
stack backtrace:
   0: rust_begin_unwind
             at /usr/src/rustc-1.59.0/library/std/src/panicking.rs:498:5
   1: core::panicking::panic_fmt
             at /usr/src/rustc-1.59.0/library/core/src/panicking.rs:116:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
             at /usr/src/rustc-1.59.0/library/core/src/panicking.rs:154:5
   4: rend::tests::endian_representation
             at /usr/share/cargo/registry/rend-0.3.6/src/lib.rs:470:13
   5: rend::tests::endian_representation::{{closure}}
             at /usr/share/cargo/registry/rend-0.3.6/src/lib.rs:351:5
   6: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.59.0/library/core/src/ops/function.rs:227:5
   7: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.59.0/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.


failures:
    tests::endian_representation

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.02s

error: test failed, to rerun pass '--lib'

Switch to always `no_std`

Having an std feature is pretty useless if you never use it

rkyv / rend Goto Github PK

rend's People

Contributors

Stargazers

Watchers

Forkers

rend's Issues

rend: Test failed on s390x and armv7hl arch

How can one make a u32_be from a u16_be?

SIMD support

error: cross-crate traits with a default impl, like `Sync`, should not be specialized

Tests on `char` broken on riscv64 and sparc64

Switch to always `no_std`

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent