Antoni

You Need A Budget

I deal with the spending problem for quite some time. But it is not necessarily an overspending one, actually, I spend less than I earn and manage to save money for bigger buys and investments. My problem is mostly connected with emotions, especially guilt when I feel like I am spending too much on daily basis but at the end of the month, everything is fine. And this guilt does not come from spending too much because I would categorize myself as a defensive spender. It mostly comes out of the feeling of the unknown.

I do not know how much I spend weekly, I do not plan ahead, I just trust my intuition and some really basic calculations like: divide all the money by the days left so I know how much I can spend today. But right now I want to point out one thing - it works. It is a very effective one when you are on a low unexpected budget, I mean you are a student. You do not have much money to spend and do not know when a spontaneous trip or party will pop up. You just live day by day trying to survive ;D

But what got me here won’t get me there. I believe in systematic thinking and try not to trust my mind too much on things that a great designed system can take care of. And that is something I have been looking for: a way to systemize my finances so I spend on important things and have spare money to travel, have fun and invest.

I felt especially motivated after a really mind-opening event happened. I was at the bakery and the lady before me asked the seller about the price of every cake and later summed up with the words: “the cheapest one please”. At that very moment, I thought: I do not want to live like this.

Now is the perfect moment to figure out my personal budgeting, I have begun to earn my own money and I am on course to my financial independence. I want my future to be stress-free and planned ahead. I want to enter the shop (or website) and know how much money I can spend. Get rid of this emotional burden of calculating how much I can spend and buy things with the best value-to-price ratio. To make the best consumer decision.

My first action point was to look for a budgeting app, I downloaded one which looked promising. It had lots of features, categories, summaries, and reports. But it was nothing new for me, just a more fancy UI than opening my bank account. I wanted something better. So I googled “best budgeting app” and there was a blog post with “best apps” on the list one clicked for me “YNAB - zero-based budgeting”. Interesting name + not yet known term, perfect. One funny thing I remember is that on-site listed “UI feels nothing more than excel spreadsheet” as a con but for me, it was a pro ;D

My first impression was really odd, I connected my bank account, and added expenses and inflows but actually I did not quite get what they were talking about. At this moment came the section “Help” - literally something I was taught my whole life to avoid (thanks windows). There was a 30 min explanatory video on how to set up a budget inside an app, click by click. And watching along with it I caught that I had some misconceptions about it. It defines a domain of the problem a bit differently, instead of focusing on certain amounts of money and expenses you focus on assigning money to categories.

you have 100$ in your bank account

now you assign it to categories

groceries : 50$
clothes : 25$
transport : 25$

in the grocery store you open your budget and see exactly how much you can spend

you can divide your budgets weekly 
you can set bigger goals which span longer e.g. christmas gifts.

I discovered this app today but already can recommend it. It introduced me to a new mental model for thinking about budgeting - envelope budgeting. It made me think about what I want to accomplish and search outside of my mind for a solution. Escape the cognitive illusion that I cannot take care of it and it will and should be the pain for time being.

I want to give it a try in the upcoming month and look forward to documenting my thoughts.

Vagus Nerve can boost your mood

You spot a snake on the side of the trail, just a step or two away. You freeze for a moment. Your breath quickens, heart races, and eyes widen. You look closer and realize the snake is actually just a stick. Instinctively, you take a deep breath and let out a long exhalation.

That action actually stimulated your vagus nerve, which instantly told your body, “We’re all good.”

It instantly caught my attention because it could sympathize with this feeling. The idea of using this brain mechanic for my own purpose seemed at least intriguing. Seemed like a low-hanging fruit that can be caught with very little effort. And indeed it is.

With each inhalation, the heart rate speeds up slightly. And with each exhalation, it slows down.

To stimulate the vagus nerve, simply extend your exhaling. For example, you might breathe in for a count of four and out for a count of eight.

It really worked for me, and I am not just saying. I had a quite stressful time in my life when I traveled abroad, and so many uncertainties appear in my consciousness. Some cause fear and panic. And in these moments I just tried to exhale longer than I inhale. And it did wonders. Very simple exercise but when used correctly can be really impactful.

I strive for things like this, simple tools to produce extraordinary effects.

Mateusz

Coding Mistake Made Intel GPUs 100X Slower in Ray Tracing

This article is basically around 10 short paragraphs about a simple pull request made in the Intel graphics driver repository. It’s not really discovering or discussing anything - no shade thrown at the author - just reporting the news. Even though, it resonates with me at this moment. That’s because in 6 months I’ll be defending my Engineering Degree (think of that as a Bachelor’s Degree for Science in Poland) where the topic is computation on GPUs. Exploring different algorithms involves a lot of copy-pasting boilerplate code but even a small mistake can lead to flawed results. Concept most prone to silent flawed results is where in GPU programming two different memory arenas are independent but in essence binded together. One of them lives in system RAM and the second one lives on the GPU RAM. Data is written by the CPU into the RAM and flushed onto the GPU, and vice-versa when the CPU wants to read memory off the GPU RAM.

My API of choice is Vulkan and it allows to allocate memory that matches given flags. With great power comes great responsibility because you can tell the GPU to use system RAM as directly. It’ll work but it’s not that quick because the PCI-E interface between them is the limiting factor. PCI-E is fast, but at this scale in one nanosecond you can only travel around 30cm. Taking the interface overhead into account it’ll be always quicker to just use the memory that is closest and has the least amount of overhead. While implementing this new algorithm it felt that it’s throughput will be at least twice that of the one I already had running. But the performance was actually around 10% of the baseline algorithm. I assumed that it’s just the way it is and GPU programming is different from CPU programming. Thinking that there are always surprises to see and things to learn I believed that the results are right and the world is weird sometimes. When I was cleaning some code in the scenario creation I noticed that the buffer labeled as Device is allocated with system RAM flags. Changing just flag used made the performance jump to 200%.

What I like about this story and this article is that to err is human. Guard rails should be put in place to always steer the person in charge to make the right decision without much thinking. How much guard rails you put up is the difference between OpenGL where everything is predetermined for you from the start and Vulkan where YOU make the choice. If you mess it up, well it’s your fault. As an API creator you want to allow the user as much flexibility as it’s possible. Now the question is are we pushing the amount of information we can store in our heads while working with those things or are those things unnecessarily complex?

ripgrep is faster than {grep, ag, git grep, ucg, pt, sift}

A musical Long Play (LP) or otherwise known as an album has many songs on it. Listening to it from the start to the end involves listening to all of the songs that it has on offer. But today more then ever someone might claim they have listened to an album whilst always skipping the same song. I’m guilty of that myself even on albums that I love to death I just always imagined it to be a boring and unfitting song overall so I skipped it. But there is always that one day where the song comes on and you just listen to it and the realization strikes. Has this song always been so good?! And it turns out that yes, the song that you always skipped very often turns out to be fantastic and you listen to it on repeat to make up for what you have missed. This skipped song on an album that turns out good in the end is a fitting metaphor for this article. I opened it at least 5 times and had a quick glance and the sheer amount of raw text always pushed me back.

But the day came when I was riding the train and my brain had an appetite for anything written. I just started to read this and half-way through I had the exact same feeling as with those skipped songs - “This is so good, why did I avoid it for so long”. The amount of information about how to make a program faster but making it do less things is fascinating. Having used ripgrep everyday at work I always assumed that it’s made of pixie dust otherwise it wouldn’t be that quick. What doesn’t grep do that ripgrep does? What doesn’t ag do that ripgrep does? Well now you are invited behind the curtain by probably the best guide to do so. Many of these code searching tools make trade-offs when it comes to code complexity vs. performance. Where ripgrep chooses to have unnecessarily complex solution that increases the speed but makes the code a living nightmare other tools just take the simpler route that while still quick is not perfect.

I appreciate ripgrep even more now that I know what it’s doing for me in order to be so quick. The initial spark that made me read this article is this email from the FreeBSD mailing list. To quote from it

GNU grep is fast because it AVOIDS LOOKING AT EVERY INPUT BYTE

And ripgrep is fast because it combines all the right decisions of other code searching tools into one handy package. To stir up some drama I’ll come out and say ripgrep is NOT FAST BECAUSE IT’S WRITTEN IN RUST. I think that it does not stand in the way of writing fast software like Go (because of garbage collection) would. Something that might be overlooked but for me it’s more important than Rust is the fact that everything is integrated and written from scratch. Programs like ag that use a third-party regex library strongly are limited by the performance of the library they use.

When Bloom filters don’t bloom

At first I wanted to write purely about Bloom filters and bask in the glory that they provide. The simplicity of the data structure and what it provides is so stunning that you forget about the fact that you’re living in the real world. Places where Bloom filters are actually useful and not a neat things are sparse - think databases and places where A LOT (10^9 at least) of records are present. I’m stunned that every thing that I write about turns to we live in a society where CPUs have caches.

You can assume modern CPUs are infinitely fast. They run at infinite speed until they hit the memory wall.

Read about Bloom filters they’re neat, but remember that CPUs are the actual place where all of this code gets executed.