Hacker News Reader

Comment by r_smart | Hacker News Reader

In general, the consideration for bit fields is that your program will run slower but consume less memory. It's usually my opinion that we want to run as fast as possible while not running out of memory, so I'd say in general bit fields are less performant. If you can afford the memory, using a whole word for booleans will yield the fastest results, but will obviously consume way more memory.

I'm a fan of state machines, but I don't think they're necessarily more performant. There's nothing about them that keeps you from doing anything crazy that will bog your program down, but I find them easy to reason about. I think they're a stylistic thing, and the only real advantage I can think of is in maybe helping the design of the program. Having to define your states and how you will move between them is usually a good idea.

View on HN

Re: State Machines

I'm neutral about state machines. Obviously in things like microcontrollers and HDL, state machines are really necessary. Outside of those two examples, state machines can either make code much more stable or just add unnecessary overhead with all the wasted cycles. They definitely have their place but there are better options available sometimes like threading a process. I had a project recently where we needed to build a custom message broker. A teammate wrote the entire thing in python as one big state machine. Everytime we needed to add another queue, it involved adding so much extra code to handle it. Another teammate suggested just having everything threaded so we reduce our code down to a template queue and can dynamically create them as needed. The state machine might have been more efficient memory-wise if we were doing it all in C on a PIC or more conservative in PLU usage if it was an FPGA but we were using python on a raspberry pi. We ended up with a broker that could handle more bandwidth in terms of how many queues we could publish to and consume from.

Obviously we didn't really shrug off state machines. We just created many smaller ones (two states: wait for message, push message) rather than a huge one. I think the massive state machines we learn about in our freshman classes are unnecessary in many cases. Memory is so cheap that its not always worth it to be so conservative/old school.

We could have just used something like rabbitmq but we didn't want the extra overhead of a service like that when we had so much more resource heavy stuff running on the pi.

Yeah, it sounds like you guys clearly made the right move in changing that. I am also neutral about state machines. Some times I run into one and I love it, other times, it just seems terrible. One of the projects at work has a state machine that's like ~2k lines of code. It's a monster, and it's a nightmare to modify. It's also got sub state machines nested in it, so the opportunities for fun are pretty much endless.

Personally I'm a fan of the smaller state machines you describe. You still got to deal with synchronizing them, but it just seems easier to grasp for me.

Bluespec actually has a little sublanguage for writing state machines as control flow programs.

Essentially since Bluespec's model is a set of conditional transactions on your state, you can write an imperative sequence of transactions with a few basic flow control primitives (if-else blocks, while loops etc.), and it creates the state logic automatically.

Unfortunately it didn't seem to have received much attention, and I ran into quite a few problems when I tried to use it for anything serious (including one straight up behavioural bug).

With regards to state machines , there's the idea of "hierarchical state machines" which basically add hierarchy and abstraction to state machines - and they are used in some safety-critical systems and supposed to greatly help with bug prevention.

Interesting, I've never heard of that (though I may just know it by another name). I'll have to look it up!

Variants on that are also called Abstract State Machines (ASM's), Interacting State Machines, and Composable State Machines. Those terms have most hits on Google.

Are bit fields slower (at least in C)? It's a matter of load-constant mask-compare, as opposed to load-compare; I imagine it's a matter of one additional instruction per load statement, and this instruction also happens to be very fast.

Reply on news.ycombinator.com