sischoel
I think at least for Google there are some browser extensions that can remove these results.
>>> from operator import itemgetter
>>> dct = {'greeting': 'hello', 'thing': 'world', 'farewell': 'bye'}
>>> thing, greeting = itemgetter("thing", "greeting")(dct)
>>> thing
'world'
>>> greeting
'hello'My last systems programming class was already a few years ago and I am a bit rusty, so I got some questions:
1. Looking at the code in https://github.com/elast0ny/raw_sync-rs/blob/master/src/even...) it looks like we are using a userspace spinlock. Aren't these really bad because the mess with the process scheduler and might unnecessarily trigger the scaling governor to increase the cpu frequency? I think at least on linux one could use a semaphore to inform the consumer that new data has been produced.
2. What kind of memory guarantees do we have on modern computer architectures such as x86-64 and ARM? If the producers does two writes (I imagine first the data and then the release of the lock) - is it guaranteed that when the consumer reads the second value that also the first value has been synchronized?
Do you know if that hardware pipeline works only for these intrinsic variants?
What is still missing there, is the idea of self-attention.
Other things I remember: - Data is mapped directly from files to C structs - this provided some challenges as I had to convert big endian to little endian. - Classic MacOS handled memory allocations quite a bit different, if one wanted to access a dynamically allocated buffer, they first had to acquire a lock on that part of memory as otherwise the operating system was allowed to move the data to some other address.
My memory on these details is quite a bit fuzzy though, so I can't guarantee that what I wrote here is 100% correct.
I think a lot of these graphs where generated with the genc.c program included in nauty (official website: https://pallini.di.uniroma1.it/ -- unofficial Github repository: https://github.com/lonnen/nauty). With the computing power that we have nowadays it might be easier to just to just run that program.
But of course you are right, that one could just use goto for C/C++.
Is it: - They want persistence in case the system goes down, or the task queue service is restarted.
- They want to replicate their task queue service and want to be sure that the data is properly synchronized.
- The amount of tasks/time if simply too much for some standard library queues
- They think is is easier to add another dependency than implement it themselves
- something else
?
There is also a secret option to get into a lisp repl in Julia "julia --lisp".
Another interesting question where one could sink a lot of time is how do to binary search on GPU's using multiple threads. There branching in multiple threads at the same time is also bad, but for slightly different reasons.
Although strictly speaking the idea with the evolutionary trees is a bit older, as far as I know it is from https://arxiv.org/pdf/cs/0111054.pdf
And the useful applications that I know of (apart from using it as a tool in proving theoretical things) come from replacing the Kolmogorov complexity with a a real compressor that just approximates the Kolmogorov complexity - this produces some empirical results.
For some interesting applications one might look at the the Wikipedia article for the normalized compression distance: https://en.wikipedia.org/wiki/Normalized_compression_distanc...
This paper here shows some interesting applications - it is not the first one, but the first non-paywalled one that I found: https://arxiv.org/pdf/cs/0312044.pdf
There is also a book by Paul Vitanyi - it has been a while since I looked at it, but if I remember correctly it also discusses some of these applications: https://www.amazon.com/Introduction-Kolmogorov-Complexity-Ap...
The way I would solve something like that is by mentioning that it is a good approach to do time calculations with some library functions so that I won't have to deal with all the weird edge cases, then start with a loop over the months and later refine that to get rid of the loop, but it is very much possible that an interviewer might view this loop negatively.
There might also be some cultural aspects. While the Gregorian calendar is probably somehow used everywhere in the world, I think there might also be some other calendar formats being used in parallel.
If it is the first interview of the day, maybe the candidates are also just nervous? I remember when I had my on site interview at Google, the first warm up question had something to do with probability and could be easily solved with linearity of expectation. In the months before that interview I had dealt quite a lot with probability for my master thesis - but at that day I was quite nervous and I had not slept well, so I spend quite a lot of time on that question. I think I answered later questions better, although it was not enough in the end.
Do you usually see some correlation between the warm-up question and later performance?
I am not sure if that is necessary, but what might help is by starting to calculate the number of days from the start of the month and then adapt the question.