• 1 Post
  • 23 Comments
Joined 2 years ago
cake
Cake day: June 17th, 2023

help-circle









  • My hot take is that unmaintainable monoliths result from poor system design / too strong coupling. If you can’t cleave off portions of your monolith without breaking it you built it wrong in the first place, and the choice between monolith and microservice isn’t going to save you. Perhaps starting with a microservice forces people to make (or at least consider) better design choices from the beginning but 1. there is no reason you can’t make those same architectural decisions with a monolith and 2. you can still strongly couple microservices with poor design.

    Getting back to basics of “what makes for good application development” using good abstractions, Go4 patterns, SOLID / KISS / DRY / etc, means that whether your threads are running colocated vs on another VM vs on another box vs in another datacenter vs in another continent shouldn’t affect you much. If your app breaks in ways beyond “I wonder if moving this job to another system means we’ll suffer from memory nonlocality or sync latency” the walls are already closing in lol.


  • Never seen so much truth in one article. 90% of applications would be fine as small VMs running monoliths. Dev time is an expensive resource compared to VMs and the simplicity promised just isn’t there. And having tech companies that run the major cloud platforms also be the software evangelists that herald “the new best way” of doing development was always a conflict of interest.

    That being said, FaaS is nonetheless a useful tool in the toolbelt for the odd app that does actually need crazy scale to 1000000 scale back to 0, or for certain kinds of simple apps. Traditional app development still rules the middle space when it comes to team productivity.


  • The changes:

    Intel® APX doubles the number of general-purpose registers (GPRs) from 16 to 32. This allows the compiler to keep more values in registers; as a result, APX-compiled code contains 10% fewer loads and more than 20% fewer stores than the same code compiled for an Intel® 64 baseline.2 Register accesses are not only faster, but they also consume significantly less dynamic power than complex load and store operations.

    Intel® APX adds conditional forms of load, store, and compare/test instructions, and it also adds an option for the compiler to suppress the status flags writes of common instructions. These enhancements expand the applicability of if-conversion to much larger code regions, cutting down on the number of branches that may incur misprediction penalties. All these conditional ISA improvements are implemented via EVEX prefix extensions of existing legacy instructions.