bazizbaziz

Workflows/orchestration/reconciliation-loops are basically table stakes for any service that is solving significant problems for customers. You might think you don't need this, but when you start needing to run async jobs in response to customer requests, you will always eventually implement one of the above solutions.

IMO the next big improvement in this space is improving the authoring experience. In short, when it comes to workflows, we are basically still writing assembly code.

Writing workflows today is done in either a totally separate language (StepFunctions), function-level annotations (Temporal, DBOS, etc), or event/reconciliation loops that read state from the DB/queue. In all cases, devs must manually determine when state should be written back to the persistence layer. This adds a level of complexity most devs aren't used to and shouldn't have to reason about.

Personally, I think the ideal here is writing code in any structure the language supports, and having the language runtime automatically persist program state at appropriate times. The runtime should understand when persistence is needed (i.e. which API calls are idempotent and for how long) and commit the intermediate state accordingly.

One benchmark would be to track down a python/JS/etc based "hello world" demo container. Base one version on Intel and the other on ARM, and measure each versions container build-time and request latency after it is set-up.

If changing the base image is all that's needed and both Dockerfiles otherwise assume ubuntu, this should not take too long.

I use an 2016 Macbook i7/8GB as my daily development system. I love it. It's light and portable, which is important for me.

The main thing to understand about these machines is that the i7 CPUs are about as good as any other CPU on the market (aside from less cores), but they're fanless which means they rely on the case to dissipate heat, and so will thermally throttle during long-running high CPU jobs. They're perfect for short lived jobs, even multi-minute compilations, but will have a hard time getting through repeated long jobs that require long durations of high CPU.In short, great for bursty computations with longer idle times where the laptop has a chance to cool off.

For instance, I build brew packages, full llvm builds, even small ML models, etc, without problems, because the machine starts cold and there is enough time after the job is done for the machine to cool off again. My machine suffers on tasks like Docker+Kubernetes/minikube that run a constantly polling VM in the background that takes 25-100% CPU when running idle.

For instance, someone in this thread mentioned the iOS emulator might be difficult to run. This may not be true, so long as the emulator does not constantly use lots of CPU - if it just uses high CPU in response to input events, it will likely be fine.

> When a value is retrieved via its key, IronDB... > Looks up that key in every store. > Counts each unique, returned value. > Determines the most commonly returned value as the 'correct' value. > Returns this most common correct value > Then IronDB self heals: if any store(s) returned a value different than the determined correct value, or no value at all, the correct value is rewritten to that store. In this way, consensus, reliability, and redundancy is maintained.

I'm not sure any of these properties are ensured the way anyone would want. Why do this? What are the failure modes this protects against? If only one of the backing stores is active when a result is written, and then the others later become active with no data, is blank data returned for the prior result? It seems like recording timestamps would fix this problem nicely on a single system and make this thing overall quite reliable.

I didn't mean to say this was a silly thing to do - most modern processors execute instructions out of order on multiple ALUs.

The problem is that the abstraction layer between the python code in question and the processor's instruction stream is so thick that it's hard to say one way or the other that the processor is indeed executing that particular pair of instructions in parallel. It's definitely executing many instructions out of order, but it's unclear (without inspection of the python interpreter and its assembly) what's happening at the machine level.

Looking at the bytecode of the python program at least begins to tells us that the python bytecode of the two versions is fundamentally different, which could account for the performance difference. Although, what exactly makes the material difference is also under debate elsewhere in the thread. :)

This comment is excellent. The title of the original post should be: "When optimising code, never guess, always read the bytecode/assembly."

Without actually reading the assembly/bytecode/etc, you end up speculating about silly things like 'the two evaluations and assignments can happen in parallel, and so may happen on different cores.'.

Last I checked, MapBox's WebGL based vector tile renderer was a cut above the rest. For simple mapping, Google's stuff may cut it, but MapBox has the ability to draw complex vector polygons over a wide area that render/zoom/scroll fast and provide a nice experience. This is pretty important if you want to provide fine grained analysis of geographic areas.

If you wanted this on GMaps, you were stuck rendering all your vectors to image tiles, hugely increasing the size. MapBox's vector support made this very easy! It may be that Google/free options have caught up in this space, but I haven't re-evaluated in a few years.

I think MapBox could also be a winner in the GIS space as the GIS options have not made the most graceful move to the web.

What about the fact that these instructions might get partially executed in the pipeline before the branch gets resolved and the pipeline flushed? If a mis-fetched instruction can reach the LSU stage before the pipeline gets flushed, it might serve as a speculative memory load...

"There is nothing to support bitcoin except the hope that you will sell it to someone for more than you paid for it.”

Genuinely asking, isn't this the plan for many people? How is bitcoin different than other commodities or property in this regard? Would Bogle say the same thing about those investments?