Início / user-7204912

ChrisB's questions

Martin Hope
ChrisB
Asked: 2024-04-23 23:59:49 +0800 CST
  • 12

Observando a saída do assembly da seguinte função C++ simples:

#include <memory>
int square(std::unique_ptr<int> num) {
    return *num * *num;
}

Gcc e clang emitem o seguinte assembly ( -O2):

square(std::unique_ptr<int, std::default_delete<int> >):
        mov     rax, QWORD PTR [rdi]
        mov     eax, DWORD PTR [rax]
        imul    eax, eax
        ret

Isso foi muito inesperado para mim: para onde o destruidor está sendo chamado?

O MSVC, por outro lado, faz o que eu esperava e chama o destruidor.

Aqui está uma reprodução de godbolt: https://godbolt.org/z/e66xh9Yos

Também tentei usar tipos maiores intpara ver se é alguma otimização de tamanho pequeno, mas não pareceu ser o caso.

Alguém pode explicar o que está acontecendo aqui?

c++
Martin Hope
ChrisB
Asked: 2024-04-11 19:42:46 +0800 CST
  • 4

Eu sei que os campos nas estruturas Rust são reordenados automaticamente para economizar memória (a menos que, por exemplo, #[repr(C)]seja especificado).

Eu estava supondo que o mesmo se aplica a enums. Hoje eu estava criando um tipo auxiliar simples (a semântica do exemplo não importa, trata-se de layout de memória):

pub enum LazyRwLockGuardVersionA<'a, T> {
    Unlocked(&'a RwLock<T>),
    Read {
        lock: &'a RwLock<T>, // still neccessary for promoting to write lock
        guard: RwLockReadGuard<'a, T>,
    },
    Write(RwLockWriteGuard<'a, T>),
}

Enquanto um Read/Write Guard bruto usa 16 bytes, esse tipo usa 32 . Para fazer com que o compilador use a otimização de nicho, tentei esta versão:

pub enum LazyRwLockWriteGuard<'a, T> {
    Unlocked(&'a RwLock<T>),
    Write(RwLockWriteGuard<'a, T>),
}

pub enum LazyRwLockGuardVersionB<'a, T> {
    Read {
        guard: RwLockReadGuard<'a, T>,
        lock: &'a RwLock<T>,
    },    
    NonRead(LazyRwLockWriteGuard<'a, T>),
}

Isso reduz com sucesso o uso de memória para 24 bytes.

Porém, notei algo estranho: Ao inverter a ordem dos campos na Readvariante:

pub enum LazyRwLockGuardVersionC<'a, T> {
    Read {
        lock: &'a RwLock<T>, // order of fields reversed
        guard: RwLockReadGuard<'a, T>,
    },
    NonRead(LazyRwLockWriteGuard<'a, T>),
}

Esse tipo usa repentinamente 32 bytes novamente.

Minha versão Rust é 1.77, aqui está uma reprodução do godbolt: https://godbolt.org/z/svE5v6Tr8

  • Os campos enum não podem ser reordenados pelas especificações ou o compilador é apenas 'preguiçoso' aqui?
  • Existe uma intuição aproximada para o algoritmo que o compilador usa atualmente para o layout de enums, para que eu possa entender esse resultado e evitar pessimizações acidentais do meu código no futuro?
rust
Martin Hope
ChrisB
Asked: 2024-02-04 19:32:07 +0800 CST
  • 6

Eu tenho uma malha com um ConvexDecomposition Collider usando bevy_rapier3d.

Como posso descobrir a massa que o rapier calcula para este colisor?

Meu código é mais ou menos assim:

fn asset_loaded(
    mut commands: Commands, 
    my_object: Query<(Entity, &Handle<Mesh>), With<MyObjectMarker>>,
    meshes: Res<Assets<Mesh>>,
    asset_server: Res<AssetServer>,
    loaded: Local<bool>,
){
     if *loaded{
         return;
     }
     let (my_entity, my_mesh) = my_object.single();
     if asset_server.load_state(my_mesh) != LoadState::Loaded {
         return;
     }
     let collider = Collider::from_bevy_mesh(
         meshes.get(my_mesh).unwrap(),
         &ComputedColliderShape::ConvexDecomposition(VHACDParameters::default()),
     ).unwrap();

     // ??: how can i get the computed mass of the object here? 

     commands.get_entity(my_entity).unwrap().insert(collider);
     *loaded = true;
}
rust
Martin Hope
ChrisB
Asked: 2024-01-25 07:20:33 +0800 CST
  • 6

O Rustnomicon contém o seguinte exemplo:

#[no_mangle]
extern "C" fn assert_nonzero(input: u32) {
    assert!(input != 0)
}

Se assert_nonzerofor chamado com o argumento 0, é garantido que o tempo de execução aborte (com segurança) o processo, compilado ou não com panic=abort.

A Referência Rust, por outro lado, afirma que:

Comportamento considerado indefinido: [...] Chamar uma função com a ABI de chamada errada ou desenrolar de uma função com a ABI de desenrolar errada.

Estas duas afirmações parecem-me contraditórias. assert_nonzerotem o CABI, mas relaxa com o pânico da Rust. Então, isso é garantido para abortar (com segurança) ou UB ? Não pode ser ambos.

Chayim Friedman gentilmente sugeriu em outra questão que este é realmente o UB.

Então o Rustnomicon está simplesmente desatualizado ou estou entendendo mal alguma coisa?

De forma mais geral: exatamente quando um pânico de Rust cruzando um limite FFI é considerado um comportamento indefinido?

rust
Martin Hope
ChrisB
Asked: 2023-12-02 22:08:41 +0800 CST
  • 10

A std::cell::Refestrutura em Rust é definida da seguinte forma:

pub struct Ref<'b, T: ?Sized + 'b> {
    // NB: we use a pointer instead of `&'b T` to avoid `noalias` violations, because a
    // `Ref` argument doesn't hold immutability for its whole scope, only until it drops.
    // `NonNull` is also covariant over `T`, just like we would have with `&T`.
    value: NonNull<T>,
    borrow: BorrowRef<'b>,
}

O // NBcomentário (presumo Nota bene / Nasty Bug ou algo assim?) implica que a seguinte definição não funcionaria, porque seria uma noaliasviolação (eles se referem aos atributos LLVM no backend?):

pub struct Ref2<'b, T: ?Sized + 'b> {
    value: &'b T,
    borrow: BorrowRef<'b>,
}

Não entendo esse ponto, pois tive a impressão de que a semântica não lexical do tempo de vida foi devidamente preservada na geração de código. Caso contrário, o seguinte exemplo simples (que obviamente compila) também seria ilegal, certo?:

struct Foo<'a> {
    v: &'a i32,
}
fn foo(x: &mut i32) {
    let f = Foo { v: x };
    *x = 5; // value modified while the `noalias` f.v pointer is still in scope
}

Alguém com mais conhecimento sobre os internos poderia me esclarecer sobre isso? Temo estar entendendo mal algo crítico aqui, levando a possíveis problemas em meu próprio código inseguro.

rust