Share your repls and programming experiences

← Back to all posts
a brute force PIN cracker
HiImAPerson (4)

a brute force PIN cracker
idk what to put here

Comments
hotnewtop
Yimmee (10)

Typo: type ia a pin ->Type in a pin

Yimmee (10)

Wait, Ubuntu is blue and white?

DynamicSquid (5023)

For visual mode, I think one thing that's slowing you down is you're using endl. Try using \n instead, and it should be a little faster (in theory)

CSharpIsGud (1070)

@DynamicSquid Writing to stdout takes some time regardless, the only thing that would really make it fast and visual would be threading

HiImAPerson (4)

@CSharpIsGud I'll try to add that. I have only started coding

DynamicSquid (5023)

@CSharpIsGud How would you implement threading for this program? Would it be something like one thread counts odd numbers, the other thread counts even numbers?

HiImAPerson (4)

@CSharpIsGud Writing \n is causing some wierd glitches. I will have to remove it, even if it make the code slower.

CSharpIsGud (1070)

@DynamicSquid That would work, for a visual count as well you would want another thread to do the output

CSharpIsGud (1070)

@DynamicSquid @HiImAPerson Here is a threaded version of this program that uses one thread for even numbers and another for odd numbers.
After it finds the pin if visual mode is on it then outputs all the tried guesses.
For this application of threading, you can't actually see that big of a difference unless you choose a very large pin, especially on non visual mode.
Even then it's usually very close.

The threaded version can finish way slower than the non threaded one sometimes on visual mode simply because it outputs all the tried pins with a single thread, and that's a lot of pins to output for a single thread. However it actually finds the pin much much sooner and spends basically all of its time outputting pins.

https://replit.com/@CSharpIsGud/C-Multi-Threaded-PIN-brute-force-cracker

DynamicSquid (5023)

@CSharpIsGud I still think changing what kind of output you're using makes a difference. I'm not sure how accurate Replit's system is when it comes to measuring times, but I forked your repl and tested

  • endl
  • \n
  • printf
  • sync_with_stdio(false)

I'm surprised the first three almost had the same times. I thought \n would be faster than endl, and printf would be faster than cout.

If you unsync C++ output with C output, you get the fastest result. It's far faster than printf, which doesn't really make sense though. I thought those two would at least be comparable.

https://replit.com/@DynamicSquid/C-Multi-Threaded-PIN-brute-force-cracker#main.cpp

Edit: I don't think the cin.tie(0) was necessary for my repl, but Replit keeps saying "IDE having trouble" so I can't really fix it

HiImAPerson (4)

@DynamicSquid There is a problem. I don't know why, but the modifyed code doesn't work for me. (I'm on MacOS)

HiImAPerson (4)

@DynamicSquid also, idk why, but the vbiggest number it can take is 2147483647. Can you tell me why?