because having those impls would break pretty much every rust program
#we have Index usize, but why not Index u8, u16, or u32?
timber wharf
try uncommenting this code: ```rust
use core::ops::Index;
struct Foo;
impl Index<usize> for Foo{
type Output = ();
fn index(&self, _index: usize) -> &(){
&()
}
}
/*
impl Index<u8> for Foo{
type Output = ();
fn index(&self, _index: u8) -> &(){
&()
}
}
*/
fn main(){
let foo = Foo;
let _ = foo[42];
}```
formal cargo
ah... interesting
im running into this situation where i want to optimize the amount of memory i need to use
restive estuary
you should prob use c, c++ if you care about maximum efficency, but its a giant headache
formal cargo
I have many of a certain type of object which has many u8s which eventually will be used as indices
restive estuary
but i dont think using a smaller iterator is gonne hurt your memory usage, its mostly other thing
ah
restive estuary
have you tryed type casting?
timber wharf
sounds like you'll have to do a bunch of thing[x as usize]
timber wharf
it doesn't matter
formal cargo
so there is thing[x as usize] all over the place
restive estuary
so whats the problem?
formal cargo
im wondering if it A) inefficient or B) redundant
if I have u8, going to usize all the time seems inefficient and redundant
restive estuary
from what i measured in c++ using rdtsc, i couldend measure a diffrence in speed when i type casted, but im just an amateur so idk if it was accurte measurment
formal cargo
i suppose it would probably depend on the instructions being issued and perhaps the processor
i havnt figured out how to check that kind of stuff yet with rust
i know it is possible to disassemble but i dont have full fluency in assembly
however i do want to make sure i am squeezing the amount of memory used
if only because i want to make sure i know how to do it
restive estuary
what you need to do is use inline assembly to assign the rdtsc wich is pretty much a clock, and run your code, run rdtsc again and test the diffrence in timing
timber wharf
im wondering if it A) inefficient or B) redundant
it most likely doesn't matter
restive estuary
no clue how to do that tho, i used the function that comes with the compiled to assign it to a variable
restive estuary
it most likely doesn't matter
hes almost definitly correct
formal cargo
what you need to do is use inline assembly to assign the rdtsc wich is pretty mu...
nicee thank you for that -- it looks hyper useful elsewhere
restive estuary
where talking about nanosecond diffrence
the rest of your program and how efficent that is, is gonne mather allot more
like cache locality, wherby your program has to jump arround and take allot of time to fetch data from memory, instead of prefetching
best example is an array, your cpu is pretty sure that your gonne acces the next elements from the array so it already fetches it from ram
left spear
unless youre running on like a 6502, using 8 bytes for a usize isntead of one byte for a u8 is a welcome trade off to be able to have a standarized value that all containers implement
It's a non issue
if it is an issue, then you should be writing in assembly or C as the highest level
restive estuary
but if you have an array and you jump from index to index your cpu will not be able to predict that and stall, becuse its waiting for a memory fetch
formal cargo
im ultimately planning to target some tiny microprocessors
formal cargo
8 bit cnn computation at edge
left spear
what's it called
formal cargo
custom chips
restive estuary
no clue about microproccesors
left spear
do you have an assembler for it?
left spear
what ISA is it based off and what is your toolchain as of now
formal cargo
bit of a hybrid
left spear
can I get some actual concrete information and not just "custom chip"
because trying to target rust -> some weird ass chip probably isng going to work very well in the long term
its dodgy even on stm32h7 which is what I use at work.
which is a very well supported chip
formal cargo
it is custom hardware actually
there are arm cores at a high level but there is also a separate hardware layer underneath that
left spear
have you made documentaytion or is this a psssion project
formal cargo
neither
left spear
have you even gotten a rust hello world to run yet?
left spear
imo you should stick with C. getting rust to run on that thing is almost certanlly going to be a nightmate
formal cargo
both unwelcome and unnecessary
you can stick with c for yours if you like
i like rust
left spear
well so do I, but I also like being practical and know when to cut my losses before I waste two work weeks getting a toolchain to work :)
is your C compiler llvm based by chance
it is possible for rust to emit llvm iirc
restive estuary
whats that?
left spear
whats that?
llvm is a mid level representation language that is like assembly but can be easily further compiled down to a lower level assembly. Imagine something like java byte code except entierly different lol
timber wharf
i do not appreciate the condescension
tbh i agree that this part of the conversation is not particularly helpful. i'll say again that the u8 vs usize thing most likely doesn't matter. if you find that it does, create a newtype and you can do whatever indexing you want
formal cargo
ultimately what i want to do is emit instructions for the chip directly
restive estuary
ah
left spear
ultimately what i want to do is emit instructions for the chip directly
to put it bluntly, thats not happening. in order for that to happen its going to have to get rustc architecture support
left spear
your best chance is compile rust -> MIR -> LLVM ->(use your c compiler if its LLVM based) your ARM like asm
left spear
If memory is such an issue why are you using a heap allocated vector.
left spear
you should be using [u8; LENGTH]
formal cargo
sure yea
left spear
I highly suggest that you grab an arduino (atmega328p) and learn about that before you jump into custom architecture stuff
evidently neither do you lmfao
have a good day
good luck!
formal cargo
tbh i agree that this part of the conversation is not particularly helpful. i'll...
thanks
left spear
✌️
formal cargo
evidently neither do you lmfao
I had a question which was totally valid, and you used the thread to jump in with a stream of totally unnecessary judgements, comments, and assumptions.
Totally unhelpful
If you dont have something nice to say, there is nothing to say
timber wharf
you should be using [u8; LENGTH]
you have no idea what OP is doing. nor has he shared a single code snippet.
there's a time and place to recommend particular constructs, this is not it
left spear
you have no idea what OP is doing. nor has he shared a single code snippet.
correct, this was an assumption based on the fact that he wanted to turn usize -> u8 for memory issues
formal cargo
try uncommenting this code: ```rust
use core::ops::Index;
struct Foo;
impl Inde...
This answer was quite useful to me, thank you
I think what I am going to do is write a quick wrapper that can Index<u8> when I need it
timber wharf
most likely you will find it'll bottom out at some intrinsic add/offsetting a pointer by an usize/isize. so it won't matter
cinder dove
On x86_64, indexing with a u8 cast to a usize generates 1 additional movzx instruction, which should execute in a few hundred picoseconds on modern hardware. The cost should be similarly negligible for any ARM-based architecture. You shouldn’t have any problem using a u8 for storage and casting for indexing.
fading obsidian
if I have u8, going to usize all the time seems inefficient and redundant
Isnt an indexing operation just simple pointer arithmetic followed by a dereference under the hood? The number needs to be converted to the same size as a pointer regardless in order to do that arithmetic regardless, unless im missing something.
So making it explicit can be a bit faster, reducing the need for conversions
cinder dove
Isnt an indexing operation just simple pointer arithmetic followed by a derefere...
You’re absolutely correct, but as I said, the conversion cost is minuscule. Ultimately it’s up to whether saving memory with u8s or saving cycles and verbosity with usizes is more important to the OP.