It's a hardcoded map of int to string. That's a fairly reasonable way of doing it in vanilla C. How efficient it actually is is down to your compiler. And some compilers impose maximum limits on the size of `case` statements..
An alternative would be a precomputed hash table, similar to what `gperf` does. Requires more work in the build system though.
Besides the curious length of the switch, I'm not seeing anything particularly 'bad' about this code .. sort of left wondering what the big deal is? This is perfectly reasonable code.
It doesn't look too terrible, but it looks like it is optimized for speed, not maintainability. I'm assuming that's why there is a lot of repeated code (instead of putting it into a function/loop). The comments are a little spartan.
Sure. And it's a no go on a laptop. Though you can probably get a ~5 year old desktop with PCIe for basically free if you ask around friends and relatives. If you ssh into it, no need for a monitor either.
Any OpenCL/CUDA program for GPGPU would require this. Different GPUs may have different characteristics (core count, available instructions, memory sizes and speeds), that need to be taken into account and can be optimized for. This can only be done when you know the run-time target device, which is only at run-time.
This is the reason why for GPGPU programs, you often supply the kernel/shader as C code or another intermediate representation (vendor-specific assembly), and the final compilation step is done by the GPU driver.
19 comments
[ 2.8 ms ] story [ 48.1 ms ] threadHashcat probably isn't the best model for clean code, since its primary goal is to squeeze every drop of performance it can get.
An alternative would be a precomputed hash table, similar to what `gperf` does. Requires more work in the build system though.
http://www.sonnettech.com/PRODUCT/echoexpressse1.html
Are there examples of other programs that require this?
This all rules are optimized binary code that work directly on the data stream instead if having a runtime that applies the rules.
This is the reason why for GPGPU programs, you often supply the kernel/shader as C code or another intermediate representation (vendor-specific assembly), and the final compilation step is done by the GPU driver.