That falls into the “very desparate” part. As long as there are companies that have better recruitement processes it will help if most people prefer those over others. If all of these companies reject an applicant then this applicant might become “desparate” and turn towards worse companies. So it’s more the mass of people that influence the market and can therefore improve its conditions.
- 0 Posts
- 7 Comments
Zacryon@feddit.orgto politics @lemmy.world•Trump Brands Dems the ‘Party of Satan’ in Unhinged Rant17·7 days agoAh yes. The party of Satan, who would forcefully drag children out of their homes to send them to an unkown place. Typical satanic dem behaviour. … Oh no, wait. /s
Zacryon@feddit.orgto Technology@lemmy.world•Google's shocking developer decree struggles to justify the urgent threat to F-DroidEnglish2·11 days ago“Google stands for free and open internet”
https://blog.google/outreach-initiatives/public-policy/keep-internet-free-and-open/
Aged like milk.
I’ve got a rejection notice after I was hired by the very same company. The reason was that someone forgot to mark the application as accepted, so the system automatically sent the rejection mail. That was confusing at first, but also funny.
switch case structures are very efficient in c and c++. They work similarly like an offset into memory. Compute the offset once (any expression in the ‘case’ lines), then jump. Using primitives directly, like here with chars, is directly the offset. Contrary to if-else branches, where each case must be evaluated first and the CPU has basically no-op cycles in the pipeline until the result of the branch is known. If it fails, it proceeds with the next one, waits again etc… (Some CPU architectures might have stuff like speculative branch execution, which can speed this up.)
However, code-style wise this is really not elegant and something like your proposal or similar would be much better.
Don’t participate in such a process and the problem solves itself (unless you are very desperate). As long as companies find some idiot who jumps through these hoops, they will continue to do this. When they realize that they are deterring candidates with this shitty process, they might start changing it.
Good question! I have read a bit more about it and this does indeed heavily depend on the respective compiler implementation. Depending on the compiler, it may prefer default if-else ladders for few cases. For more, dense cases, LUTs may play a larger role. For less dense cases binary search might be chosen.
I inspected the generated assembler code of your (slightly extended) example via https://godbolt.org/
The code I used:
Using x86-64 gcc 15.2 this leads to a couple of
cmp
followed byje
instructions, so “compare” and “jump to label if equal” which basically is a typical if-else ladder. I get the same for x64 msvc v19.43.Changing the cases to 1, 2 and 3 instead of 5000, 2000 and 1000 does not change the outcome.
Increasing to 23 different but incrementally increasing cases (cases 1 to 23) does not change the outcome as well for gcc. But here msvc has introduced a performance optimization: it decreased the input value by one to get a range of 0 to 22 and then created a jump table, so a LUT with execution addresses. (I am not going to detail the assembler commands logic here, but you can use the C++ code below and take a look yourself. :) )
So even in this simple example we can already see how different compilers may implement switch cases differently depending on its structure. Even though gcc chose the apparently less efficient solution here, usually one may trust on the compiler choosing the most efficient switch implementation. ;)
As far as I know, we would not even get the chance of similar optimizations if choosing if-else ladders directly instead of a switch-case structure. It would be interesting to put this to a test though and see whether some compilers translate if-else ladders equivalently with the performance benefits that can currently come with switch structures.
The inflated code: