Coca leaves contain various alkaloids, but not caffeine. Coca Cola gets its caffeine from (traditionally) kola nuts, and (today, presumedly) the usual industrial sources.
Are you at a company that tends to hire from non-traditional backgrounds? The topics you mention -- the underlying "how it works" of the tech we use to build things day to day -- should be, and in my experience are, the areas where juniors have the clearest understanding relative to more senior engineers, since they just finished 4+ years learning about it five days a week in detail.
Good point.. A lot of those colleagues were indeed either fresh out of college (math, computer science, mechanism etc...) or graduated in things like electrical engineering etc.. and worked in software roles for 3-5 years..
> IMHO the bigger issue with NaN-boxing is that on 64-bit systems it relies on the address space only needing <50 bits or so, as the discriminator is stored on the high bits.
Is this right? You get 51 tag bits, of which you must use one to distinguish pointer-to-object from other uses of the tag bits (assuming Huffman-ish coding of tags). But objects are presumedly a minimum of 8-byte sized and aligned, and on most platforms I assume they'd be 16-byte sized and aligned, which means the low three (four) bits of the address are implicit, giving 53 (54) bit object addresses. This is quite a few years of runway...
There's a bit of time yes, but for an engine that relies on this format (e.g. spidermonkey), the assumptions associated with the value boxing format would have leaked into the codebase all over the place. It's the kind of thing that's far less painful to take care of when you don't need to do it than when you need to do it.
But fair point on the aligned pointers - that would give you some free bits to keep using, but it gets ugly.
You're right about the 51 bits - I always get mixed up about whether it's 12 bits of exponent, or the 12 includes the sign. Point is it puts some hard constraints on a pretty large number of high bits of a pointer being free, as opposed to an alignment requirement for low-bit tagging which will never run out of bits.
This was 20+ years ago, so the "sophisticated" baseline wasn't ML or AI.
I was looking into an initial implementation and use of order files for a major platform. Quick recap: C (and similar languages) define that every function must have a unique address, but place no constraints on the relative order of those addresses. Choosing the order in which functions appear in memory can have significant performance impact. For example, suppose that you access 1,000 functions over a run of a program, each of which is 100 bytes in size. If each of those functions is mixed in with the 100,000 functions you don't call, you touch (and have to read from disk) 1000 pages; if they're all directly adjacent, you touch 25 pages. (This is a superficial description -- the thousand "but can't you" and "but also"s in your mind right now are very much the point.)
I went into this with moderately high confidence that runtime analysis was going to be the "best" answer, but figured I'd start by seeing how much of an improvement static analysis could give -- this would provide a lower bound for the possible improvement to motivate more investment in the project, and would give immediate improvements as well.
So, what are all the ways you can use static analysis of a (large!) C code base to figure out order? Well, if you can generate a call graph, you can do depth first or breadth first, both of which have theoretical arguments for them -- or you can factor in the function call size, page size, page read lookahead size, etc, and do a mixture based on chunking to those sizes... and then you can do something like an annealing pass since a 4097 byte sequence is awful and you're better off swapping something out for a slightly-less-optimal-but-single-page sequence, etc.
And to test the tool chain, you might as well do a trivial one. How about we just alphabetize the symbols?
Guess which static approach performed best? Alphabetization, by a large margin. This was entirely due to the fact that (a) the platform in question used symbol name prefixes as namespaces; (b) callers that used part of a namespace tended to use significant chunks of it; and (c) call graph generation across multiple libraries wasn't accurate so some of these patterns from the namespaces weren't visible to other approaches.
The results were amazingly good. I felt amazingly silly.
(Runtime analysis did indeed exceed this performance, significantly.)
> 2. Become very good (top 25%) at two or more things.
Is this idea that top 25% is "very good" at something innumeracy, or a subtle insight I'm missing? There's got to be a million skills that you could assess rank at -- writing embedded C code, playing basketball, identifying flora, PacMan, archery, bouldering… I can't imagine ever being able to not continue this list -- and you should expect to be in the top 25% of roughly a quarter of those skills, obviously heavily biased towards the ones you've tried, and even more biased towards the ones you care about. It's hard to imagine anyone who's not in the top 25% of skill assessment in a dozen things, let alone two or more…
Ignore the numbers - the gist is being good enough at the right two or three things can create similar value for you as being the best at one specific thing.
Everyone (for the sake of my argument) wants to be an engineer at a FAANG but there are tons of folks making more money with more autonomy because they've found a niche that combines their good-enough technical ability with an understanding or interest in an underserved market.
It depends on the population you are taking from. Being the top quartile embedded C developer in the world is perhaps unimpressive (there are up to 2 billion people better than you at embedded C programming), but being the top quartile embedded C developer within the population of professional embedded C developers is much more impressive.
I think it's generally accepted that at a high level being in the top quartile is considered very good. Not excellent. Not unicorn. Just very good.
Beyond that, it's not about becoming very good at two different, completely orthogonal things, it's about becoming very good at two things that are complementary in some way that is of value to others. Being good at PacMan and Bouldering is only particularly valuable if you are competing for opportunities to participate in a hypothetical mixed reality video game, or perhaps a very niche streaming channel. Being the top quartile of embedded c code, and flora identification could result in building software/hardware tools to identify flora, which is a niche that currently has multiple competing products that are high value to those interested.
If you consider your denominator to be the population of practitioners, rather than "everybody", top quartile would be pretty good. To use chess as an example, the 75th percentile of the global population probably knows the rules and nothing else. The 75th percentile of chess players would be an Elo of 1800 and change.
It's (obviously) a random number pulled out from someone's ass. However, I think top 25% isn't that off. It means top 25% of people who actually tried.
If it still sounds easy, try to reach top 25% rank of a video game that you are not familiar with (diamond in Starcraft II or whatever). You'll find it's literally the workload of a full-time job.
a [chemist, biologist, mathematician, DSP researcher] who can code at a professional level (that 25%) is worth far more to the right position than either of those skills individually.
If you haven't tried Hidden Rose apples, give them a try. Besides being gorgeous, they have a tart:sweet ratio that's similar to Granny Smith, but with a texture that's further away from a baking apple and a thinner skin. Absolutely my favorite lately.
Coca leaves contain various alkaloids, but not caffeine. Coca Cola gets its caffeine from (traditionally) kola nuts, and (today, presumedly) the usual industrial sources.
reply