search

rust-lang / rfcs

RFCs for changes to Rust
https://rust-lang.github.io/rfcs/
Apache License 2.0
5.89k stars 1.56k forks source link

deactivate all panics (obviously optional) #3280

Closed WormPatch closed 2 years ago

WormPatch commented 2 years ago

unreachable_unchecked is a way to tell the compiler: "this will never happend", example:

fn index(array:&[u8], x:usize) {
    if x < array.len() {
        return array[x]; //return is more readable
    } else {
        panic!("out of bounds");
    }
}

if we replace panic!() with unreachable_unchecked(), this function converts into:

fn index(array:&[u8], x:usize) { array[x] }

what happened here?, we "despanicked" a function.

panic = 'unreachable_unchecked' in Cargo.toml. will despanic all functions in project. disabling all checks

WormPatch commented 2 years ago

In fact, the whole point of unreachable_unchecked is to allow the compiler to optimize it by asserting that a certain condition is met. If we do not consider any compiler optimizations, this whole discussion is completely pointless because the performance gain from removing a branch alone is close to zero.

yes, we are considering optimizations, as in a real environment. but the analyzes sometimes don't go that deep to detect unnecesary bound checks, unrechable_unchecked doesn't require that much difficulty

workingjubilee commented 2 years ago

i understand in that context, we have good computers, that is pretty nothing even to an 1990 computer, but how would you do it in small embedding, you dont wanna drop and quit. now i remember why i feel uncomfortable with this, i have an usb wifi micro (dont wanna code in C, because i need some features).

image this has really small size pointer, drop and quit is not enough,

I could be wronng (it's hard to tell from the picture) but that looks like an Adafruit HUZZAH ESP8266 Breakout which normally has the NodeMCU eLua 5.1 interpreter preloaded on it. The ESP8266 should have at least 32 KiB instruction RAM and 80KiB data RAM, and most complete boards with it say they have at least 1 MiB flash. Adafruit says their version is slightly beefier, even, and has 64 KiB of instruction RAM, 96 KiB of data RAM, and an incredibly generous 4 MiB of flash. This is roughly comparable to the GameBoy Advance that was mentioned, which people have written Rust programs for. And its 80mHz speed absolutely demolishes the GBA's mere 16.78mHz.

You should easily be able to fit Rust programs in there with some work, assuming the compiler supports emitting optimized machine code for it. I am not sure, honestly, if it does, and if it doesn't, that makes all this moot. As you have noticed, using unreachable_unchecked does not actually reliably reduce code size. It can in fact cause generate illegal instructions instead that will abort execution. I suggest consulting https://github.com/johnthagen/min-sized-rust for advice on how to get Rust to emit smaller code.

Aside from that, there seems to be some consensus that this proposal would need a clearer motivation and might require a major (2.0) revision of the entire language, which would need its own proposal with motivation as well. Thus, I am closing this.

WormPatch commented 2 years ago

what does means closed as not planned?

Lokathor commented 2 years ago

It means that there are no plans to do this request.

WormPatch commented 2 years ago

It means that there are no plans to do this request.

by me of by rust team? (stop it i will search it myself)

thomcc commented 2 years ago

We can't stop you from doing anything, obviously. Feel free to fork the compiler and add it yourself, but there are no plans to do this officially, and as @workingjubilee stated, this would require significantly more motivation to change that.

workingjubilee commented 2 years ago

I closed this as a politeness: To make clear that, even if you did this and opened a pull request to rust-lang/rust, that it would not be accepted without more grounding reasoning, likely starting with a pull request to rust-lang/rfcs. And that even if you opened a pull request to rust-lang/rfcs, it would have to incorporate the feedback that has already been given.

Most especially, it seems to me the concern is not actually about panics in Rust. It is about code size or performance. There are other ways to address those concerns.

WormPatch commented 2 years ago

it's not because panic!() is bad or not. remember that panic!() is compiled for every sum, division, subtraction, multiplication, indexing, functions(some of them). instead reaching ASM program propose directly. i know optimizations can delete them, but... only sometimes, because compiler is not a genius. and sometimes optimization is not possible

but adding this fix it, because you have the option of using or not panics, then you always have the good side (using panics or not), depending of your program

Lokathor commented 2 years ago

In a release build (cargo build --release) the default is for all math operations to simply overflow and wrap (except an integer divide by zero).

This much is already easily configured by the overflow-checks field of your build profile.

WormPatch commented 2 years ago

In a release build (cargo build --release) the default is for all math operations to simply overflow and wrap (except an integer divide by zero).

This much is already easily configured by the overflow-checks field of your build profile.

oh yes your right, but what is the sense of panics then, if i made a DB i want it to tell me about overflow

Lokathor commented 2 years ago

If you would like to perform a checked math operation, you can use functions such as checked_add or checked_mul.

I think that you should write more rust code and become more familiar with the standard library. You'll find that almost all of your concerns are already solvable with existing standard library methods and existing compiler configuration options.

WormPatch commented 2 years ago

If you would like to perform a checked math operation, you can use functions such as checked_add or checked_mul.

I think that you should write more rust code and become more familiar with the standard library. You'll find that almost all of your concerns are already solvable with existing standard library methods and existing compiler configuration options.

what? using a function for every sum? that is terrible and you know it

WormPatch commented 2 years ago

We can't stop you from doing anything, obviously. Feel free to fork the compiler and add it yourself, but there are no plans to do this officially, and as @workingjubilee stated, this would require significantly more motivation to change that.

rustc code is too long to make it, i don't think i have the time for this. i through it was going to be easy

Lokathor commented 2 years ago

I want to be really clear: I don't think that you should try to patch rustc to make this happen. I don't think that anyone should ever try to make this idea happen. I don't think it's a good idea.

Instead, I think that you should write other rust programs to do whatever it is you want to do, and gain experience with the language and ecosystem that way.

Many people make many very fast programs in rust, I'm sure you will be able to as well.

WormPatch commented 2 years ago

I want to be really clear: I don't think that you should try to patch rustc to make this happen. I don't think that anyone should ever try to make this idea happen. I don't think it's a good idea.

Instead, I think that you should write other rust programs to do whatever it is you want to do, and gain experience with the language and ecosystem that way.

Many people make many very fast programs in rust, I'm sure you will be able to as well.

why do you think its a bad idea? it reduces space bloat and runtime

WormPatch commented 2 years ago

i understand in that context, we have good computers, that is pretty nothing even to an 1990 computer, but how would you do it in small embedding, you dont wanna drop and quit. now i remember why i feel uncomfortable with this, i have an usb wifi micro (dont wanna code in C, because i need some features). image this has really small size pointer, drop and quit is not enough,

I could be wronng (it's hard to tell from the picture) but that looks like an Adafruit HUZZAH ESP8266 Breakout which normally has the NodeMCU eLua 5.1 interpreter preloaded on it. The ESP8266 should have at least 32 KiB instruction RAM and 80KiB data RAM, and most complete boards with it say they have at least 1 MiB flash. Adafruit says their version is slightly beefier, even, and has 64 KiB of instruction RAM, 96 KiB of data RAM, and an incredibly generous 4 MiB of flash. This is roughly comparable to the GameBoy Advance that was mentioned, which people have written Rust programs for. And its 80mHz speed absolutely demolishes the GBA's mere 16.78mHz.

You should easily be able to fit Rust programs in there with some work, assuming the compiler supports emitting optimized machine code for it. I am not sure, honestly, if it does, and if it doesn't, that makes all this moot. As you have noticed, using unreachable_unchecked does not actually reliably reduce code size. It can in fact cause generate illegal instructions instead that will abort execution. I suggest consulting https://github.com/johnthagen/min-sized-rust for advice on how to get Rust to emit smaller code.

Aside from that, there seems to be some consensus that this proposal would need a clearer motivation and might require a major (2.0) revision of the entire language, which would need its own proposal with motivation as well. Thus, I am closing this.

________|_bits____|_MHz___|_usermem_|_max_file_size_|
ESP8266 | 32 bits | 80MHz | 80KB    | 1MB (sketch)  |
GBA     | 32 bits | 4MHz  | 128KB   | 8MB (catride) |

i'm not gonna lie, ESP Mhz is incredible, but... max file size is bad, maybe making an abort and comparison per indexing is too much

Kixiron commented 2 years ago

If you have no data to back up your statements there's no point is continuing this discussion, it's been closed so I'd recommend going though the proper help channels for your troubleshooting

Lokathor commented 2 years ago

Those numbers you have appear to be for the Game Boy (GB), not the Game Boy Advance (GBA). The GBA has a 16MHz CPU and 32k+256k of RAM (and 96k VRAM).

But either way, the point is that you should go and actually build whatever program you want first.

Instead of just guessing that "maybe" things might not work, make an actual program and demonstrate for sure that it either does or does not work on that device. If it turns out to not work when you've got a complete program you can share, then you could get additional tech support from one of the places I shared previously (reddit, discord, etc).

WormPatch commented 2 years ago

Those numbers you have appear to be for the Game Boy (GB), not the Game Boy Advance (GBA). The GBA has a 16MHz CPU and 32k+256k of RAM (and 96k VRAM).

But either way, the point is that you should go and actually build whatever program you want first.

Instead of just guessing that "maybe" things might not work, make an actual program and demonstrate for sure that it either does or does not work on that device. If it turns out to not work when you've got a complete program you can share, then you could get additional tech support from one of the places I shared previously (reddit, discord, etc).

i'm sure it says GBA in the info page anyways

WormPatch commented 2 years ago

If you have no data to back up your statements there's no point is continuing this discussion, it's been closed so I'd recommend going though the proper help channels for your troubleshooting

some benchmarks, i made a chess minmax to show the results replacing arr[i] to arr.get_unchecked(i), benchmarked with criterion

checked_chess_minmax
time: [702.40 ms 708.54 ms 715.72 ms]

unchecked_chess_minmax
time: [682.11 ms 685.16 ms 689.39 ms]
ChayimFriedman2 commented 2 years ago

What is the code? There may be much better approach.

WormPatch commented 2 years ago

What is the code? There may be much better approach.

do where should i pass it?

lebensterben commented 2 years ago

this discussion really needs to be locked as it wasted too much time for everyone.

the author of this RFC really should have heeded suggestions to get technical support elsewhere in Rust community.

WormPatch commented 2 years ago

this discussion really needs to be locked as it wasted too much time for everyone.

the author of this RFC really should have heeded suggestions to get technical support elsewhere in Rust community.

look, i'm not getting technical support, if you say im wasting your time at least tell me how it is not a good idea to let user to decide if panics are included in the program

WormPatch commented 2 years ago

What is the code? There may be much better approach.

https://github.com/WormPatch/temp_chess_minmax/tree/main

edit: cargo bench