#memory allocation problems...

1 messages · Page 1 of 1 (latest)

acoustic dome
#

this code must be ai generated, it is complete nonsense

sly moon
#

You cant try since your function doesnt return an error union
Youll need to catch the allocator.alloc calls at least

#

Yeah didnt even notice that but it is very odd

#

allocator.alloc(u8, 44) catch @panic(“uh”):

#

try … catch … doesnt make senes (99.99% of the time)

#

try foo is syntax sugar for foo catch |err| return err

#

so unless you have like a E!U!T (error union of an error union) you won’t see that ever

#

also just fyi, it’s almost always wrong to do an allocator.alloc when the size is comptime known
it’s much slower than just doing var buf: [44]u8 = undefined

#

technically there might be a case where you’re doing a deeply recursive function and you know you might run out of stack space if you don’t use the heap, but I really wouldnt worry about that

#

it allocates on the stack, allocator.alloc (usually) allocates on the heap

limpid knoll
#

you say "appended to the end of the 24 byte" does this mean you want to concat strings or do you want to calculate sha256(input<<8+[try out this number])?

sly moon
#

var buf: [44]u8 just increases the stack frame of the function by 44 bytes, it’s essentially a no-op
while allocator.alloc(u8, 44) can be infinitely complex and almost always is very complicated (except for a fixed buffer allocator, but even then you have the indirection overhead)

#

what’s the type of result and target

#

you can do @compileLog(@TypeOf(result), @TypeOf(target)) if youre not sure

limpid knoll
#

*[]u8 is a pointer to a slice. You probably want to use *[24]u8 and *[32]u8

#

What is the salt + i? Is it a string concat?

sly moon
#

you should be able to do

var buf: [std.fmt.count(input.len + "500000".len] = undefined;

that way you don't need to worry about overflow and you can also do catch unreachable since bufPrint cant fail now

#

also make sure youre compiling as ReleaseFast or ReleaseSafe since Debug speed is expected to be really bad

reef wing
#

rust takes... i just tested and it seems to be taking around 2400ms, wtf? last time i checked it was around 1300ms... bruh
depends on what runtime you're using, but wasm is usually jit compiled IIRC? that + background processes might cause significant performance variation

#

maybe send your rust code as well?

gaunt flax
#

Note that the return value from bufPrint is the portion of buf that it overwrote.
The fact that you're ignoring it and using the entirety of buf when hashing is probably a mistake on your part.

#

I also don't know if you're actually comparing apples and apples with those timings or not

sly moon
#

since you know 500000 is the biggest number that it can be, you also know that’s the longest string possible
so you can safely assume every other iteration will use at most that many characters

#

the buffer is set to undefined, so itll be 0xAA bytes on Debug and ReleaseSafe and whatever garbage happened to be on the stack on ReleaseFast/ReleaseSmall, it’s always illegal to rely on it being a specific value or even being a valid encoding for that type

#

you should be able to do this with 0 memory

#

unless that includes stack memory

#

but I doubt that

#

also id recommend setting optimize to b.standardOptimizeOption(.{}), that way you can override it from the command line
itll be Debug by default but then you can do -OReleaseFast to make a release build
Debug will help you catch tons of small mistakes

stoic burrow
#

ignoring the return of bufPrint is almost always a mistake as mentioned earlier, you likely want to do:

const str = std.fmt.bufPrint(...) catch unreachable;
// ...
hasher.update(str);