1^2 = 1 * 1 = 1
2^1 = 2
820 karma · joined December 27, 2020
2^1 = 2
I built a scene distribution renderer similar to Kilauea for my masters thesis in school, except with a feed forward shader design which exploited the linear color space to never send the results of computations back up the call stack… kind of neat but yeah, all sorts of reasons why that kind of design would not work well under production workloads. And RAM has gotten so stinking cheap!
Arras was designed to let multiple machines work on a single frame in parallel. Film renderers still very much leverage the CPU for a lot of reasons, and letting a render run to completion on a single workstation could take hours. Normally this isn’t a problem for batch rendering, which typically happens overnight, for shots that will get reviewed the next day.
But sometimes it’s really nice to have a very immediate, interactive workflow at your desk. Typically you need to use a different renderer designed with a more real-time architecture in mind, and many times that means using shaders that don’t match, so it’s not an ideal workflow.
Arras was designed to be able to give you the best of both worlds. Moonray is perfectly happy to render frames in batch mode, but it can also use Arras to connect dozens of workstations together and have them all work on the same frame in parallel. This basically gives you a film-quality interactive lighting session at your desk, where the final render will match what you see pixel for pixel because ultimately you’re using the same renderer and the same shaders.
RDL has two on-disk formats, RDLA (for “Ascii”) and RDLB (for “Binary”). The text format is literally just a Lua script which uses various function calls to instantiate scene objects and set their parameters. It’s great for spinning up test scenes and doing development work on shaders or the renderer itself.
The binary format (which at the time used Protobuf to serialize scene objects, not sure if that’s still true) is more suited to production workflows where you don’t want to deal with things like floating point to text precision issues and a more space efficient representation is preferred.
I found some documentation and examples of the RDL format here: https://docs.openmoonray.org/getting-started/about/rdl-scene...
And it looks like the user documentation has some examples of how to do things, including instantiating various types of scene objects: https://docs.openmoonray.org/user-reference/
Time shifting risk would be perfectly fine if market makers had to play by the same rules as everyone else in the market, but they don't. They get to ignore certain rules, which results in distorted prices because they can effectively accept infinite risk over an infinite length of time.
Let's say there's suddenly a run-up of $WEN and I, as a retail investor, want to short it because I think the price will surely come back down eventually. If it continues to go up, ultimately I get margin called and have a very short period of time to produce a lot of money to keep that trade open, otherwise I'm liquidated. There is a (risk * time) maximum before I, the retail investor, ultimately go out of business.
Market makers are exempt from this. They are legally permitted to short stock by conjuring phantom shares from thin air without having to locate borrows to satiate the buying demand during the run-up and wait effectively an infinite amount of time to repurchase the shares. There is no limit to their (risk * time) budget. Better yet, when the underlying company ultimately goes bankrupt from the stock being cellar boxed into the ground, the market maker can just wrap up all the worthless, sub-penny shares into a zombie holding company which lives forever, so they have never close the trade and actually pay taxes on the ill-gotten gains. Meanwhile, nobody seems to bat an eye at tens of billions of "securities sold, not yet purchased" on the market maker's balance sheet, because hey, as long as the SEC remains a wet noodle thanks to regulatory capture, they'll never get charged with fraud and the music keeps playing.
It's a system that has been deliberately structured to screw over average retail investors and concentrate wealth behind a few large market making firms, which incredulously all have their own hedge funds (which is somehow not seen as a hilariously brazen conflict of interest). Whenever anyone asks why all this complexity is necessary, the "We provide liquidity, so you can trade right now, for free!" line is trotted out and they hope you go away so they can continue running their shell game. Our markets have become addicted to this fake liquidity, which is ultimately backed by an infinitely expanding risk balloon. As long as the balloon never pops, the game is still on.
I've honestly never understood this. Economics 101 teaches us that artificially manipulating supply (liquidity) is at direct odds with a free market's ability to do price discovery. If there is effectively infinite supply of any security (because all these high frequency firms are instantly hedging out the risk against their entire portfolio), why should anyone believe the NBBO? It's just a made up fantasy number at that point. It doesn't represent what the real security is worth because there are an infinite number of buyers and sellers willing to transact at any moment.
It really does feel like an enormous grift.
Minor nit: You can fly at night with a Private Pilot's certificate, but it must be under VFR like all your daytime flying.
In particular, it’s almost impossible to get glibc to link statically. You need to switch to musl or another libc that supports it.
It's on my list of things that I will inevitably never get to.
But if you actually have to get something done for your business to exist, it's a lot of unrelated work to keep the beast fed and happy.
Yes, and it's very important to note that Bazel does nothing to solve the problem about having a reproducible and hermetic runtime. Even if you think you aren't linking against anything dynamically, you are probably linking against several system libraries which must be present in the same versions to get reproducible and hermetic behavior.
This is solvable with Docker or exceptionally arcane Linux hackery, but it's completely missing from the Bazel messaging and it often leaves people thinking it provides more than it really does.
In my experience it hasn't panned out like that.
We desperately want to believe it, because we see how valuable we are to the business. But the reality is that the people making decisions rarely understand the value of the dirty work because they, themselves, have no interest in it. It could be absolutely critical to the business but they will happily walk away because they have no interest in understanding the work you do or its ultimate importance to their own goals.
The article isn't critical of mathematical models, it's specifically critical of deep learning. Is there any evidence that the Medallion Fund uses deep learning? Are there any funds that have said they use deep learning that have a consistent track record of beating the market?
My (admittedly anecdotal) understanding is that many, many people have tried using deep learning to predict the market and I'm not aware of anyone who has had long term, consistent success with it.
Most style guides I've seen that use underscores in identifier names use trailing underscores deliberately to avoid colliding with names reserved by the standard.
Now, if that's the level they engage at, that might be ok for a junior role. I expect juniors to require projects to be spelled out in excruciating detail, and to not deviate from exactly what they were told to do. That's what, by definition makes them junior.
A senior engineer on the other hand, can generally be given vaguely defined tasks and has the initiative to figure out what actually needs to be built in the first place, before launching into building something.
I don't have a specific threshold of performance I'm expecting for passing or failing the interview. It's about gauging where a candidates skills are on a spectrum, and then seeing if that skill level lines up with their experience and the job level the are interviewing for.
If you have senior experience and are interviewing for a senior role, my expectations are higher. If you perform at a junior level, then either we'd offer you a junior role instead or not make an offer. If you have junior experience and do well, then it might be time to make the leap to a senior role, or we'd make you a very attractive junior offer because we see that you're likely to advance quickly.
Generally the entire interview is, "Let's design an X", where X is some kind of system that has a substantial software component. The goal is to see how a candidate handles an open ended design problem of undefined size when we only have 45-60 minutes to discuss it.
For example, do they expect to be handed requirements? Do they ask what the requirements and use cases are? How much detail do they go into? Can they strike the right balance of depth and breadth of the requirements? (Or better yet, can they ask the right questions for guidance on what level of depth I'm looking for?) Once they've settled on a design, can they at least write pseudo code to demonstrate how the software would work? Can they come up with reasonable test cases? Do they even think about how they're going to test the system at all? Did they design for testability or was that an afterthought?
Some of the most effective systems for X include things that feel trivial or simple on the surface, but have some layer of hidden complexity that's only apparent once you really start thinking about it how it works, where different people may have different expectations or assumptions about the desired system behavior. For example, I frequently use a Garage Door Opener. It seems simple enough until you start enumerating the different states the system can be in, what should happen in each state when the button is pressed, what happens if multiple buttons are pressed at the same time, how to integrate the safety laser sensor which is supposed to stop the door if something is under it, etc.
More senior engineers tend to ask lots of clarifying questions and probe the bounds of the design and expectations of the customer before they start. They usually end up in good shape, because they discovered the potential blind alleys early in the discussion, their questions helped them understand the right scope for the system design, etc. It usually works out well with some very minor refactoring along the way.
More junior engineers tend to assume a LOT of the requirements and use cases if the system's operation sounds simple, and jump straight into coding without establishing these things explicitly. This is almost always a mistake, because you discover important design considerations too late and end up having to do major refactors for things that could have been identified at the very beginning, if only you'd taken more initiative and asked more questions.
For example, I recently gave this interview to a junior with 3 years of experience. He didn't ask many questions up front, and only after 45 minutes did we come to realize that he assumed the garage door remote would have 2 buttons, one to explicitly make the door go up and one to make the door go down. I (the customer) had assumed there would be one button that would toggle directions based on the door state, but this never came up or was asked about before he launched into a complex design involving 7 different classes and several circular dependencies.
I appreciate that this is probably true, but ultimately I moved all my personal email from Gmail to Fastmail for a similar reason. It honestly feels good to pay someone for the service to improve the chances that our incentives are aligned. It's hard to believe my incentives will ever be aligned with Google when they are notorious for slurping up every ounce of user data they can find for the purposes of ad targeting.
This isn't true in my experience at large companies. For this to be true, you would either need to have absolutely no shared core libraries, or core libraries that are so stable and unchanging that they never receive updates. Updates to those core libraries usually result in a cascade of changes across a ton of repos, tons of tests that need to be rerun, and a slew of now incompatible versions.
All of these problems go away with a monorepo. Monorepos are absolutely the right solution for 98% of companies out there because they will never reach the engineering scale where monorepos start to struggle. For the 2% of companies that do reach that engineering scale, these kinds of blog posts get written.
The mistake is reading blog posts like this and thinking is necessary or even relevant to any more than 2% of the companies out there. The vast majority of shops will never need anything like this.
And I would be willing to be substantial sums of money that any metrics Google has with respect to "adding value to the user" are actually more directly track "adding value to the business".
Did you try asking him to stop, or to eat somewhere else?
You've moved the goal posts to narrow the focus onto Google Docs, though. When my grandma wants to write a letter, she doesn't go searching for a "cloud-based shareable free office suite". She launches whatever is already installed on her computer.
I don't think this is a fair characterization. Most crypto fans I know want regulations, they just want them clearly defined and enforced with software and distributed consensus rather than through corrupt and ineffective organizations like the SEC.
For example, we had simulation test suites which would run ~30 seconds of real-world time. If we can run those sims at 10x real time, each only takes 3 seconds, great! But with optimizations turned off, heavy Eigen code would run 1000x slower, which means the sims now take nearly 3000 seconds to run when bug hunting in the non-Eigen related surrounding logic. This already makes the test suite virtually un-runnable in debug builds, but if you want to then run those binaries through Valgrind (which tacks on another 100-1000x performance tax) you're now talking about something which is completely intractable. You can't run optimized builds through Valgrind without potentially introducing false positives, so you can't even run Valgrind on only the optimized builds... you just can't run it at all because your linear algebra library is slowing everything down.
The core problem is Eigen's heavy use of expression templates, which the optimizer cuts through just fine. But without the optimizer turned on, it adds layers and layers and layers of unnecessary abstraction. Because these are all templates, C++ expands all this code at every call site, making it substantially less efficient and impossible to shim out by linking with an optimized build of Eigen itself.
The only approach I've seen get close to making this work was an attempt by an engineer to use explicit template instantiation to create a separate binary with all the necessary Eigen functions which could be compiled separately with the optimizer turned on. However, this proved too nightmarish because since Eigen can template on the dimensions of everything, you need to know up front exactly all the various instantiations of Eigen types the program uses. This might be doable by writing a clang plugin or something, but doing it by hand was just way too much work because the codebase was huge, so we couldn't justify spending more time on it.
Eigen makes extensive use of expression templates in C++ to collapse complex operation sequences into streamlined and minimal calculations. This is generally ok, until you need a debug build. I've regularly seen debug builds of software using Eigen run 1000x to 10000x slower than the release build, which seriously complicates various debugging workflows. It also makes it a nightmare to run your test suite through valgrind, for example.
I've seen several engineers attempt (and fail) to try creating/linking a release build of Eigen with a debug build of the rest of the program to try to regain most of that speed while still allowing a decent amount of debugability, but this is really hard due to all the aggressive inlining and heavy use of templates.
In my experience, I would happily accept a 2x or more slowdown in linear algebra performance in release builds in exchange for significant boost in debug execution speed. If you're starting a greenfield project, you should consider how important decent debug performance is before choosing Eigen by default.
Way off base, in my experience. The vast majority of highly talented developers are rarely, if ever, actually on the market. They have multiple competing offers before ever walking out the door of their previous employer. There is no way they’re going to spend 30 hours of their time on maybe getting an offer from you. It doesn’t even matter if you pay them for it. Why would I take $4000 for maybe getting an offer, when I’m already deciding between multiple guaranteed offers? It’s just a huge waste of my time.
More importantly though, this process is strongly biased towards young, single people with no hobbies. You’ll likely never get a parent to commit to this kind of interview, because when I’m not working I’d much rather be spending that time with my family. Additionally, as a parent I’m concerned about stability because other people depending on me for food and shelter. Yanking me around for several weeks or months on a probationary period after which you can fire me even if I was doing everything great just screams amateurish to me. You’re not taking my employment seriously, so I’d rather go with one of the four offers already in hand.