{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicpa2euogej6w2vbmgupk4vvxgpc2a2yaessaoaa2sjiul4wcptk4",
    "uri": "at://did:plc:hqad6xwuzg7oqfmwylfkvqfm/app.bsky.feed.post/3mi3hb42ng6w2"
  },
  "path": "/viewtopic.php?t=33248&p=271502#p271502",
  "publishedAt": "2026-03-27T20:29:04.000Z",
  "site": "http://forum.palemoon.org",
  "textContent": "> I rewrote the memory management for JavaScript using SSE2. I don't know if I can push this to upstream though considering Pale Moon is AVX only\n\nPerformance improvements are always welcome if they don't cause issues.\nAlso, it doesn't matter that our main compiler optimization is using AVX; if you are implementing SSE2 variants of core functions at the code level, that may still improve the more generic functions there are (keeping in mind low-level/assembler parts of the code are unlikely to be touched by the compiler's AVX routines).\n\n\n> As far as I remember, Pale Moon switched to avx for the few percent performance it gives.\n\nIt's considerably more than that. However:\n\n> And if sse2, with your optimizations, provides even better performance...\n> It's not like switching back to sse2 would be difficult.\n\nIf there is enough performance improvement with a collection of upstreamed patches that makes for a more balanced set working better on a wider set of processors and not actually benefitting from AVX compiler optimizations, then I'm all for taking away the AVX requirement in mainline and making things simpler for every user regardless of hardware. But... it won't be decided on just a single site's load speed. A lot more testing will have to be done.\n\n* * *",
  "title": "Other Applications • Re: Dactyloidae Browser (Basilisk fork)",
  "updatedAt": "2026-03-27T20:29:04.000Z"
}