Something like this should be hitting the instruction level vectoriser, the basic block at a time one, nearly bang on. Its a lot of the same arithmetic op interleaved. It might be a good test case for llvm - I would have expected almost entirely vector instructions from this.
Yes. Take the one which might not halt and add an integer argument which you decrement on recursion/loop, possibly called "fuel", and return don't know when that hits zero. Then call your algorithm with a large integer for that argument and wait.
Practically speaking, if your goal is to protect system resources, which is a practical concern removed from theoretical computer science, the halting problem isn't even the right concern. It's good to know about and all, but the problem is that programs which halt can be a nuisance. You don't care about the difference between "runs for 5 days and halts" and "runs forever".
Some programs run indefinitely by design, like services. Those may be acceptable in a system, but not CPU-intensive, long-running programs.
So you in fact have to reject some programs which halt, and accept some which don't.
If you replace the uint64_t cell with an attribute((vector_size(32))) and build with march=native, the bitwise ops will work exactly as before but you'll light up the vector units on the x64 machine.
Writing the software for your company is selling it to your company in exchange for your salary.
Either you fancy writing some code and pitching it to your employer, which seems like donating it with extra steps plus some lawyers, or you want to build something for the other department and the main challenge is persuading your boss that's a good idea.
This can and should be a separate tool, probably called a linter. The compiler dealing with codegen can then just say "nope, that's not a program in this language, try the linter", optionally calling into the linter for you.
This does of course mean that divergent ideas of "correct" between linter and compiler are confusing and really do need to be avoided for happy developer times.
The right solution to that continues to be outlawing genetic risk-based cost scaling. Doing anything else means that we're just deciding people get to live and die due to their genetics and we will systematically encourage that; it's eugenics with extra steps.
That means the only insurer who could afford the risk is the US government.
openssh has been an optional windows component for... almost a decade now? including the server, so you can ssh into powershell as easily as into any unix-like. (last time I set it up there was some fiddling with file permissions required for key auth to work, but it does work.)
OpenSSH on Windows is great for the odd connection and SFTP session, but I still feel strongly that any serious usage should just stick with PuTTY and WinSCP. The GUI capabilities these provide are what Windows users are used to. The only benefit of built-in SSH is if you're working with some minimal image stuff, like Windows Server Core or Tiny11. IMHO.
reply