4 ms·

“Software is not limited by physics like buildings are.” is dead wrong. Information transfer is bound by the speed of light. We are light architects, and L1 cac

by crb002 6y ago

“Software is not limited by physics like buildings are.” is dead wrong. Information transfer is bound by the speed of light. We are light architects, and L1 cache vs a remote call to a server hundreds of miles away matters. The architect’s role is to design for data flow and compose functionality so it can be swapped out. Great new book on that: https://www.amazon.com/dp/0136524036/ref=cm_sw_r_tw_dp_U_x_ub67EbR1M89AG https://www.amazon.com/dp/0136524036/ref=cm_sw_r_tw_dp_U_x_u...

bluGill 6y ago
Maybe, maybe not. I am architect on a system that gets by on 16 but cpus with no cache. Or we did until they went out of production, I'm hired to duplicate what was working on something more modern (32 bit) . I don't worry about l1 cache because no matter how bad I am to the cache I know the code used to work on a cpu much slower. Of course that is just one of my domains. I have other systems that are pushing bounds of what 64 bit systems can do, and there I'm more worried about how can I avoid synchronizing the cache between the cores without a race condition. I don't have to worry about the servers hundreds of miles away though, that is a different architect.
opmac 6y ago
Hardware is defined by physics. I can write code that is logically the same no matter what hardware it's running on. Of course, some software has to take the hardware it is intended to run on into account, but this is not a fundamental property of software as a whole.
deleted 6y ago
[deleted]
lowbloodsugar 6y ago
Agree. For some it's L1 vs DRAM latency. For others it's entropy (memory management, eventual consistency, GC).
Jtsummers 6y ago
Taken to its limit, you are not entirely wrong. But, practically speaking, the bounds are much higher in software than in physical construction. The limits of physics, with respect to, software determine more its performance limits rather than its logical limits. Setting aside performance (which is important), I can make a complex piece of software with 1000 modules each directly connected to the other. A building is not capable of a similar degree of direct connectedness. There may be critical components, your keystones, but each brick is only attached to each neighboring brick. Outside of the critical components you can remove (up to a limit) and replace many components in place without bringing the entire structure down, and often without local damage. And replacing a damaged brick in place requires rejoining with only those immediately around it. Good software is written in a similar fashion, but software itself is not bound by the physical limits that force that fashion (until you start considering performance, which will encourage better design but only when it hits a particular pain point, or if dealing with a global network of computers).
deleted 6y ago
[deleted]

by crb002 6y ago

bluGill 6y ago

Maybe, maybe not. I am architect on a system that gets by on 16 but cpus with no cache. Or we did until they went out of production, I'm hired to duplicate what was working on something more modern (32 bit) . I don't worry about l1 cache because no matter how bad I am to the cache I know the code used to work on a cpu much slower. Of course that is just one of my domains. I have other systems that are pushing bounds of what 64 bit systems can do, and there I'm more worried about how can I avoid synchronizing the cache between the cores without a race condition. I don't have to worry about the servers hundreds of miles away though, that is a different architect.

opmac 6y ago

Hardware is defined by physics. I can write code that is logically the same no matter what hardware it's running on. Of course, some software has to take the hardware it is intended to run on into account, but this is not a fundamental property of software as a whole.

deleted 6y ago

[deleted]

lowbloodsugar 6y ago

Agree. For some it's L1 vs DRAM latency. For others it's entropy (memory management, eventual consistency, GC).

Jtsummers 6y ago

Taken to its limit, you are not entirely wrong. But, practically speaking, the bounds are much higher in software than in physical construction. The limits of physics, with respect to, software determine more its performance limits rather than its logical limits. Setting aside performance (which is important), I can make a complex piece of software with 1000 modules each directly connected to the other. A building is not capable of a similar degree of direct connectedness. There may be critical components, your keystones, but each brick is only attached to each neighboring brick. Outside of the critical components you can remove (up to a limit) and replace many components in place without bringing the entire structure down, and often without local damage. And replacing a damaged brick in place requires rejoining with only those immediately around it. Good software is written in a similar fashion, but software itself is not bound by the physical limits that force that fashion (until you start considering performance, which will encourage better design but only when it hits a particular pain point, or if dealing with a global network of computers).

deleted 6y ago

[deleted]