Earlier quoted context omitted.
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.
Hashcat and oclHashcat have gone open source
11–20 of 20 posts
Re: Hashcat and oclHashcat have gone open source
#12I've tried hashcat before, but does anyone know if oclHashcat works on Intel GPUs? Specifically the Iris Pro 5200?
If you're seriously interested in GPU acceleration, any reason not to spend $150 on a GTX 950 and get ~5x the performance of your Iris Pro 5200?
Re: Hashcat and oclHashcat have gone open source
#13> the kernel needs to be compiled at run time 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.
Re: Hashcat and oclHashcat have gone open source
#14Earlier quoted context omitted.
If you're seriously interested in GPU acceleration, any reason not to spend $150 on a GTX 950 and get ~5x the performance of your Iris Pro 5200?
I'm just playing around with it for fun, not doing anything particularly important. Also, I don't think I can connect a GPU to my Macbook Pro :(
Re: Hashcat and oclHashcat have gone open source
#15Earlier quoted context omitted.
I'm just playing around with it for fun, not doing anything particularly important. Also, I don't think I can connect a GPU to my Macbook Pro :(
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.
Re: Hashcat and oclHashcat have gone open source
#16> the kernel needs to be compiled at run time Are there examples of other programs that require this?
Re: Hashcat and oclHashcat have gone open source
#17I've tried hashcat before, but does anyone know if oclHashcat works on Intel GPUs? Specifically the Iris Pro 5200?
Re: Hashcat and oclHashcat have gone open source
#18Earlier quoted context omitted.
If you're seriously interested in GPU acceleration, any reason not to spend $150 on a GTX 950 and get ~5x the performance of your Iris Pro 5200?
I'm just playing around with it for fun, not doing anything particularly important. Also, I don't think I can connect a GPU to my Macbook Pro :(
Re: Hashcat and oclHashcat have gone open source
#19> the kernel needs to be compiled at run time Are there examples of other programs that require this?
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.
Re: Hashcat and oclHashcat have gone open source
#20Earlier quoted context omitted.
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.