@LovesTha Yeah, but... My issue is that a Docker image I'm trying to deploying is only failing on the server! Isn't that what's not meant to happen with Docker?

I thought Docker was meant to prevent these headaches!!!!!!!!

@pukkamustard I'll vote for Lua... I don't know what else meets these requirements...

@lightweight Same for Maori!

It seems the time to remind you: I'm builing my own browser engines "The Argonaut Constellation"!

I see a need to illustrate an alternate vision for the web if we are to get the improvements we want. I see a need for a more modular engine to aid experimentation both regarding the web & elsewhere.

And well... Someone had to do it!

@yatil I ended up arguing with Doctorow on this...

I'd be happy to engage in browser competition on iOS, but the competition I'd bring is not what is being naively dreamt about!

@theruran @psf @vidak Hmmmm, I think the Reduceron better inspiration there...

Its a stack machine that has been prototyped on an FPGA which uses ultra-wide memory buses & independently-addressed memory to optimize substituting in a function's arguments into a function body. Includes a builtin garbage collector.

Its specifically designed for Haskell & similar languages, and performance testing shows promise according to the researchers.

@blacklight @bob Personally, I think there's too much discoverability of opensource code!

A whole lot of it is half-backed & not ready for prime time. I'd rather there was human curational step in the process filtering out junk so I don't have to dig through it.

For this reason I take projects a lot more seriously if it's in, say, the Debian repos!

@natecull Do make sure to print out the Unicode standard & store it in a library somewhere! Ideally as many libraries we can reach!

I don't want to limit the, say, Chinese to ASCII...

@theruran If we take the approach of recommending e.g. a "free software system like elementary or Manjaro" I don't believe the "fragmentation" is actually a marketting issue.

You can argue about duplication of effort leaving less available to create a truly excellent system. In that case I'd argue this fragmentation appears to be directly proportional to the ease of implementing those tools! Which can have negative externalities if you're not careful...

@lightweight @theruran To give an example of where this trend: The thing that fragments most are webframeworks & syntax highlighters. Its trivial to write syntax highlighters in any language that supports regular expressions!

@JulianOliver That's what drives me!

@technomancy @somarasu @zens Yeah, I like railing against JavaScript. But I do admit that you can use it responsibly.

Seems that outside of capitalism few find it worth the investment not too...

@zens @zwol @niconiconi @alexandra @Jaqueek I believe all the modern font fileformats do this too! And I might have heard that bytecode is poorly specified & turing complete?

@zens @zwol @niconiconi @alexandra @Jaqueek I thought both Apple & Microsoft both had their own similarly-named formats? And that WOFF is a slight variation on OpenType?

Can't say I'm all that ontop of this aspect...

What else?

Inlining functions is a tricky balance to get right. Can reveal more optimizations & can save minuscule branching cost if its not overwhelmed by the harm it does to concision.

Some instructions (e.g. multiplication, divide) take longer to evaluate than others (e.g. add, subtract, shift), so there's "peephole" optimizers handling that.

Ordering code so related branches (with preference given to probable paths) are near each other helps the instruction cache.

5/6

Branch density is especially within loops, then again (especially if the optimizing if the optimizing compiler has anything to say about) loops make branch prediction easier! They can even make dynamic branches easier to predict!

So GCC at least has a whole suite of optimization passes dedicated to shrinking loopbody sizes & minimizing loop iterations (again vector instructions are very handy here), especially for inner loops.

Replacing finite loops with duplicate straightline code helps.

4/6

Then there's CPU registers! Even if stackmachines look more elegant to me...

RAM is relatively-extremely slow so optimizing compilers try to keep all the data they can in CPU registers. At which point a late lowering pass needs to decide which CPU registers those corresponds to.

Which is roughly equivalent to The Map Colouring Problem, meaning there's no good way to compute it. We have to rely on hueristics & fallbacks to stack.

As always lowering yields messiness to cleanup.

6/6 Fin!

Recently much of the performance benefits of modern CPUs have instead come from "optimizing compilers" (like GCC, LLVM [in turn rustc, Julia, etc], Glasgow Haskell Compiler, JavascriptCore, Spidermonkey, V8, JVMs, etc) emitting code better suited for them. Addressed by numerous optimization passes.

At which point compilers have an interesting tradeoff: Do we make our own software faster or the software we're compiling? JITs have this worse!

So what sort of code does modern hardware like?

1/6?

Modern CPUs love small software! It fits better in its instruction caches! Perhaps an optimizing compilers main job is to rewrite your code to be more concise without unused code, duplicate code, computations which could be performed at compiletime, etc.

Vector instructions can help with this!

Sure you could argue that this is poor code quality the compiler is cleaning up, but thanks to lowering (split into several passes) & other optimizations it sneaks into even the cleanest of code.

2/6?