Language Selection

English French German Italian Portuguese Spanish

Ode to Machine Architecture

Filed under

I have been writing lately about the importance of learning the underlying tenants of computing if you are going to be a great programmer, and in particular some machine language and computer architecture.

It typically does not make a difference which architecture you learn, or which machine language, as long as the architecture and machine language can illustrate the basic concepts of computing to a level that is useful in future studies of operating systems design and compiler theory, helping you to under stand issues like cache management, interrupt handling and I/O.

This blog entry, however, is not going to talk about those issues. Instead it will talk about a few instances in my life where knowing assembly language helped me immensely in solving problems.

rest here

Architecture Does Matter

People seemed to like my blog yesterday about how the knowledge of assembly and machine language improved my programs, or the programs of people around me.

Today I would like to show people how simply understanding a little about the architecture of the machine and operating system, even without knowing assembly language, can improve program performance. Likewise the study of algorithms and computer techniques.

rest here

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

7 tools for analyzing performance in Linux with bcc/BPF

A new technology has arrived in Linux that can provide sysadmins and developers with a large number of new tools and dashboards for performance analysis and troubleshooting. It's called the enhanced Berkeley Packet Filter (eBPF, or just BPF), although these enhancements weren't developed in Berkeley, they operate on much more than just packets, and they do much more than just filtering. I'll discuss one way to use BPF on the Fedora and Red Hat family of Linux distributions, demonstrating on Fedora 26. BPF can run user-defined sandboxed programs in the kernel to add new custom capabilities instantly. It's like adding superpowers to Linux, on demand. Examples of what you can use it for include: Read more

Why the open source community needs a diverse supply chain

Diversity and inclusivity in the technology industry—and in open source communities more specifically—have received a lot of coverage, both on and elsewhere. One approach to the issue foregrounds arguments about concepts that are more abstract—like human decency, for example. But the "supply chain" metaphor works, too. And it can be an effective argument for championing greater inclusivity in our open organizations, especially when people dismiss arguments based on appeals to abstract concepts. Open organizations require inclusivity, which is a necessary input to get the diversity that reduces the risk in our supply chain. Read more

Red Hat: Kerala, Amazon and More

Programming: Swift, Brilliant Jerks in Engineering, and Career Path for Software Developers

  • Swift code will run on Google's Fuchsia OS
    A few days ago, there was a flash-in-the-pan controversy over Google "forking" Apple's open-source programming language Swift. After a few minutes of speculation over whether Google was going to make its own special flavor of the language for its own purposes, Swift's creator Chris Lattner (who now works at Google) helpfully clarified the situation:
  • Brilliant Jerks in Engineering
    This are numerous articles and opinions on the topic, including Brilliant Jerks Cost More Than They Are Worth, and It's Better to Avoid a Toxic Employee than Hire a Superstar. My colleague Justin Becker is also giving a talk at QConSF 2017 on the topic: Am I a Brilliant Jerk?. It may help to clarify that "brilliant jerk" can mean different things to different people. To illustrate, I'll describe two types of brilliant jerks: the selfless and the selfish, and their behavior in detail. I'll then describe the damage caused by these jerks, and ways to deal with them. The following are fictional characters. These are not two actual engineers, but are collections of related traits to help examine this behavior beyond the simple "no asshole rule." These are engineers who by default act like jerks, not engineers who sometimes act that way.
  • [Older] The missing career path for software developers
    You started hacking on technology thrilled with every stroke of the key, making discoveries with every commit. You went about solving problems, finding new challenges. You were happy for a while, until you hit a plateau. There was a choice to be made. Continue solving the same problems or start managing others. You tried it out, and hated it. Longing to focus on technology, not people, you turned to your open source project. When it became successful, you became an open source maintainer but ended up overwhelmed and burned out. Hoping to get back to doing work that fascinates you, you went work for yourself. Lacking experience running a business, you're crushed with all the decisions you need to make. You’re nearing burnout — again. It feels like you’re on a hamster wheel.