Raaaaaammmbling
Apr. 22nd, 2009 04:31 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
garoteI have decided that this late half-hour shall be for spewing out my uncomposed thoughts. Here goes.
- - -
I have too much bicycle crud crammed into too small of a space. The armoire by the front door can't contain it all. It's also not quite enough. Several boxes are due to arrive in the mail, with additional gear.
I didn't expect to become a gearhead from this, but it's happened anyway. I know too much about chains and sprockets and headsets and downtubes now. It's aggravating, because before this started, all I saw when I looked at my bicycle was a bicycle. Two wheels and a seat. Now it's four-score components and an unfinished construction site.
The last step of the rechargeable USB device is vexing me. I need to design an enclosure, but the design is wedged between decisions about wiring, connectors, and weatherproofing. So far it's just a box with three subdivisions measured out, spinning around in Solidworks on the computer screen. More time spent in front of the screen - yeech. I'd rather be out riding,... but with a completed box. Catch-22.
Too many small things need to be done. A while ago I purchased some project organizer software for the iPhone, and moved all my notes into it. The bicycle section has eight separate lists, with over a hundred items. One list is an inventory of everything I would pack on the bike for a long trip. (I'm still missing five or six items.) Another list is all the modifications I want to make to the bike itself, plus the parts required. I need to raise the handlebars. I need to swap out the rear cogset for better hill climbing. I need new brake pads...
It's become an eternal project. And that's okay if you have infinite time, but I'm really feeling the pinch, even with over two months left.
It doesn't help that I've been putting in extra hours at work recently, to push through a set of test system changes that are blocking other projects. I enjoy the sense of accomplishment I feel when the system performs a new trick and the other engineers thank me, but long hours in front of the screen is bad for my health.
An amusing thought has been pinging around in my head recently: Programmers earn good money by putting themselves in a meditative state of mind that is both isolated and crowded, much the same way that a student in an ashram may visualize a mandala, attempting to comprehend the whole of the design all at once. The programmer is drawing the mandala as she goes, attempting to follow complicated, unbreakable rules, and is trained specifically to describe the mandala with a linear, symbolic language, similar to speech but with a grammar that is sometimes bizarre. Even languages that seem to violate the linearity of speech - like Flash with its timeline, or Javascript with its horrendous closures and event cascades - is still ultimately expressed as linear progressions through the grammar of a logic tree constructed from unbreakable rules. Mathematically sound, from the bottom up.
But then we get into multi-threaded programming.
When you write code that spawns several threads, you are creating autonomous entities which will then be interacting in some way. At the simplest level, this is like walking and chewing gum at the same time. One thread walks, one thread chews the gum, and they share the limbs and the jaw and the nervous system politely and all is well. The reason it's simple is because walking and chewing gum are simple tasks that are well understood. There are only a few ways they interact. What could go wrong? If you trip you might accidentally swallow your gum, and if you spit out your gum you may step on it. No big deal.
But what if you were writing code that did the equivalent of cooking a thai-style yellow curry, and two dozen cinnamon rolls, simultaneously, in the same kitchen? You'd need a thread to watch the boiling water, a thread to cut the potatoes, a thread to sift the flour, a thread to chop the onions, a thread to mix the cinnamon glaze ... all fighting for use of the countertop, the stove, the oven, the cutting board, the knives...
By visualizing the entire process in your head, you can come up with sets of rules to describe how the threads must interact, to avoid burning down the kitchen. Most of the time a programmer will take a brute-force approach, first attempting to bake a curry and some cinnamon rolls in a completely linear way, one step at a time, and then compressing their solution at various points experimentally, seeing which steps can be reliably run in parallel, according to the recipe and the kitchen itself. At some point the variety of interacting threads to choose from becomes overwhelming, and the programmer begins to profile different mixtures of threads doing larger or smaller tasks, trying to find the approach that saves the most time, most of the time.
But you can kind of tell - this isn't like a mandala. The structure you're making here is in constant motion, and the rules you use to describe it are subject to change. When you're cooking two dishes in parallel, and both require use of the stovetop, and the curry could need anywhere from one to four burners on the stove depending entirely on how you decide to cook it ... your rules are whatever you make them. Do you spawn a stovetop-tracking thread? Or one thread per burner, each with a task queue, and let them interact? Or do you call them devices, declare a series of locks, and make "use the stove" threads that spin waiting for a burner to unlock? Do you let them kick their peers off the stove, if it's a particularly time-critical task, like waiting for the potatoes to get just cooked enough so you can dump them in with the sauce? Or do you account for that contingency by making it impossible to spawn more than three stovetop threads at a time until you absolutely need that fourth burner for the sauce?
The rules could be anything, because there is no One True Way to approach the problem, and because threads don't always behave according to the rules anyway. Sometimes they get squished by the system, or caught in time warps, or stay mysteriously silent when you signal them. And these bugs only come out at night. In the late hours of testing, or in the wild. Now that I think of it, it's less like drawing a mandala, and more like trying to populate an imaginary aquarium with mentally unbalanced carnivorous fish.
Oh hell; what was I talking about? Bicycles I think?
Yeah, that's what's on my mind a lot these days. Spirituality, programming, and bicycling. It's hard to imagine that just about 15 months ago, my bike was just another neglected piece of luggage parked in the spare room. Two wheels and a seat, that's all I saw. Now I'm taking it waaaay out into the boonies and planning crazy cross-state trips with it. Sometimes, partway up a 3000 foot hill, I ask myself: "Why am I doing this?" Mostly I just like the combination of the open road, and the remarkable feeling of self-containment I derive from having food, water, and electronic interconnectedness right at hand in the middle of nowhere. (Not that it's really the middle of nowhere when you still get a cell signal. But, I've been there too. And it's also nice.)
Also I've been having disturbing dreams about my time at UCSC, and some of the girls I knew there. Perhaps it's the heat. Or all the discussions I've been having about school lately.
- - -
I have too much bicycle crud crammed into too small of a space. The armoire by the front door can't contain it all. It's also not quite enough. Several boxes are due to arrive in the mail, with additional gear.
I didn't expect to become a gearhead from this, but it's happened anyway. I know too much about chains and sprockets and headsets and downtubes now. It's aggravating, because before this started, all I saw when I looked at my bicycle was a bicycle. Two wheels and a seat. Now it's four-score components and an unfinished construction site.
The last step of the rechargeable USB device is vexing me. I need to design an enclosure, but the design is wedged between decisions about wiring, connectors, and weatherproofing. So far it's just a box with three subdivisions measured out, spinning around in Solidworks on the computer screen. More time spent in front of the screen - yeech. I'd rather be out riding,... but with a completed box. Catch-22.
Too many small things need to be done. A while ago I purchased some project organizer software for the iPhone, and moved all my notes into it. The bicycle section has eight separate lists, with over a hundred items. One list is an inventory of everything I would pack on the bike for a long trip. (I'm still missing five or six items.) Another list is all the modifications I want to make to the bike itself, plus the parts required. I need to raise the handlebars. I need to swap out the rear cogset for better hill climbing. I need new brake pads...
It's become an eternal project. And that's okay if you have infinite time, but I'm really feeling the pinch, even with over two months left.
It doesn't help that I've been putting in extra hours at work recently, to push through a set of test system changes that are blocking other projects. I enjoy the sense of accomplishment I feel when the system performs a new trick and the other engineers thank me, but long hours in front of the screen is bad for my health.
An amusing thought has been pinging around in my head recently: Programmers earn good money by putting themselves in a meditative state of mind that is both isolated and crowded, much the same way that a student in an ashram may visualize a mandala, attempting to comprehend the whole of the design all at once. The programmer is drawing the mandala as she goes, attempting to follow complicated, unbreakable rules, and is trained specifically to describe the mandala with a linear, symbolic language, similar to speech but with a grammar that is sometimes bizarre. Even languages that seem to violate the linearity of speech - like Flash with its timeline, or Javascript with its horrendous closures and event cascades - is still ultimately expressed as linear progressions through the grammar of a logic tree constructed from unbreakable rules. Mathematically sound, from the bottom up.
But then we get into multi-threaded programming.
When you write code that spawns several threads, you are creating autonomous entities which will then be interacting in some way. At the simplest level, this is like walking and chewing gum at the same time. One thread walks, one thread chews the gum, and they share the limbs and the jaw and the nervous system politely and all is well. The reason it's simple is because walking and chewing gum are simple tasks that are well understood. There are only a few ways they interact. What could go wrong? If you trip you might accidentally swallow your gum, and if you spit out your gum you may step on it. No big deal.
But what if you were writing code that did the equivalent of cooking a thai-style yellow curry, and two dozen cinnamon rolls, simultaneously, in the same kitchen? You'd need a thread to watch the boiling water, a thread to cut the potatoes, a thread to sift the flour, a thread to chop the onions, a thread to mix the cinnamon glaze ... all fighting for use of the countertop, the stove, the oven, the cutting board, the knives...
By visualizing the entire process in your head, you can come up with sets of rules to describe how the threads must interact, to avoid burning down the kitchen. Most of the time a programmer will take a brute-force approach, first attempting to bake a curry and some cinnamon rolls in a completely linear way, one step at a time, and then compressing their solution at various points experimentally, seeing which steps can be reliably run in parallel, according to the recipe and the kitchen itself. At some point the variety of interacting threads to choose from becomes overwhelming, and the programmer begins to profile different mixtures of threads doing larger or smaller tasks, trying to find the approach that saves the most time, most of the time.
But you can kind of tell - this isn't like a mandala. The structure you're making here is in constant motion, and the rules you use to describe it are subject to change. When you're cooking two dishes in parallel, and both require use of the stovetop, and the curry could need anywhere from one to four burners on the stove depending entirely on how you decide to cook it ... your rules are whatever you make them. Do you spawn a stovetop-tracking thread? Or one thread per burner, each with a task queue, and let them interact? Or do you call them devices, declare a series of locks, and make "use the stove" threads that spin waiting for a burner to unlock? Do you let them kick their peers off the stove, if it's a particularly time-critical task, like waiting for the potatoes to get just cooked enough so you can dump them in with the sauce? Or do you account for that contingency by making it impossible to spawn more than three stovetop threads at a time until you absolutely need that fourth burner for the sauce?
The rules could be anything, because there is no One True Way to approach the problem, and because threads don't always behave according to the rules anyway. Sometimes they get squished by the system, or caught in time warps, or stay mysteriously silent when you signal them. And these bugs only come out at night. In the late hours of testing, or in the wild. Now that I think of it, it's less like drawing a mandala, and more like trying to populate an imaginary aquarium with mentally unbalanced carnivorous fish.
Oh hell; what was I talking about? Bicycles I think?
Yeah, that's what's on my mind a lot these days. Spirituality, programming, and bicycling. It's hard to imagine that just about 15 months ago, my bike was just another neglected piece of luggage parked in the spare room. Two wheels and a seat, that's all I saw. Now I'm taking it waaaay out into the boonies and planning crazy cross-state trips with it. Sometimes, partway up a 3000 foot hill, I ask myself: "Why am I doing this?" Mostly I just like the combination of the open road, and the remarkable feeling of self-containment I derive from having food, water, and electronic interconnectedness right at hand in the middle of nowhere. (Not that it's really the middle of nowhere when you still get a cell signal. But, I've been there too. And it's also nice.)
Also I've been having disturbing dreams about my time at UCSC, and some of the girls I knew there. Perhaps it's the heat. Or all the discussions I've been having about school lately.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
no subject
Date: 2009-04-22 02:19 pm (UTC)no subject
Date: 2009-04-27 09:42 pm (UTC)no subject
Date: 2009-04-27 10:17 pm (UTC)