acfreeman dev

How to Give an Academic Presentation

2026-08-14T00:00:00+00:00

Public speaking is an art that takes a lot of practice to get good at. Being a good public speaker is what separates the wheat from the chaff, so it’s crucial that you gain this skill during your academic journey. Here are some guidelines.

Never read from a script. It’s the most frustrating thing in the world as an audience member. If you’re reading from a script, why don’t I just read that same script myself and save us all some time? This breaks all engagement with the audience.
Don’t memorize a script. In the same vein, you shouldn’t just memorize a written-out script. You need to be able to think dynamically. It’s okay to have a few words or phrases in your slideshow notes, but these should just help accelerate your context switching.
1. Items 1 and 2 are particular temptations for non-native English speakers. I truly empathize with that. However, if you never force yourself into this discomfort, you’ll never learn and improve. You have to rip the band-aid off.
Avoid “um.” This is the hardest one for me (and most people). It takes an intense amount of effort to avoid filler words. But if you can achieve that, or at least minimize the usage to a handful of times, you will stand out.
Make eye contact. Look audience members in the eye. Don’t look at any individual for too long, though, because that’s creepy.
Use gestures, and refer to the slides/whiteboard directly. Your body language should exude confidence. Laser pointers can be helpful if you don’t overuse them.
Make a joke or two. It helps keep audience members engaged.
Use dynamic inflection. Monotone speakers are boring.
Speak loudly. You should be loud enough for the people in the back of the room to hear you clearly.
Slow down. When you’re nervous, the tendency is to talk too fast. Then you realize that everybody knows you’re nervous, and then you talk faster. It’s a vicious cycle. Slow down and breathe.
Test out the A/V equipment before you start. There’s always time to test out the presentation equipment before your presentation’s start time. Take advantage of that opportunity to sort out any kinks. You don’t want to be that person who gets up there and can’t get their laptop’s display output to be detected. It’s awkward.
Have a backup plan. If your laptop were to be dropped from a 10-story building right before your presentation, what would you do? Have a copy of your presentation hosted in the cloud, somewhere easy to access. Check with a friend or conference organizer to make sure that you can borrow someone’s equipment in case something happens.
Don’t go over time. If it’s a formal, one-off presentation, you have a specific time limit. In this case, you should practice and time yourself to make sure that you respect the time limit. Leave a few minutes of buffer for questions. If you’re doing a group presentation, each person should have individual time limits that are agreed upon, and you should hold each other accountable. My pet peeve at research conferences is when everybody goes 5-10 minutes over time. Over the course of a whole session, this throws off the entire schedule. Therefore, it’s an act of disrespect to all the other presenters and attendees.
Be prepared for questions. You could give an amazing presentation, but if you can’t answer questions about the content, it leaves a sour taste in the mouth at the end. You should be able to explain any detail in your presentation at a higher level of detail. If somebody asks a question that requires a very lengthy answer, or if there’s a back-and-forth of several follow-up questions, try to summarize your answer but offer to discuss it privately afterwards. My go-to phrase is, “I’d be happy to continue this discussion offline.” This respects the time limit.
Know your audience. It’s okay to assume a certain level of background knowledge if you’re talking to an audience of experts, but not if you’re talking to a general audience. You need to adapt your material to the audience. But still, don’t tune the entire presentation for the average. A good rule of thumb that I heard once is the 70/20/10 rule: 70% of your presentation should be understood by everybody in the audience; 20% should be understood by a handful of expert audience members; and 10% should be understood by nobody in the audience. This last 10% needs to still be accurate, obviously, but the idea is that you present some small amount of material that is new to everyone, and that encourages them to do further exploration on your topic afterwards. This is what leads to interesting follow-up questions. In a conference setting, the sign of an excellent presentation is if you compel people to actually go read your paper.
Define most acronyms/initialisms early on, and consider verbally repeating the definitions later on. This is part of knowing your audience. You don’t want an overly jargony presentation, but you do want to use acronyms/initialisms when they greatly increase the efficiency of communication. For example, if I’m giving an hour-long lecture on TCP to undergraduates, I’ll explicitly say “Transmission Control Protocol” maybe a dozen times. If I’m giving a presentation on video streaming to a group of experts, I’ll never define TCP explicitly. If it’s a mixed audience, I’ll land somewhere in the middle, writing out the acronym on the slides and saying it once or twice.

Graduate Student Expectations

2025-07-22T00:00:00+00:00

This document lays out some of my expectations for a computer science graduate student working under my advisement. It also serves as a sort of guide to navigating graduate school, if you’re not sure what’s in store. The goal here is not to intimidate you or worry you, but rather to ease the transition. I know it’s hard! I was in your shoes not too long ago, and my hope is that this will make things easier.

To help prospective applicants have a better idea of what they’d be getting into with me, I’m sharing this on my public blog as well. I also recommend that you read the general advice I offer here.

The first two years

Many of the guidelines here will be geared toward PhD students, since they do a lot more research. The first two years of your graduate life, however, will be much the same between PhD and on-site Master’s students.

You’ll have to take several classes during this period: approximately two 3-credit courses per semester.

Overall, your baseline goal in your courses is this: get decently good grades. That’s it. You don’t have to get perfect grades.

This can be a stark change from your experience in undergrad or a prior Master’s degree. The reason is that every hour of time you spend on a course is one less hour that you’re spending on research. If you can spend 5 hours per week on a course and get a A-, that’s better than spending 15 hours per week on a course and getting an A. My expectation is that you’ll have an A- in at least four courses.

Now, you should use some discretion in deciding if certain courses are worth more effort and time for you. For example, I would expect you to get an A in a data compression course, since that’s a core are of research you will likely engage in. But I wouldn’t be bent out of shape if you got a B+ in an algorithms course.

Although courses take some time, your focus should already be on your research. Spend time with me discussing ideas, so we can start to identify a solid project for you to spend the next few years on.

After the third semester, you’ll have to do your qualifying exams, or “quals,” as some people call them. This is where you can be rewarded for strong grades, as you can avoid the breadth exam by having an A- or greater in a few courses. The depth exam, in contrast, focuses on your understanding of your chosen research topic, as we assess your preparedness to begin full-time research.

The last three-ish years

Once you’re done with courses, research is your one and only focus. You may still have some distractions through TA work (below) if there’s not relevant RA funding available, but your efforts as a TA will not be considered when your dissertation is being evaluated.

At this stage, you’ll need to organize your dissertation committee according to these guidelines. In addition to me, you should enlist at least three (my preference is four) other professors to evaluate your dissertation progress.

Towards the end of year 3 (or whenever you and I feel that you’re ready), you should submit your dissertation proposal. This will consist of a clear research question or thesis statement, a literature review, a discussion of your progress so far, and a thorough plan for what you intend to accomplish (and how). You’ll present this proposal to your committee, and once you pass you’ll officially be considered a PhD “candidate.”

From there, it’s full steam ahead. You should meet with your committee at least once every 6 months (i.e., once per semester) to report your progress and receive feedback. You’ll be working on papers that will get you closer to your dissertation goals, and weaving those papers into one giant, long dissertation document. Once you and I agree that you’ve made sufficient progress, you’ll submit your dissertation to your committee and arrange a meeting to defend it.

Your defense will involve an hour-long presentation, public questioning, private questioning from your committee members, and then private deliberation. If you pass, you’ll be able to include three more letters in your email signature! You’ll also be able to breathe for a minute and move on to the next phase of your career.

Grad school is a job… and a marathon

You should work roughly 40 hours per week, just like you would in a normal job. You should be proactive about scheduling regular meetings (once per week, except on holidays) with me to discuss your progress, and you should attend the weekly lab meetings.

Teaching assistants (TAs) are typically assigned 20 hours per week. If you’re working as a TA, keep a log of your hours. You should never work more than 20 hours in a week on a TA assignment. If you do, that means your professor is assigning you too much work. You should let me know, and I’ll talk to them about it for you. Research assistants (RAs) are also assigned in 20-hour blocks, but it’s not a bad thing if you go over 20 hours. Your work as an RA directly gets you closer to graduation.

Don’t work 60-hour weeks or anything ridiculous. There will occasionally be a day where you have to stay up late to meet a deadline, but this should never be the norm. In fact, if you take a careful approach to your time management, it’s possible to avoid late nights altogether. In the same vein, you should try to avoid working on weekends. You’ll come back on Monday refreshed and brimming with new ideas.

You can even take extended breaks, so long as they’re reasonable and you let me know in advance. Enjoy time with family over Thanksgiving and Christmas. Go on a big road trip during the summer. If you attend a conference in a fun location, use some of your savings to travel around the area afterwards. These are all things that I did as a PhD student, and I was a happier man for it.

You have a precious balance to maintain in your brain chemistry, spiritual and physical health, relationships, and degree progress. Plan ahead, make steady progress, and remember to stop and smell the roses.

Publish or perish?

I don’t have any firm requirements for publications, because I know that the reviewer lottery is sometimes particularly unfair. However, a good rule of thumb is this:

By the end of Year 1, have one minor 1st-author publication, or be a 2nd+ author on a major publication from the lab
One major 1st-author publication each of the following years
One 1st- or 2nd-author journal publication by the end

“Major” publications will typically be full-length papers in esteemed conferences or journals. “Minor” publications will be shorter papers, or full-length papers in not-so-good conferences. As your advisor, I can tell you what publication venues are good or “meh,” and my opinions won’t always align with the public rankings (which don’t really encompass multimedia very well).

Other expectations

These are “nice-to-haves” during your PhD that will greatly help you prepare to transition out grad school and start your career as an independent researcher:

Deliver three presentations at conferences
Write a substantial portion of one grant proposal
Work at least one research-focused internship

I’m on your side

It’s my job to advocate for you to other faculty. It’s my job to help you get published. It’s my job to help you get a job yourself. My success is largely measured by your success.

If I give you any negative feedback, it’s because I’m trying to help you improve and succeed. Every week of grad school, you should be able to think back to the previous week and say, “I know more than I did, and I’m better than I was.”

If it’s really not working…

If, for whatever reason, I don’t think that you have any chance of being successful as my student, I will let you know in a kind but clear way. That’s my commitment to you. This is important, because it’s better to let you know early than allow you to flounder and waste your time.

On the other hand, you might also find yourself dissatisfied working with me. I expect you to let me know that as well. Maybe you don’t like my style, or you decide you’re not interested in the research topics available. That’s okay! It’s always possible to change your advisor, but it’s best to realize this need early on (within the first year or two), so that your degree progress isn’t delayed.

Personal notes for my students

Every advisor has his own idiosyncrasies and sources of irritation. I hope that I can be self-aware enough to be forthcoming of what mine are. To a certain extent, recognizing and accommodating these quirks can make life easier. You should also feel entitled, though, to call me out when I’m being unreasonable. I’m a sinner just like you, and I don’t always get it right.

Don’t use “code” as a verb unless you’re talking about compression. You should instead say e.g., “program” or “write code.”
Skip the formalities in your communication. Cut to the chase—we don’t have all day here! Communication should be focused and to-the-point of the business at hand. If there’s a lot of fluff, I won’t read it in detail. That’s not to say we won’t be personable. Rather, I’d prefer if you talk to me the same way you would one of your fellow grad students, rather than someone special. You should call me by my first name.
If possible, send me a Teams DM instead of an email. Direct messages are much better for quick and interactive conversations. Emails should be more focused on separate tasks. For example, if you have a question about the methodology in a paper you’re reading, send me a DM. I can probably get back to you within a couple of hours during the work day. If you need me to sign some paperwork and it’s not due for two more weeks, send me an email. I’ll leave it flagged in my inbox until I have time to get to it.

Also, 95% of the emails I get are completely unimportant. It’s easy for your message to get lost in the noise. A DM increases the likelihood that I’ll actually see it.

What I Want from an Operating System

2024-07-25T00:00:00+00:00

Back in middle school I got my first computer. It shipped with Windows Vista, an operating system infamous for its high resource demands and sluggish performance. When Windows 7 released, I didn’t want to spend $100 (that I probably didn’t have) just to get some more performance.

In my search for alternatives, I decided to dabble with Ubuntu Linux. I was a bit worried that I would mess up the installation, so I asked my dad for permission. To help convince him, I lied and said that a friend of mine from school had installed it recently. This white lie was probably the furthest that my teenage rebellion went, and I have since told my father and received his forgiveness along with some good laughs.

In high school, I built my first computer, an awful machine running an AMD FX “8-core” CPU (that was, in reality, 4 very bad cores). I didn’t leave enough room in my budget for a Windows license, so onward with Ubuntu it was. At this point in my life, I still had some interest in computer games, so I was on the Wine struggle bus trying to get Windows programs to run. The only game I remember actually getting to work was Limbo, where I got a very jittery 20 FPS.

Some old Ubuntu install discs I found at my parents' recently. My handwriting has not improved in the intervening years.

For undergrad, I needed to use a laptop. Linux firmware support at the time was abysmal for such systems, so I switched to Windows to make my life easier. In grad school, however, I quickly found that systems development was a nightmare on Windows. I switched back, and was not disappointed.

As an aside, I had two stints using a MacBook for internships in undergrad and grad school. I was amazed at the remarkable battery life those machines could achieve. I was not amazed by much else.

These days, I dual boot PopOS (based on Ubuntu, but I may change soon) and Windows… 10? 11? I’m not even sure. I only boot into Windows ocassionally to use Adobe Lightroom for photo editing.

Now, with the Windows BSOD nightmare last week, I was reminded of some reasons why I don’t think I can go back. I’ve ranted about these topics plenty of times to my wife and friends–none of whom care, and I don’t blame them–but maybe someone online will find my views insightful. Here is everything I want from an operating system.

The perfect OS should…

Not be locked down to any particular hardware.
- Vertical integration has a couple of advantages, but they’re always outweighed by the cons in my view. I like choice, and I don’t like being price gouged.
- This knocks out MacOS, so let’s not talk about that further.
Never reboot on its own.
- I should never have to worry that my overnight compute process will be interrupted, unless I wrote bad code.
Never install or update any software without user approval.
- This seems like common sense, and this alone would have avoided the CloudStrike mess. I know that enterprises have strict software enforcement policies, but at the very least the IT team of each company should have to manually approve each individual software update. It may be less convenient, but look where convenience got us.
Come with only the most basic software out of the box.
- My software needs are different from yours. Why should we have software that we will never use?
Not push the use of any particular software.
- Make it easy to change software defaults and extension handlers. Allow me to remove any software that I don’t like.
Not be tied to a particular desktop environment.
- If I want to completely change the look and feel of my system, I should be able to.
Allow me to change anything I want, without making it difficult.
- With enough tinkering, I should be able to control anything I want to.
- I should be able to install any software I want, by any means I want.
Not break when I change things.
- Or, if it does break, make it easy to revert those changes. NixOS (and/or the Nix package manager) seem great in this regard, but I haven’t yet had the time to devote to learning them.
Not have any telemetry.
- I’m not sure that any mainline OS can claim this, and the only way to guarantee it is to never connect the device to the Internet. Still, no telemetry is the ideal. Extremely limited and anonymous telemetry (as anonymous as can be, that is), is the baseline expectation.
Not have any “AI.”
- I don’t want it or need it, except in very controlled circumstances. Generative AI built into an OS is a privacy nightmare, and unlikely to be very useful.
Not randomly eat up resources in the background.
- A cause of rage any time I boot into Windows. No, I haven’t installed any updates in months, because I haven’t booted you up in months. That doesn’t give you the right to use 100% of my CPU to run a background update installer.
Not have advertisements.
- I feel like this should be obvious, especially if it’s an OS I’ve paid for.
Get out of my way.
- Don’t require me to do something in one particular way. Don’t have flashy animations. Don’t ask me twice if I want to perform some action.
- I don’t need my operating system to be pretty or elegant. I don’t want to have to think about my operating system at all. It is merely a tool. I want it to get out of my way so I can do my work.

I wrote this list with desktop operating systems in mind, but I actually believe in these same principles for mobile operating systems, too. It should be obvious what kind of phone I have.

Advice for New PhD Students

2024-05-10T00:00:00+00:00

I’m currently wrapping up my PhD in computer science, getting ready to enter the next season of my life and career. Looking back on the last five years, I’m very happy with how things have worked out. There are some things that I wish I had done differently, but I learned some valuable lessons along the way. The following is my advice for future PhD students, under my advisement or otherwise. I write from a Christian perspective, but several of these points may apply to non-believers. I’m also writing about what worked for me, so your mileage may vary. I may update this list over the years as I gain experience as an advisor.

Your research and career are not your life
- Don’t pin your worth on the success or failure of your research. We are children of God, and He calls us by name. While you can glorify God through the uncovering of new knowledge, all your material work will fade. The relationships you foster and the disciples you make here on Earth are what will last.
Your PhD work is a job, so treat it like one
- As much as possible, try not to work on weekends. Try to keep a consistent 9-5 schedule. Sure, working 80 hours per week for 5 years may result in better research output and better job placement. But it will absolutely crush you, and there’s the law of diminishing returns. It’s not worth it. See point #1.
Be involved in your local church
- Participate in a small group. Serve in some way. Be a leader, if you are called to that.
Have friends that aren’t grad students
- You can still have friends that are grad students, of course, but it can be easy for you to get caught up in the academic bubble. Seek out people with “real-world” jobs. They won’t want to talk about academia, so you’ll have to find other things to talk about. That’s a good thing. It helps keep you grounded in reality, more pleasant to be around, and better equipped to deal with stress.
Live away from campus, and only go to campus when necessary
- You’re not a college student anymore, so you won’t really be interested in (or have the time for) all the hubbub of on-campus activities that the undergraduates engage in. It can be easy to get stuck in the college bubble if you live close to campus. Live a decent drive away, if you can, and have a physical separation between your work and personal life.
Have a designated workspace
- If you’re most productive in the quiet of your home, work there. If you need to be in your lab or office on campus, work there. If you get energized by being in a coffee shop, work there.
Have hobbies
- Have something productive and fun to do that is not work.
Try to start a family
- I could have a broader discussion about the problems with modern dating, but just know that it will take considerable effort. If you want to get married, you have to make that a priority and work towards it. Put yourself in positions where you can meet a potential spouse (see point #3). Date intentionally. Date with purity. Date only for the amount of time that it takes to determine if this is a person you want to marry. Then get engaged and get married as soon as possible.
- Having a spouse can change your entire outlook on your work and career. It’s no longer just about you. You are now forced (for the better) to allocate time for another person. You can save on rent and expenses with a double income, especially if your spouse isn’t a student, freeing you up to invest your meager graduate stipend. Life becomes much more fun and fulfilling when you’re serving others, and marriage locks in that service for life. If you don’t find that person, however, don’t fret. Serve your church, your neighbors, and your friends.
Go on adventures
- Ideally, you have a lot of flexibility with your time during grad school, and multiple opportunities to travel for research conferences. Take advantage of those! Travel as much as you can and explore the world.
Don’t be afraid of your advisor
- A quick Google search will reveal many advisor horror stories spanning verbal abuse, impossible expectations, hypocrisy, and the like. It can be easy to feel like your advisor holds a lot of power over you. In reality, I think it’s less one-sided, especially in a small lab. Your advisor expects you to produce good research, and he or she can make or break your degree progress on that basis. At the same time, Your advisor depends on you for that research, to some extent. If your advisor makes life difficult for you, then you won’t produce good work, which means it will be harder for him or her to secure grant funding in the future. If you have a really bad advisor, you’ll probably figure that out early on in your PhD journey. If you find yourself in that situation, you should change advisors. That might mean a slight delay in your progress, but it will be worth it for your mental wellbeing.
- Be honest with your advisor, even if critical. If I am ever overly difficult towards my students, hard to reach, tardy, etc., I hope that they will bring their concerns to me and we can have an honest conversation. I want to be open to criticism, because I know I have many flaws. We should always be trying to improve ourselves.
Don’t compare yourself to your peers
- You will almost certainly get imposter syndrome, but you need to fight against that. Avoid the temptation to compare your research results (number of publications or citations, attention, popularity) to others, especially if their research is in a different topic. If you are making the above points a priority, then there are definitely other students who are working harder and longer hours than you to achieve that notoriety. Others benefit from access to better academic resources and connections. Still others simply get lucky. It’s okay to not be one of those people. You need to decide for yourself what you value and set reasonable goals for yourself.

ADDER Codec

2022-08-23T00:00:00+00:00

ADΔER Codec

I’m excited to share a software library I’ve been working on called the ADΔER codec. ADΔER stands for Address, Decimation, Δt Event Representation, which I’m pitching as a radical new way to think about video. This Rust library enables users to experiment with my asynchronous, event-driven video representation, and build applications which leverage it. To showcase some of my ideas, I put together a demo with examples of transcoding framed video to ADΔER. I have a couple applications in the works which directly employ this library, which I hope to share in the coming months.

This work is the culmination of three years of research into event video representations, but does not encompass all the work I’ve done. Rather, this is just the stuff that I polished up to a state where I felt comfortable releasing it out into the wild. I needed the pressure of making my code public in order to get it to a state where it’s at least somewhat documented and readable. More is coming soon, especially as I approach a paper deadline in October! In the meantime, refer to the project’s README for more information, and star/watch it on GitHub to receive updates. And of course, let me know if you have any questions by contacting me directly or creating an issue on GitHub.

Learning a New Language in a Weekend (Rust)

2022-05-10T00:00:00+00:00

The state of things

85% of my time programming over the last few years has been in C++, 10% in Python, and 5% in MATLAB. The thing is, I don’t like programming in any of these languages.

MATLAB is great for working on quick image processing tasks and big matrix operations. I used it quite a lot for a couple classes, and for some early prototyping of neural network designs. However, it would be far too slow for the video-oriented tasks I work on.

Python is… a language I loathe, to put it bluntly. While it’s great for rapid prototyping, data science, and machine learning, it’s only fast when Python code isn’t running. That is, you have to call on all sorts of packages which use underlying C code in order to achieve serious performance. That feels wrong to me, and it makes debugging a nightmare. I generally only use Python for machine learning programs with PyTorch, or for quick data transformation tasks.

C++ is fast, but it can be a nightmare to program in. You’re exposed to all sorts of memory bugs that can hide out for months and be extremely difficult to track down. Using #include statements is a nightmare without a package manager, especially when moving between machines with different library versions installed. CMake makes this a bit better, but getting that to work reliably is also a pain. The language is frustrating to write in, and it often got in the way of me making progress on my work.

My favorite language I’ve ever used is Elixir, a functional language for back-end systems designed for massive concurrency and resiliency. Unfortunately, Elixir is ill-suited to my research, so I haven’t touched it in a few years.

Enter Rust

A few months ago, I got fed up with C++. I wanted a change. I wanted to enjoy programming again, and feel empowered to work on the research itself, rather than have to spend so much time chasing down bugs and optimizations. A colleague of mine had badgered me about a language called Rust for upwards of a year, so I decided to check it out. My wife had a weekend shift at her work, so I was working through the weekend, too. I started reading the Rust Book on a Saturday morning.

I quickly learned that Rust can be as performant as C code, while providing some seriously impressive guarantees about memory safety through a borrow checker. Every piece of data has an owner, and there can only be one mutable reference to a value at time. This makes concurrency much safer, since the compiler strictly enforces these rules. Parallelizing a piece of code can be much more difficult in some cases than in C++, sometimes requiring clever organizations of struct members, but it’s a worthwhile tradeoff for the memory guarantees. I’d rather spend my time writing safe code than debugging unsafe code. Furthermore, it has a simple, modern package manager provide by the Cargo system.

By Monday morning, two days after starting to read the documentation, I had rewritten the bulk of my exisiting code base for asynchronous camera emulation entirely in Rust. It was that easy. The kicker? It was already faster than my C++/CUDA implementation. Upon having that realization, I was converted. For the last couple of months since then, I’ve done all my further development in Rust, and worked to further optimize it as I learn new features of the language and discover helpful packages. Admittedly, there are some things that continue to cause me headaches (maybe I’ll write about them later), but all in all this has made my work life much more enjoyable. I hope to release my new Rust codebase sometime this summer, once I get it packaged more nicely.

Provisioning a Fresh Ubuntu Installation with Bash

2021-07-19T00:00:00+00:00

Last year I started keeping track of the packages I was installing, anticipating a time where I would need to start afresh with a clean Ubuntu installation. I have a running list of installation commands in a bash file which I can run all at once, without having to think about it. This worked marvelously during my OpenCV fiasco last week, allowing me to get everything back the way I liked it with minimal effort on my part.

Here’s the repository, in case you’re interested. I target Ubuntu 20.04 LTS, since that’s what I’m using for the forseeable future, but you can adapt to suit your distro. MATLAB still requires manual installation, and I have to manually enable my GNOME extensions to make the desktop more space-efficient (I use Dash to Panel, and have my settings backed up in a config file on the repo). In the future I also want to be able to automatically set my custom keyboard shortcuts and configure my IDEs and code editors. But all in all, I’ve found it to be a pretty good solution for me. I can get a new system looking and behaving just the way I want it to, with all my desired programs ready to go, with just a few clicks and some waiting around.

Ruining a Linux Installation with OpenCV

2021-07-17T00:00:00+00:00

OpenCV is a behemoth of a library. It’s really useful, but my goodness is it a pain to work with sometimes.

This week I was trying to compile OpenCV to be able to get faster optical flow performance with CUDA. I needed to recompile OpenCV with the CUDA flags enabled. I also needed FFMPEG support to process full videos. I had upgraded my FFMPEG a few weeks ago to version 4.4, because it was hard resetting my machine every time I tried to rescale a video (the CPU would quickly hit 100% and then crash). But apparently the latest FFMPEG update broke the OpenCV bindings. Fine, I’ll downgrade FFMPEG for now and find a workaround or have another version in a container, I said. I also needed CuDNN, but I’m not sure how much that contributed to my problem.

Anyway, everything broke. I started getting all sorts of CUDA build errors, so I tried upgrading to CUDA 11.4. I tried different Nvidia drivers. I tried building older, better tested versions of OpenCV but that led to a myriad of errors related to the FFMPEG codecs not being available or having improper function definitions even though they were installed and working correctly. I spent three days straight trying to fix it before giving up. OpenCV was irrevocably broken, and I was tired of it. I think somewhere along the line I tried “installing” my OpenCV build with make install, and that can apparently cause issues with updating system packages.

I tried getting my programs running on Windows, and I got very close but abandoned that for now. OpenCV and CUDA are even more difficult to work with in a CMake application on Windows. I don’t want to use a full Visual Studio solution because 1) Visual Studio is bloated and I don’t like it, and 2) having cross-platform code is unimportant when there’s only one person working on it and using it right now (me). So I threw my hands up and decided to wipe the slate clean with a fresh Ubuntu install.

And that worked great. Perfectly. My program runs again, on the latest version of OpenCV, compiled with CUDA, and I can continue doing the work that matters. It’s just frustrating to me that OpenCV isn’t more modular and user-friendly. It’s so easy to break! While I’m ranting, there’s an undue amount of effort put into the Python documentation, considering the library is written in C/C++. The C++ docs are terrible and most of the example code is horribly outdated. The library is way too big, and I should be able to more easily add/drop modules as I wish without having to recompile the whole thing. It’s so large that it’s impractical to containerize on a personal machine with limited storage. It’s amazing and powerful when it works, but when it doesn’t… I want to rip my hair out.

C++ Raw Pointer vs. Smart Pointer Performance with 1 Million Linked Lists

2020-07-10T00:00:00+00:00

In my research work, I need to maintain about 1,000,000 linked lists, with each growing to about 100 nodes and frequently deleting the head. These lists initially populate by reading in data from a file in a matter of seconds, and I’m aiming for <1 millisecond performance to add one new node to all the lists. Each node occupies 29 bytes of storage, including the pointer to the next node. That’s 2.7 GB of data that needs to be processed and managed with minimal overhead. At this scale and with the particular target application, every nanosecond counts.

The conventional wisdom for this problem would be to use smart pointers to manage the node references, especially since the nodes themselves must contain the pointers and the nodes are deleted by a function from a different class. unique_ptrs are the fastest, with the CPP docs saying they offer “little to no overhead over built-in pointers (depending on the deleter used).” So I took their word for it and used unique_ptr references in my nodes with the default deleter. But the performance was awful. Truly bad.

I set up the following test to verify that the use of smart pointers was the culprit, making sure to allocate and populate the memory realistically, as well as test deleting and reinitializing data. Here’s the code to test raw pointer performance:

#include <iostream>
using std::cerr;
using std::cout;
using std::endl;
using std::ostream;

#include <chrono> 
using namespace std::chrono; 
  
#include <array>
#include <cstdint>

class Node
{
private:
    Node *next;
    double d1;
    double d2;
    double d3;

public:
    Node();
    Node(double d1, double d2, double d3);
    Node *getNext();

    void addNext(int count);
};

static int arr_size = 1000000;
static int list_size = 100;

Node::Node()
{
    next = nullptr;
}
Node *Node::getNext()
{
    return next;
}

Node::Node(double d1, double d2, double d3) : d1(d1), d2(d2), d3(d3)
{

    next = nullptr;
}

void Node::addNext(int count)
{
    if (count < list_size)
    {
        next = new Node(d1, d2, d3);
        next->addNext(++count);
    }
}

Node *deleteTest(Node *head)
{
    Node *old_head = head;
    head = head->getNext();
    delete old_head;
    return head;
}

int main(int argc, char *argv[])
{
    auto start = high_resolution_clock::now(); 
    Node **nodes = new Node *[arr_size];
    for (int i = 0; i < arr_size; i++)
    {
        nodes[i] = new Node(1, 2, 3);
        nodes[i]->addNext(0);
    }

     for (int j = 0; j < arr_size; j++)
    {
        for (int i = 0; i < list_size; i++)
        {
            nodes[j] = deleteTest(nodes[j]);
        }
        delete nodes[j];
    }

    for (int i = 0; i < arr_size; i++)
    {
        nodes[i] = new Node(1, 2, 3);
        nodes[i]->addNext(0);
    }

     for (int j = 0; j < arr_size; j++)
    {
        for (int i = 0; i < list_size; i++)
        {
            nodes[j] = deleteTest(nodes[j]);
        }
        delete nodes[j];
    }

    delete [] nodes;
    
    auto stop = high_resolution_clock::now(); 
    cout << "Finished in " << duration_cast<milliseconds>(stop-start).count() << " milliseconds" << endl;
}

And here’s the code to test unique_ptr performance:

#include <iostream>
using std::cerr;
using std::cout;
using std::endl;
#include <chrono> 
using namespace std::chrono; 

#include <iomanip>
#include <array>
#include <cstdint>

class Node
{
private:
    std::unique_ptr<Node> next;
    double d1;
    double d2;
    double d3;

public:
    Node();
    Node(double d1, double d2, double d3);
    std::unique_ptr<Node> getNext();

    void addNext(int count);
};

static int arr_size = 1000000;
static int list_size = 100;

Node::Node()
{
    next = nullptr;
}
std::unique_ptr<Node> Node::getNext()
{
    return std::move(next);
}

Node::Node(double d1, double d2, double d3) : d1(d1), d2(d2), d3(d3)
{

    next = nullptr;
}

void Node::addNext(int count)
{
    if (count < list_size)
    {
        next = std::make_unique<Node>(d1, d2, d3);
        next->addNext(++count);
    }
}

std::unique_ptr<Node> deleteTest(std::unique_ptr<Node> head)
{
    std::unique_ptr<Node> old_head;
    head.swap(old_head);
    head = old_head.get()->getNext();
    old_head.reset();
    return head;
}

int main(int argc, char *argv[])
{
    auto start = high_resolution_clock::now(); 
    std::unique_ptr<Node> *nodes = new std::unique_ptr<Node>[arr_size];
    for (int i = 0; i < arr_size; i++)
    {
        nodes[i] = std::make_unique<Node>(1, 2, 3);
        nodes[i]->addNext(0);
    }
    for (int j = 0; j < arr_size; j++)
    {
        for (int i = 0; i < list_size; i++)
        {
            nodes[j] = deleteTest(std::move(nodes[j]));
        }
        nodes[j].reset();
    }

    for (int i = 0; i < arr_size; i++)
    {
        nodes[i] = std::make_unique<Node>(1, 2, 3);
        nodes[i]->addNext(0);
    }
    for (int j = 0; j < arr_size; j++)
    {
        for (int i = 0; i < list_size; i++)
        {
            nodes[j] = deleteTest(std::move(nodes[j]));
        }
        nodes[j].reset();
    }    
    delete [] nodes;
    
    auto stop = high_resolution_clock::now(); 
    cout << "Finished in " 
         << duration_cast<milliseconds>(stop-start).count() 
         << " milliseconds" << endl;
}

Here were my results from running the programs in a terminal:

The raw pointers performed about 6% better than the unique_ptrs on my machine. This may not seem like a huge difference, but as I said above it really adds up noticeably over the program lifecyle. Things get particularly bad, however, when I’m tyring to debug the code.

Debugging in Visual Studio Code I achieve only a minor slowdown with the raw pointers over their straight execution:

Meanwhile the use of unique_ptrs caused a 24X slowdown when debugging:

With my approach to development, such a slowdown is intolerable. At this stage in my project, I often need to debug and step through large chunks of my code in the middle of execution (after several GB of data have been processed). So I’ll gladly take the higher risk of using raw pointers over the severe debugging bottleneck of smart pointers, in this case.

Emulating Clock Tick for Parallelized Event Generation

2020-06-23T00:00:00+00:00

For my current research project, I’m developing an asynchronous camera emulator that reads in Blender-rendered frames and outputs a stream of event data. Each pixel of the simulated sensor can output multiple events over each reference interval (the exposure time of each input frame), and each pixel may change the light sensitivity of other pixels around it (which in turn affects when those pixels will fire their next events).

The details of this particular program aren’t important to understand, but they led me to the following issue.

How can I ensure the emulated pixels are accurately affecting each other at the right points in time? And how can I parallelize it to run faster?

Working under the necessary assumption that the rate of light integration is constant for a given input image, I needed to divide up the light data to my emulated pixels and deliver it, piece by piece, in a time-ordered manner. The delivery of this data must be sequentially accurate. The solution I came up with was to have a TEMPORAL_ACCURACY parameter which may be chosen at runtime. This variable essentially determines the number of timeslices we divide the reference interval into, and we divide each input image’s data into as many pieces. This data is integrated sequentially in each pixel. At this step I was able to parallelize the integration, since the pixels only affect each other’s sensitivities for the next timeslice, and the threads synchronize at the end of each timeslice.

Here’s the relevant C++ snippet using OpenMP to parallelize:

double ref_time = (frame_length / TEMPORAL_ACCURACY);
for (int timeframe = 0; timeframe < TEMPORAL_ACCURACY; timeframe += 1)
{
	int x, y;
#pragma omp parallel for private(y) schedule(dynamic)
	for (y = 0; y < image.height(); y++)
	{
#pragma omp parallel for private(x) schedule(dynamic)
		for (x = 0; x < image.width(); x++)
		{
			double *bw = image.data(x, y, 0, 0); // get grayscale pixel intensity
			pixels[y][x].integrate((*bw / TEMPORAL_ACCURACY), ref_time);
		}
	}
}

The TEMPORAL_ACCURACY, therefore, is a sliding scale directly proportional to the accuracy of the emulation, but inversely proportional to the speed of the emulation. If TEMPORAL_ACCURACY = frame_length, then we have a perfect 1:1 emulated clock tick and perfectly accurate results. frame_length is measured in nanoseconds, however, so the necessary tradeoff is to sacrifice some accuracy for higher speed. I have found satisfactory results for a frame_length of 10000000 when using a TEMPORAL_ACCURACY of 100, such that each timeslice represents the passage of 100000 clock ticks.

With a somewhat low-resolution (but realistic for the camera in question) emulated sensor of 360x240, I can achieve nearly real-time emulation speeds even with a complex sensitivity adjustment scheme. This means that the computation and output of events generated from a given input image takes roughly the same amount of time as the input frame’s exposure. The bottleneck here seems to actually be slow write performance of my NVME SSD, since all the events are written directly to disk.

I’m not in a position to share the full code of this project at this time, but I can give you more details or answer any questions if you e-mail me. I should have a paper proposal ready in the next month or two, if you’re interested.