Simple Tricks To Make Your Python Code Faster

Python has become one of the most popular programming languages out there, particularly for beginners and those new to the hacker/maker world. Unfortunately, while it’s easy to  get something up and running in Python, it’s performance compared to other languages is generally lacking. Often, when starting out, we’re just happy to have our code run successfully. Eventually, though, performance always becomes a priority. When that happens for you, you might like to check out the nifty tips from [Evgenia Verbina] on how to make your Python code faster.

Many of the tricks are simple common sense. For example, it’s useful to avoid creating duplicates of large objects in memory, so altering an object instead of copying it can save a lot of processing time. Another easy win is using the Python math module instead of using the exponent (**) operator since math calls some C code that runs super fast. Others may be unfamiliar to new coders—like the benefits of using sets instead of lists for faster lookups, particularly when it comes to working with larger datasets. These sorts of efficiency gains might be merely useful, or they might be a critical part of making sure your project is actually practical and fit for purpose.

It’s worth looking over the whole list, even if you’re an intermediate coder. You might find some easy wins that drastically improve your code for minimal effort. We’ve explored similar tricks for speeding up code on embedded platforms like Arduino, too. If you’ve got your own nifty Python speed hacks, don’t hesitate to notify the tipsline!

Golang On The PS2

A great many PlayStation 2 games were coded in C++, and there are homebrew SDKs that let you work in C. However, precious little software for the platform was ever created in Golang. [Ricardo] decided this wouldn’t do, and set about making the language work with Sony’s best-selling console of all time. 

Why program a PS2 in Go? Well, it can be easier to work with than some other languages, but also, there’s just value in experimenting in this regard. These days, Go is mostly just used on traditional computery platforms, but [Ricardo] is taking it into new lands with this project.

One of the challenges in getting Go to run on the PS2 is that the language was really built to live under a full operating system, which the PS2 doesn’t really have. However, [Ricardo] got around this by using TinyGo, which is designed for compiling Go on simpler embedded platforms. It basically takes Go code, turns it into an intermediate representation, then compiles binary code suitable for the PS2’s Emotion Engine (which is a MIPS-based CPU).

The specifics of getting it all to work are quite interesting if you fancy challenges like these. [Ricardo] was even able to get to an effective Hello World point and beyond. There’s still lots to do, and no real graphical fun yet, but the project has already passed several key milestones. It recalls us of when we saw Java running on the N64. Meanwhile, if you’re working to get LOLCODE running on the 3DO, don’t hesitate to let us know!

Speeding Up Your Projects With Direct Memory Access

Here’s the thing about coding. When you’re working on embedded projects, it’s quite easy to run into hardware limitations, and quite suddenly, too. You find yourself desperately trying to find a way to speed things up, only… there are no clock cycles to spare. It’s at this point that you might reach for the magic of direct memory access (DMA). [Larry] is here to advocate for its use.

DMA isn’t just for the embedded world; it was once a big deal on computers, too. It’s just rarer these days due to security concerns and all that. Whichever platform you’re on, though, it’s a valuable tool to have in your arsenal. As [Larry] explains, DMA is a great way to move data from memory location to memory location, or from memory to peripherals and back, without involving the CPU. Basically, a special subsystem handles trucking data from A to B while the CPU gets on with whatever other calculations it had to do. It’s often a little more complicated in practice, but that’s what [Larry] takes pleasure in explaining.

Indeed, back before I was a Hackaday writer, I was no stranger to DMA techniques myself—and I got my project published here! I put it to good use in speeding up an LCD library for the Arduino Due. It was the perfect application for DMA—my main code could handle updating the graphics buffer as needed, while the DMA subsystem handled trucking the buffer out to the LCD quicksmart.

If you’re struggling with updating a screen or LED strings, or you need to do something fancy with sound, DMA might just be the ticket. Meanwhile, if you’ve got your own speedy DMA tricks up your sleeve, don’t hesitate to let us know!

Building A Raycaster Within Bash

Wolfenstein 3D was a paradigm-shifting piece of software, using raycasting techniques to create a game with pseudo-3D graphics. Now, [izabera] has done something very similar, creating a raycasting display engine that runs entirely within bash.

The work was developed with an eye cast over an existing raycasting tutorial online. As you might imagine, implementing these graphical techniques in a text console proved difficult. The biggest problem [izabera] encountered was that bash is slow. It’s not supposed to display full frames of moving content at 25+ fps. It’s supposed to display text. Making it display graphics by using tons of colorful characters is really pushing the limits. Bash also doesn’t have any ability to work with floating points, so all the calculations are done with massive integers. Other problems involved the limited ways to read the keyboard in bash, and keeping track of the display as a whole.

It’s neat reading about how this was pulled off—specifically because it was hard. It might not be the kind of project you’d ever implement for serious work, but there are learnings to be had here that you won’t get anywhere else. Code is on Github, while there’s a visual storytelling of how it came together on imgur.

We’ve seen similar work before—with magical 3D graphics generated in Microsoft Excel. Will wonders never cease? We hope not, because we always like to see new ones on the tipsline. Keep us busy!

Blowing Up Shell Scripts

One of the most universal experiences of any Linux or Unix user is working through a guide or handbook and coming across an almost unbelievably complex line of code meant to be executed with a shell. At the time of encountering a snippet like this it’s difficult to imagine any human ever having written it in the first place, but with some dedication it is possible to tease out what these small bits of code do when they’re typed into the terminal and run (unless it’s something like :(){ :|:& };: but that’s another story entirely). [noperator] recently built a tool which helps users in this predicament understand these shell scripts by expanding them into a more human-intelligible form.

The tool is named sol and does much more than expanding shell one-liners into a readable format. It also provides an interactive shell environment where the user can explore the exploded code in detail, modify it in any way they see fit, and collapse it back down to a single line so it can easily be sent to other users. It can be used with most of the major text editors as well as piped directly to standard input, and has a number of other options as well such as custom configurations and the ability to see non-standard bits of code that might not be compatible from one shell environment to another, as well as helping to translate those bits of code.

[noperator] has made the code available in the linked GitHub page for anyone curious about its use, and has a to-do list for future versions of the tool as well including adding support beyond bash. We’d definitely recommend a tool like this especially if you’re still relatively new to bash scripting (or shell scripting in general) and, as always, we’d just to remind everyone not to blindly copy and paste commands into their terminal windows. If you’re the type of person to go out on a limb and run crazy commands to see what they actually do, though, make sure you’re at least logged into the right computer first.

Compiling Four Billion If Statements

With modern tools, you have to try very hard to do something stupid, because the tools (rightly) recognize you’re doing something stupid. [Andreas Karlsson] can speak to that first hand as he tried to get four billion if statements to compile.

You may ask what state space requires four billion comparisons to evaluate? The answer is easy: the range of an unsigned 32-bit integer. The whole endeavor started with a simple idea: what if instead of evaluating whether an integer is even or odd with a modulo or bit mask, you just did an if statement for every case? Small ranges like 0-10 are trivial to write out by hand, but you reach for more automated solutions as you pass 8 bits and move towards 16. [Andreas] wrote some Python that outputs a valid C program with all the comparisons. For 16 bits, the source only clocks in at 130k lines with the executable less than 2 MB.

Of course, scaling to 32 bits is a very different problem. The source file balloons to 330 GB, and most compilers barf at that point. Undeterred, [Andreas] modified the Python to output x86_64 assembly instead of C. Of course, the executable format of Windows (PE) only allows executables up to 4 GB, so a helper program mapped the 40 GB generated executable and jumped into it.

What’s incredible about this whole journey is how performant the program is. Even large numbers complete in a few seconds. Considering that it has to thrash 40 GB of an executable through memory, we can’t help but shake our heads at how even terrible solutions can work. We love seeing someone turn a bad idea into an interesting one, like this desoldering setup.

An Enigma Machine Built In Meccano

As far as model construction sets go, LEGO is by far the most popular brand for building not only pre-planned models but whatever the builder can imagine. There are a few others out there though, some with some interesting features. Meccano (or Erector in North America) is a construction set based around parts that are largely metal including its fasteners, which allows for a different approach to building models than other systems including the easy addition of electricity. [Craig], a member of the London Meccano Club, is demonstrating his model Enigma machine using this system for all of its parts and adding some electricity to make the circuitry work as well.

The original Enigma machine was an electronic cypher used by the German military in World War 2 to send coded messages. For the time, its code was extremely hard to break, and led to the British development of the first programmable electronic digital computer to help decipher its coded messages. This model uses Meccano parts instead to recreate the function of the original machine, with a set of keys similar to a typewriter which, when pressed, advance a set of three wheels. The wheels all have wiring in them, and depending on their initial settings will light up a different character on a display.

There are a few modifications made to the design (besides the use of a completely different set of materials) but one of the main ones was eliminating the heavy leaf springs of the original for smaller and easier-to-manage coil springs, which are also part of the electrical system that creates the code. The final product recreates the original exceptionally faithfully, with plans to create a plugboard up next, and you can take a look at the inner workings of a complete original here.

Continue reading “An Enigma Machine Built In Meccano”