One of the things we always strive for our tools to do is meet you where your work already lives.

For most developers these days, that means Git, of course, but it also means GitHub or GitLab. Your source code is there. Your issues are there. Your pull requests or merge requests are there. CI status, releases, tags, milestones, labels, all the little bits of project state that live around the actual code — they are there too.

So with this week’s builds, we started to make Fire, Water, GitBrowser, and CodeBot a lot aware of those services.

You can now add GitHub and GitLab accounts in the Account Manager, including custom/self-hosted GitLab installs, and both GitBrowser and CodeBot in Fire/Water/Campfire can make use of them.

GitBrowser

The first place this shows up is GitBrowser.

Until now, GitBrowser mostly assumed that the repositories you cared about already existed locally. You could add a folder, drag a checkout in, group your repositories, work with local changes, branches, worktrees, commits, pushes and pulls, and so on.

That is still the core of GitBrowser. It is, first and foremost, a really nice tool for working with your local Git checkouts. But now it can also help you get those checkouts in the first place.

Once you have added a GitHub or GitLab account, the “Clone Repository...” flow can show repositories from that account. Pick one, choose where it should go, and GitBrowser will clone it and add it to your sidebar. SSH is the default, because that is what most of us use day to day, but HTTPS is available too.

This also works for custom GitLab servers, not just gitlab.com. So if your team runs its own GitLab instance, GitBrowser can talk to that as well.

The other direction is publishing.

If you have a local-only repository — maybe you initialized a folder locally, or dragged in a project that was not under Git yet and let GitBrowser initialize it — GitBrowser can now help publish it. You can publish to:

• a remote URL you already know,
• an existing empty GitHub/GitLab project,
• or a brand new GitHub/GitLab repository.

New repositories default to private, because that seems like the least surprising and least embarrassing default. You can choose the owner or namespace, enter the repository name, pick the branch to push, and GitBrowser will create or connect the remote, add origin, and push with upstream tracking set up.

One small but important detail: GitBrowser tries to infer GitHub/GitLab relationships from your existing remotes. So if you cloned a repository outside of GitBrowser, it should still be able to recognize “this is a GitHub repo” or “this is from that GitLab server”, and offer useful actions such as opening it on the web.

This is the beginning, not the end. Once GitBrowser knows about your account and can match a local checkout to a hosted project, a lot of future niceties become possible: creating pull requests or merge requests, checking out PRs into worktrees, showing CI state, opening issues, and so on, are on our list next.

But cloning and publishing felt like the right first step. Nice, practical, and immediately useful.

CodeBot in Fire and Water

The second place this shows up is CodeBot.

CodeBot already understands your solution, your code, your build errors, your debugger session, and so on. Now it can also understand the project-management side of the work, using the same GitHub and GitLab accounts you configure in the IDE.

That means you can ask CodeBot things like:

What issues are open for this project?

or:

Can you look up issue #1234?

or:

Log a new issue for this bug we just found.

CodeBot sees a unified tool surface, regardless of whether the backing service is GitHub, GitLab.com, or your own GitLab install. You do not have to think in terms of GitHub’s API shape versus GitLab’s API shape. CodeBot asks for “issues”, “pull requests”, “labels”, “milestones”, “pipelines”, “releases”, and so on, and the provider-specific details stay hidden behind the scenes.

For this first round, CodeBot can work with:

• configured GitHub and GitLab accounts,
• project/repository connections for the current workspace,
• issue lookup, search, creation, updates, and comments,
• pull requests and merge requests,
• labels and milestones,
• projects/boards where the provider supports them,
• CI/pipeline/status information,
• releases and tags.

Write operations still go through CodeBot’s approval system, so if CodeBot wants to create an issue, comment on one, or change something in your project tracker, it will ask first and tell you what it is about to do: which provider, which account, which repository, which item, and what change.

That is important. Reading project context is one thing. Writing to the team’s issue tracker is another. Helpful automation is great; surprise automation is not.

Under the hood, this is built as native account support rather than MCP. MCP is still great, and CodeBot continues to support it, but for GitHub/GitLab we wanted this to feel like a first-class IDE feature: accounts live in the Account Manager, credentials are stored securely, and the same connection can be used by GitBrowser, CodeBot, and future IDE features.

As always, this is one of those features where the first version is useful, but the real payoff comes as it starts connecting with everything else.

Imagine asking CodeBot to investigate a failing build, trace it back to a commit, look up the related issue, summarize the current PR, and then draft a comment with what it found. Or having GitBrowser show you not just that your branch is ahead, but that the matching merge request is green and ready to go.

That is the direction we are heading.

For now: add your GitHub or GitLab account, try cloning and publishing from GitBrowser, and try asking CodeBot about your issues.

And, as always, let us know what feels useful, what feels awkward, and what obvious thing we forgot.

We only shipped GitBrowser for Mac earlier this year (after it being an internal tool here at RemObjects for several years), but it has already evolved a lot since. Let's take a look at some of the exciting new features we recently added...

Change Set Analysis

One of my favorite features that recently landed, and frankly one I cannot even believe I lived without, is Change Set Analysis.

These days, I don't just work on my local checkout alone. Between CodeBot and Codex, I often have several agents working on adding new features or improvements at the same time, while also tweaking and reviewing code myself. After a while, I easily end up with 30+ changed files covering different sets of features, all ready to be reviewed and committed. (Yes, I should be using separate branches, see below 😉. But often I don't, because often it's easier not to).

GitBrowser's new Change Set Analysis makes it easy to sort out what's landed, review it, and commit it clean.

Simply right-click in the empty space of your changed files list, and choose "Analyze Changesets with CodeBot". GitBrowser will gather all local changes, and pass them to CodeBot to analyze, and after a few seconds, you get a view like this:

CodeBot has grouped my 20+ changes into distinct groups, and provided me with a succinct description of what each changeset entails. In this case, there's a new "code completion" for the prompt editor (think typing voice=), changes to the history chat compression, and some more changes off-screen.

Clicking on any of the filenames will give you a diff preview via QuickLook.

If I'm feeling confident, I can click "Commit" right there, confirm and/or adjust the pregenerated commit summary, and done. More often than not, instead I'll choose "Stage This" and close the sheet. GitBrowser ill stage the relevanr changes for me – and prefill the commit message – but i can then have a peek at the files, review the changes, and see if i maybe want to include or exclude anyting else form this change, before i commit manually.

In the example shown here, the changes were to several pretty distinct features, so there was no overlap. But the cool thing with Change Set Analysis is that it works even if parts of a single file have changed for Feature A, and others for Feature B. When you tell it to stage (or commit) Feature A, you will see that the file shows in a partially staged state – GitBrowser has committed only the sections that belonged to Feature A, but not the ones for Feature B.

Pretty cool.

Partial Staging or Reverting

GitBrowser has also gotten support for manually staging just parts of a file. Again, this is helpful if, e.g., you made changes to a file that cover distinct features, but also if you maybe have some changes that are ready to commit while others are not, or you have unrelated local changes – e.g., debug logging – that you don't want to commit.

Right-click in the diff view at the bottom right of GitBrowser, and you can now choose to stage (or discard) any individual change (or hunk, as Git calls them).

In this case, I'll discard the change, because importing Foundation is silly when AppKit is already in use. Even Codex doesn't get it right all the time... ;)

If a file is partially staged (showing as [-]), a new toggle at the bottom of the diff view lets you choose which diff to see: previous version vs. staged, or staged vs. unstaged. (If a file is fully staged or fully unstaged, the toggle is disabled – because one of the diffs would be empty. But it still adjusts to show you which view you are looking at.

Double-clicking your file to open an external diff viewer will open a three-way diff (if supported), allowing you to compare the previous version, staged, and unstaged, at the same time (this part is not new).

Worktree Support

I'm somewhat new/late to using worktrees, myself, and you will argue that embracing them more fully would prevent needing Change Set Analysis. And you'd be right, but.

In Git terminology, a Worktree is similar to a branch being checked out to its own separate folder, except that it is not, in that it doesn't require you to have a complete separate clone of the repo, and that Git keeps track and manages your wlorktrees for you. GitBrowser embraces worktrees and makes ot really easy to work with and manage multiple worktrees for your repository.

Personally, I'm not a big branch guy myself. I will use branches (and worktrees) for big, long-running feature work, but I prefer to stay on my main branch for regular development. Hence, Change Set Analysis ;).

Getting started with worktrees in Git Browser is super easy. You can create a new worktree in two ways, from the Branches pop-up in the toolbar

• Open the "Worktree from Branch" submenu, and pick any existing branch.
• Choose "New Worktree..." and pick a name for a new branch, to create a worktree based on your current branch.

Note that you can only create a worktree for a branch that is not currently checked out, and once you have a worktree for a branch, Git will not allow you to switch to that branch on your main checkout or on any nother worktree. GitBrowser will gray our ineligible branches in the menu.

In either case, GitBrowser will ask you for a target folder for your new worktree. It will suggest your main repository folder, suffixed with the branch name, e.g. ./MyApp-develop-coolnewfeature so the new worktree would live next to the orogonal folder – but you can place your new worktree anywhere on disk that you like.

Once a worktree exists, you can work in that folder like you always would. You can commit, you can push, you can merge e.g. your master branch back into the worktree branch, and so on. It behaves like a normal Git checkout. You can even switch branches (which might get confusing if you named your folder after the branch, so I don't recommend it), as long as that branch isn't checked out elsewhere.

Git and GitBrowser keep track of your worktrees, and if you do have any active worktrees, they will show up as child nodes of your repository. They will also show in the branches pop-up in the toolbar.

Your main checkout will show with the solid tree icon, and it represents the main folder of your repository, the actual git clone. Secondary worktrees will show as the hollow tree icon.

Selecting any worktree in the list will allow you to work with that worktree and on that branch in GitBrowser, as if it were a normal checkout (which it is, I guess). You can review your changes, stage and commit, browse history, run available merge scripts, and so on. (Selecting the "solid tree" main checkout is the same as selecting the root node).

The context menu for worktrees provides some additional helpful options. "Compare to" opens your favorite diff viewer for a folder comparison between the two worktrees and any other. It's helpful if you just want to have a quick peek at what's different, or maybe review a change made in the branch compared to the original code.

More interestingly, "Analyze Changes over" allows you to run a full Change Set Analysis (similar to above) between the two branches. Like for local changes, Change Set Analysis will ask CodeBot to have a detailed look at the files that differ between the two worktrees, and give you summaries of the changes in logical groups.

It's super helpful if your co-worker just dumped a branch on you to merge with seven new features that need to be reviewed and approved before they can be merged. Not that that ever happened to me...

Finally, at the bottom of the context menu, there's an option to "Retire" the worktree once you're done with it. Retiring will delete the local folder (but not the branch!), and will unregister it with Git. You should generally not just delete the folder manually, because then Git will not know about it and get confused. But if you did, GitBrowser will detect that, show your worktree as "missing", and give you an option to clean things up.

As a last aside, you might notice the two odd worktrees in the screenshot above, and might find similar one slisted on your system. Worktrees can be checked out to a name branch or a commit, and – unlike with branches, several worktrees can exist for the same commit. The two you see here were created automatically by Codex for background work. It will sometimes do that. You can delete them in either GitBrowser or via Codex's Preferences view, if you are sure they aren't needed anymore.

GitBrowser for Windows

GitBrowser was originally conceived as a Mac app, because I wrote it mainly for myself to use when GitBox died.

Since we shipped it, a lot of people have asked to use it on Windows, so here we are.

GitBrowser was actually built on the same IDE foundation as Fire, so porting it turned out to be a lot easier than expected (or maybe just as expected) – it was basically a weekend side project to get a usable v0. We have done a lot more polishing since, and a lot more is to do, but as of this week's .295 set of builds, a preview build is available for download. Check it out and let us know what you think!

GitBrowser and CodeBot Server

Finally, I want to talk about a new option for connecting GitBrowser to AI.

Right now, GitBrowser uses embedded CodeBot – just like Fire and Water, if in an exposed, much more limited way – for its AI functionality. This means you provide it with your own API key to connect it to the AI provider of your choice, e.g. OpenAI, Claude, or Gemini.

With the upcoming CodeBot for Delphi, which uses our own CodeBot Server backend, you will now be able to connect GitBrowser to your CBS account and your existing CodeBot/Delphi credits for the AI features – no separate sign-up with an AI provider needed. In the back, CBS uses OpenAI's gpt models.

The main theme this week is that CodeBot has evolved further, from a reactive chat assistant toward something more proactive, media-capable, and host-aware. In particualar for the upcoming Campfire, this shows up as scheduled prompts, proactive reach-out from CodeBot to you, and new options for time awareness, location awareness, life events, and proactive planning. CodeBot also now keeps long-running work awake with power-management support, which should make longer background runs more reliable.

Media generation is the other big visible area. CodeBot and Campfire gained broader image generation routing, partial media previews, generated-image annotations, and early video-generation support via Grok and Gemini, including retries, partial-result recovery, streaming image support, reference-image persistence, and generated-media cost tracking.

On the compiler side, Elements had a more focused but still meaningful quality pass. The compiler picked up fixes for invalid IL around untyped var params in async state-machine cases, stack-depth verification after raise in case expressions, fixes for C# string interpolation whitespace, Java file-scoped package preservation, Delphi Compatibiliti Mode enhancements, and stricter handling of untyped var/out params outside DCM. The debugger also gained delegate-variable support on the CLR and Mono.

Infrastructure carried much of the platform work behind the Fire/Campfire changes: persistent scheduled prompts, proactive planner diagnostics, duplicate-schedule protection, thread-history chaining for better conversation context, safer skill/session refresh behavior, stronger model-strategy propagation, image-generation capability gating, and more robust analyzer parsing.

Elements 13 shipped just last week, but we already have a major new round of features and enhancements landing today.

Fire & Water

• CodeBot got broader model strategy/profile work: deep reasoning profile, debugger profiles, capability-based model selection, Mistral/latest model strategy, better routing, and public orchestration enablement.
• Interactive debugging mode for CodeBot in Fire and Water.
• MCP support in CodeBot expanded with endpoint connection UI, OAuth flow support, optional local approvals for access to the MCP Server, and safer elicitation behavior.
• CodeBot also gained image generation support (less interesting for CodeBot, more intersting for the upcoming Campfire).
• Usage reports for CodeBot if Fire, Water and GitBrowser.
• GitBrowser gained CodeBot-assisted changeset analysis for unstaged diffs, and support for logical grouping of files/hunks.

Elements

• Toffee/libNougat LINQ support expanded substantially: Chunk, SkipLast, TakeLast, Zip, Append, Prepend, Aggregate, LongCount, joins/group joins, SelectMany, SequenceEqual, DefaultIfEmpty, ElementAt*, Single*, Count(block), Sum, Average, ToLookup, and corrected Except semantics.
• InternetPack updates inside Elements: percent-decoded HTTP query parameter names/values, bound-port reporting after socket bind, and consolidated multi-target project structure.
• RTL2 update: async Process completion is more reliable when output pipes stall, on Darwin.

CodeBot for Delphi

• CodeBot for Delphi is getting closer to release, with a new client build that lands a lot fixes and improvements and, more importantly, a brand new Code Bot Server backend built on the shared Infrastructure Agent Runtime.

Infrastructure

• OpenAI integration advanced quite a bit: /responses API support, image generation support, automated API key creation tweaks, usage/cost APIs, and gating/routing around newer model capabilities.
• Structured JSON response formats are now supported across AI clients and agent profiles, including OpenAI chat/responses payload handling and tests.
• Model routing became more capable: configurable model strategies, reasoning effort tracking, capability fallback routing, profile-level capabilities, explicit profile routing from message text, and better GPT model filtering.
• Agent runtime improved: AI usage tracking for runs, polished usage report presentation, cleaner profile/orchestration model, and revamped runtime overview documentation.
• Gemini tool calling support was added, and Claude request handling has been improved

High-level theme: this week is heavily CodeBot/AI-platform focused, with visible Fire/GitBrowser workflow upgrades, a sizable Infrastructure AI/MCP/OpenAI foundation push, and a smaller but meaningful Elements compiler/runtime/library fix batch.

But the most exciting thing, I think, is that CodeBot is now a painter too.

With last week's release of Elements 13, we shipped what is probably the largest and most significant update to CodeBot since its inception: CodeBot v3.

CodeBot v3 is not just an extension of what came before it; it is a brand new experience that will – I know this might sound like hyperbole, but trust me, it's not – change how you write Elements code, forever.

The biggest change to CodeBot is under the hood, and that it has grown from a simple question/answer chat model to a fully orchestrated agent runtime powered by RemObjects Infrastructure. It knows different profiles and can spawn agents specialized for certain tasks, such as code review, finding security flaws, writing new code for you, or even interactive debugging. Each specialized agent automatically comes with Skills embedded that give it expertise in its field, and in Elements in general.

Skills

Detailed, predefined skills for your language (s) and platform(s) of choice let CodeBot really understand what you are working with. For example, if you are working on a cross-platform C# project (like I do when working on Fire itself), Codebot really understands that C# does not just mean .NET, and knows how to apply Cocoa concepts, use Elements RTL, and so on.

The Skill infrastructure is open and extensible, and you can create your own Skills (or have CodeBot create them for you automatically) to teach CodeBot about your own projects, coding style, and preferences, or to give it detailed knowledge about your application domains. You can create skills right inside CodeBot, and it will also automatically pick up any project-level Skills you might have from other tools such as Codex or Claude Code.

Tools & Approvals

CodeBot comes with more and better tools than ever, for all areas of development. It is better at reading code and has gotten really good at updating your code. It can build or test the project for you, diagnose error messages, run external tools, and more.

As someone once said, with great power comes great responsibility, so CodeBot has a new granular approval system that puts you in charge of what CodeBot can and cannot do.

By default, CodeBot will have read-only access to your project, meaning it can look around and give you advice. It can look, but not touch. For any action that could have an effect on your project (let alone outside of it), CodeBot will ask for your permission, which you can grant broadly or narrowly, based on your preferences and your trust in the tool. For example, if you ask CodeBot to make a change in your project for the first time, you will see someting like this.‌                                                              

Note how, in addition to showing you the change it wants to make (more on that in a bit), it gives you several options:

You can allow this and future changes to this particular file, or to all files in your solution (or its folder). You can also choose whether you want to approve just this one change (it will ask you again for the next one), or if it can go ahead making changes on its own moving forward – either just for this coding session, or forever.

This approval concept applies across all actions CodeBot can take, and you can decide how much autonomy to give it. For example, I tend to want to review code changes, especially when working on important codebases, so I generally press "Once", here, but I'm happy to let CodeBot do tasks such as rebuilding my project or starting a debug session, without re-confirming each time.

YMMV, also based on what type of project you work on – e.g., a serious project vs an afternoon vibe-code session.

Of course, you can always review (and remove) all pre-approvals in the new "Manage CodeBot Data" sheet.

(P)reviewing Code Changes

You've already seen that CodeBot will show you a nice inline diff of the changes it plans to make, and that's great. But I often find these diffs hard to read – especially for more complex or intricate changes to an existing method flow. CodeBot gives you the option to open the diff in a real external diff viewer of your choice, such as Araxis Merge (my favorite), Kaleidoscope, or BBEdit.

What's more, if you like what CodeBot proposes, but are not quite happy with the final shape – e.g., the formatting is a bit off – you can tweak it in Araxis Merge, hit save, and when you come back to Fire or Water, your changes will reflect when you apply.

No need to track down the code to adjust it afterward, or ask CodeBot to make a minor adjustment.

Action Items

Oftentimes, especially when doing a code or security review, CodeBot might come back with a whole bunch of suggestions on what to fix or improve. Not for your own code base, of course, but code other people wrote. Sometimes it can be hard to keep track or tackle it all at once, so CodeBot has the option to log these as "action items", to keep track of, tackle one by one, or come back to later.

You can then ask, e.g., to address these one by one and mark them off the list.

Builds, Runs & External Tools

CodeBot can, of course, run a build for you and look at, diagnose, and address error messages. In fact, it will often suggest doing this on its own after making changes, to make sure the changes landed well, or make further tweaks and adjustments if the first fix didn't stick. It can also run your project, including in EUnit test mode to run your unit tests (which it will often suggest to set up for you as it implements new features or fixes for you).

In addition, CodeBot can run (and manage long-running) external tools for you – after proper approval, of course. For example, you might be working on a project that connects to a separate server app. You could ask CodeBot to launch that server and keep an eye on its log output as you debug your app (or as CodeBot debugs it for you ;).

Debugging

Which brings us to Debugging. New in .3083 this coming week, CodeBot will be able to run a fully autonomous debug session for you, which is truly a sight to be seen. You can just tell it:

Hey, when I run my app, at point X in time I would expect it to print "blah", but it prints "blub". Can you debug and figure out why?

CodeBot will go ahead and debug this for you; it will run the project (sometimes many times), set breakpoints, step thru the revelant pieces of code, evalaute expressions – in essence, employ all the debugging steps you would normally do manually – and in the end, hopefully, not only point you to soucre of the bug, but also offer a ready-to-apply fix to solve your problem!

MCP Support

Model Context Protocol (MCP) is an industry-standard protocol for connecting AI tools, and CodeBot comes with built-in support for MCP both as a client and a server.

MCP Client support means you can connect CodeBot to your favorite MCP sources and access the external tools or resources provided by them. For example, you can connect CodeBot to our GitHub account via MCP and let it manage repositories or check and log tickets for you, or connect it to Notion to have it automatically generate documentation to share with the rest of your team.

MCP Server support means that CodeBot itself can (opt-in) act as an MCP server, and you can let other AI tools control Fire or Water for you. For example, you can connect Codex or Claude Code to Fire and have them run builds for you, understand the project content, or make changes for you. Essentially, any tool that CodeBot has at its disposal inside Fire or Water also becomes available to the AI apps you connect to it.

And So Much More

And these are just the highlights. There is so much more in CodeBot v3, anbd even more to come over the next few weeks and the rest of the year. We can't wait for you to try it!

Under the Hood

CodeBot v3 is built on our all-new Infrastructure AI Agent Runtime. It is a new shared codebase that will also be used by the upcoming (very soon now, promise 🤞) CodeBot for Delphi, and another in-the-works product, and is also available for use in your own projects, via our  RemObjects Infrastructure platform.

Get Elements 13 w/ the New CodeBot v3, Now

Elements 13 is out now and – as always – a free update for all users with an active subscription. Don't have a license yet? Get one in our also brand new and more beautiful-than-ever Online Shop, or get a free 30-day trial version to check it out!

Read more about CodeBot on its dedicated product page here.

Enjoy, and let us know how CodeBot changed your developing life!

If you compile your app for AVX2 and it runs on Windows ARM under Prism emulation, is it faster or slower than compiling for SSE2-4.x?

I assumed it would be roughly the same — maybe slightly slower due to emulation overhead, but AVX2's wider operations would compensate. The headline gives it away: I was wrong.

This post explains how I found out, what I measured and how, the benchmark results, and why.

Curiosity

A few weeks ago, in a Hacker News thread on WoW (the game) emulated performance on Windows ARM, I wondered:

I’ve been testing some math benchmarks on ARM emulating x64, and saw very little performance improvement with the AVX2+FMA builds, compared to the SSE4.x level. (X64 v2 to v3.) ... I’ve found very little info online about this.

Well, I nerdsniped myself, because those math benchmarks are now complete and so we have the perfect framework for testing AVX2+FMA emulation performance overhead on ARM Windows. I have no technical reason to do so: if you use our compiler we encourage that if you want to run your app on Windows ARM to just compile your app for Windows ARM. It's simply: I want to know.

Thus I spent much of Sunday crunching our data and figuring it out.

ARM emulation of x86

You can skip this bit if you know about Windows ARM's emulation and what various Intel instruction sets like SSE through AVX2 are: go forward to Benchmarks.

Windows 11 lets you run both 32-bit and 64-bit Intel apps on ARM. It does this via emulation. Essentially, x86/64 code is translated on the fly into ARM. Windows 10 supported emulating 32-bit Intel, and by 2021 Windows 11 introduced emulating 64-bit apps.

In 2024 Windows 11 was updated with a new emulation layer, Prism. The main user-facing change seems to have been performance: 'Microsoft told Ars Technica that Prism is as fast as Apple’s Rosetta 2' and:

Most x86 apps now run without issues, and in many cases don't even feel like they're being emulated. These days, the majority of users won't notice a difference between using an Intel PC or a Snapdragon one
– Windows Central

Is emulation complete / entire?

x86 and x86_64 have not always remained the same. Over time they add more functionality, which is exposed as instruction sets. These are the base instructions that an app can be compiled to use and are often focused around doing things faster. For example, the x87 floating point math instruction set still exists (it was introduced in the 1980s!) but was succeeded a quarter century ago by SSE2, introduced with the Pentium 4. SSE2 lets you perform floating point math operations much faster. A few years later the SSE 4.x series also improved largely integer-based operations. This is a very handwavy summary: in fact, these are part of a wide series of instructions intended to process data fast, where possible in wider configurations (more data at a time per clock tick) than older instructions, each new improvement introduced one by one over many years. This does not even begin to address the other supplementary extensions: ones for bit manipulation, specific math patterns like multiply-add, and more.

This is important to understand because software does not all use the same sets of instructions. Figuring out baseline standards of which sets it was reasonable for an app to use was a mess, and Linux folk found it annoying enough that, working together with Intel and AMD, Red Hat and SUSE defined standardised versions to allow known safe targets for compiling for specific collections of instruction sets. Thanks to them, x86_64 now has four main versions that modern compilers target, which define generations of new instructions. x64 version 1 is that same old year-2000-ish era; x64 version 2 circa 2008 level, v3 circa 2013 level, and v4 circa 2017 level.

It takes time for instructions to become mainstream: if you are building software for 64bit Intel Windows in general, you likely won't build solely for the v4 2017 level because you may have users who have older computers, or ones newer than 2017 but which had less capable chips that didn't feature all the latest instruction sets. AVX-512 (v4) is a wonderful instruction set for very wide vectorised behaviour but still many computers in practical use today don't have it.

And similarly to how actual hardware may or may not support specific instruction sets, Windows x86 emulation also supported only a subset.

That subset was approximately x64 version 2 (ie with SSE2 and 4.x) and only recently have newer versions of Windows have supported v3: to handwave, AVX2 and FMA. This is new, exciting, and to my knowledge, largely unknown.

We are comparing performance using x86-64-2 level vs v3 level running emulated on ARM.

That brings us to that Hacker News comment and today. What's the emulation performance for those newer instructions?

Our benchmarks

At RemObjects we make a multi-language (6 of them!) compiler toolchain that targets native CPUs via LLVM (as well as .NET, JVM, and WASM backends.) We recently integrated a new vectorised math library, which gave us the perfect benchmark framework for testing this.

We already supported ARM Windows, that is not new, but our cross-platform RTL had our own implementations of common math methods on the 'Island' (native) platform (the normal set: sin/pow/exp/floor and so forth.) These were correct in that they followed known algorithms, but we felt there was room for performance optimisation. We settled on integrating a third party open source math library. At the time I wrote the above HN comment, this integration was still being tested and tweaked; we even changed some of LLVM's internal passes.

Today, we have this new math implemented for macOS ARM (and x64), and Windows i386, x86_64, and ARM64. Our Windows 32-bit (i386) math supports SSE2/4.x, but the math library for Windows x64 supports using either v2 (SSE2-4.x) or v3 (AVX2-targeted) level depending on the x64 revision you target in the compiler options. (You can actually tell Elements to target v1 through v4, but our new math library kicks in at v2, with more performance with v3, and we have not enabled anything extra in math for v4; you can certainly compile allowing AVX-512 etc if you wish for your code in general though.)

As part of checking our new math code as (a) correct and (b) improved performance, we have concrete data running 21 different math operations on both real x64 hardware, and Windows ARM on Parallels on a Mac M2.

Because these are different machines we cannot compare the wall clock time, but we can compare the relative time, using the SSE2-4.x level as a basis: what is the relative performance difference of using AVX2(+FMA) on Intel vs on ARM? Normalising against the earlier, well-emulated instruction set means that the difference between emulated and real hardware gives us the answer of how well AVX2 emulation performs.

We can also use ARM64 on ARM, and AVX2 on x64, as a handwavy comparison for if you need ARM: an indication if emulation provides 'good enough' performance or if there's real value in compiling for ARM.

Thus:

• Using SSE2-4.x as a baseline for performance on both ARM and x64 (ie, scaled this to 1), what is the relative performance of AVX2 when emulated on ARM vs running on x64, and thus what overhead does ARM emulation of AVX2 provide compared to native?
• Using two kinda similar-gen machines, and hand-waving that it's nothing more accurate than that, how well does ARM-native vs x64-emulated vs x64-native perform? Do you need to compile for ARM, or can you get away with letting your apps run under Windows emulation?

Details

Performance tests instruct LLVM to build targeting the specific instruction set; are heavily vectorised; and our AVX2 level includes FMA (fused multiply-add.) We use only 256-bit wide AVX2, not the 128-bit wide instructions. Specifics are:

• Normalised to 1.0: CPU x86-64-v2 (referred to as 'SSE2-4.x' above, because those are the primary instructions math uses), feature set: +cx16,+popcnt,+sahf,+sse,+sse2,+sse3,+ssse3,+sse4.1,+sse4.2
• AVX2+FMA comparison: x86-64-v3, feature set: +cx16,+popcnt,+sahf,+sse,+sse2,+sse3,+ssse3,+sse4.1,+sse4.2,+avx,+avx2,+fma,+bmi,+bmi2,+f16c,+lzcnt,+movbe,+xsave
• ARM64: 'generic' ARM64 CPU, no specific feature set

Each math operation is run on a randomly initialised array of 64-bit doubles as input, in a loop (ie intended to be vectorised), 10 million times. The output is retained and 'used' in order to prevent the loop being optimised away. In IR, we verified the loop exists, is vectorised, and appears to look as expected. Numbers reported are typical timing runs, with no observable difference in cold vs warm runs. Timing is of course only around the tight loop itself, not the prolog or epilog setting the data up or 'using' the results.

All the 21 results are then scaled as a ratio vs baseline instruction set, x64 v2, and the geometric mean calculated to give a single representative number. This means that we can tell how much faster AVX2-level code is vs SSE2-4.x level, both on actual Intel hardware, and under ARM emulation.

Test machines

x64: Tiger Lake i7 (2.80 GHz), mobile-class CPU, circa 2021, on Windows 11 Pro 25H2.

ARM: Apple M2, circa 2022, macOS Tahoe 26.1 with the ARM version of the same version of Windows 11 Pro (25H2), running on Parallels 26.

x86_64 AVX2 emulation on ARM: Results

The following chart scales x64 v2 to 1.0 (grey baseline) and x64 v3 i(ie AVX2+FMA) is relative to that (Intel in green, ARM emulation in blue), that relative number calculated as the geometric mean of the result ratios of x64 v3 vs v2 for 21 common math functions run on 64-bit doubles per the above detailed description.

Normalised to 1.0, larger is better (faster).

As expected, using AVX2 on native Intel is significantly faster: 2.7 times faster.

But when the same code is run on ARM, the AVX2 implementations are notably slower than SSE2-4.x. They are almost exactly 2/3 as performant as emulating the older instruction set.

This means if your app uses x64 v3 with AVX2, and runs on emulated ARM on Windows, following this data, it will run slower than if you restrict it to the x64 v2 compilation level.

Why?

At the time I wrote the HN comment that started this, I had noticed that we didn't see faster performance using the AVX2 versions of our math function on ARM; what I had not yet measured was such a significant slowness.

Some possible reasons are:

• ARM has 128-bit wide NEON operations. AVX2 is using 256-bit wide operations (our code is not using 128-bit widths). This means the emulation code has to handle running two halves; it would be very close to impossible to make that equal performance.
  This is in my estimation the most likely single reason.
• The Prism AVX2 emulation code is new, compared to that emulating older instruction sets, and may not yet be fully optimized.
• It may optimise for heavily for 32-bit singles, not 64-bit doubles. Our math library focuses on double-precision.
• The ARM emulation documentation notes, 'Prism is optimized and tuned specifically for Qualcomm Snapdragon processors. Some performance features within Prism require hardware features only available in the Snapdragon X series...'
  These tests were on an Apple M2. While I'm sure Microsoft wants to support, or even prioritise, non-Apple hardware, in my view, Windows on Mac (via Parallels) is worth them supporting. But perhaps they don't support it well, yet.
• The emulation code may look for specific patterns that our code does not meet: perhaps, and this is entirely speculation, known (eg) VC++ Intel output, such as common RTL methods, may map to specific ARM64 patterns in the emulator. We are using LLVM, and (probably) rarer math implementations, therefore, less common sequences of operations.
  I cannot speak to how the emulator is implemented, and if this is even likely. It's a guess.
• Our x64 v3 performance seems, at this stage of testing, to be faster than Visual C++'s. (By a significant factor: in this chart, where our AVX2 code at our maximum FP precision came in at 2.7x the baseline, a VC++ 2022 version of the same benchmark compiled in x64 release mode, default FP accuracy, no further changes to default settings came in at 1.3x running on native Intel hardware. Yes, that is a 2x difference, and we attribute this to the VC runtime likely lacking AVX2-optimised math routines; their SSE2 math is slightly faster than ours, gosh dangnum darn it.)
  Therefore, for AVX2, using our compiler may be unfair compared to using other tools.

Meaning in practice

It is rare to have tight loops of operations: data processing, scientific and engineering software, etc., are the most likely. Even games may push much to the GPU. Therefore, the impact you see on your AVX2 app is unlikely to represent your app running at 2/3 the speed of your AVX2-4.x app. Only parts of it will.

If you have apps that do real number-crunching, whether that's native or something like Python, you should have the ARM version installed. (You likely have the ARM64 Python wheels installed anyway. But check.)

Although this checked floating point math, it is likely that it also applies to integer instruction set emulation too.

Therefore, it's likely worth treating Windows' ARM emulation of AVX2-level support as for support and compatibility, not for equal performance. To get performance, you'll need to compile as ARM.

If performance is key: Yes, it is absolutely key to build your app as ARM, not to rely on Windows ARM emulation.

This weeks Elememts build brings three new and exciting language features to the Oxygene language – and they all center around a single new keyword: field.

Field-Backed Properties

Things started off by bringing one of the new C# 14 features to Oxygene: Field-backed Properties.

Field-backed properties solve the conundrum where, as soon as you want a property to do anything more complex than just store and retrieve a value straight-up, you need to manually declare a field to store its value in by hand. With the new syntax, you can let the compiler handle that part for you, but still provide custom getter or setter code. And you can use the new field keyword (same in C# and Oxygene) to access the "backing field" from inside that code.

In C#:

private string _msg;
public string Message
{
    get { return _msg; }
    set 
    { 
        _msg = value ?? throw new ArgumentNullException(nameof(value)); 
    }
}

Now simply becomes

public string Message
{
    get;
    set 
    {
        field = value ?? throw new ArgumentNullException(nameof(value));
    }
}

No manual getter code; no private field declaration, no msg cluttering up the class's scope. And, most importantly, no chance to accidentally access _msg directly from other pasts of the class.

The same concept applies to Oxygene:

property Message: String write begin
  field := coalesce(value, raise new ArgumentException(nameOf(value));
end;

Any property that uses the field keyword in its read or write code becomes a field-backed property.

Also, any field-backed property will be read/write, and get its default read or write Implementation implied, if not specified, like in the example above. Why can we assume that's the intention? Because a read-only or write-only field-backed property would be pointless – who else would read (or write) its value, otherwise?

Field-backed Properties for Oxygene are documented in full, here.

Fields

Now that we have a field keyword in Oxygene anyways, this opened up the door for additional opportunities.

I have long been a proponent of proper naming, because the way we call things shapes the way we think about them. It's one of the takeaways I got from the excellent book Object Thinking, and one of the reasons why – as far back as version 1.0, before it was even called Oxygene – I pushed for the introduction of the method keyword to the language. Because Classes do not provide functions and procedures (and there are additional arguments on why Pascal's terminology re: functions and procedures is bad – but that is for another day), they provide methods. So it feels only right to use the method keyword to declare them.

Another thing classes (and records) contain is fields. In fact, a class without fields is not much of a class. Even though fields are (usually) variable, as in mutable, they are not variables! Yet, what (optional, alas) keyword did we use to declare fields? var.

No more! As of today, the field keyword can be used inside a class or record declaration to declare one or more fields, replacing var as the preferred and suggested option.

Of course, var will continue to work, for backwards compatibility; just as function and procedure are still there to this day, if you prefer. But field is the way to go.

Field type members in Oxygene are documented in full, here.

Local Fields

But we did not stop there.

The third and probably coolest application of the field keyword is inside code, i.e. in the body of your methods.

Of course, the var keyword sticks around for declaring variables inside your code, whether in a var section at the top of your method, or – the preferred Oxygene way since 2004 – inline with the var statement.

This is not changing. But we've introduced a new field statement that follows the same semantics, but will declare a field on class-level – but scoped to be accessible only in the current method or scope. The field will be initialized the first time the line declaring it is hit, and after that, its value will persist across all future calls to the same method (on the same instance).

Essentially, a local field is like declaring a regular private (all fields should be private) field, but limiting access to it to a single method or scope within a method.

• Local fields can be instance (the default) or static for the class when using class field or the static modifier. (same as for regular, global fields).
• Local fields in a static method or a static class will, of course, always be static.
• Local fields in an instance constructor need to be static (because what would be the point, otherwise) and are not supported in a (static) class constructor.

For example, this Log method keeps internal track of indentation level, based on what strings it got sent to writeLn:

    method Log(aMessage: String);
    begin
      field fIndent := 0;
      if aMessage.StartsWith("<-") then
        dec(fIndent, 2);
      writeLn("".PadEnd(fIndent, ' ')+aMessage);
      if aMessage.StartsWith("->") then
        inc(fIndent, 2);
    end;

Local Fields for Oxygene are documented in full, here.

Get All Your Fields Now!

All of these (and field-backed properties in RemObjects C#, of course) are available in Elements .3057, out on the Preview channel today. We expect next week's .3059 to bring them ot the Stable channel and the free trial.

Read more about Elements here. New stuff is being added to Elements every week.

If you're a Delphi developer, you might not be used to thinking of Object Pascal as a language that produces very fast code. Not in the way people talk about C++ or Rust, anyway; those languages are famous for performance.

We think that should change. And we've done something about it.

Depending on your platform and what your code does, recompiling your Object Pascal with Oxygene instead of dcc32/dcc64 could now give you 4x to 11x faster math performance.

In our benchmarks, we're on par with Visual C++, and at the AVX2 level, faster than Visual C++ – yes, in Pascal. Let me explain what that means and how it works.

How we got here

Back in November we upgraded Elements' LLVM backend and, while we were there, got curious about our math performance. Island, our LLVM native code compiler backend, uses the IslandRTL for many functions including math. We don't reuse the system C RTL, because it can have varying implementations on every platform. We provide our own. Our math functions had correct implementations, of course, but we realised modern instruction sets offered an opportunity we hadn't yet taken.

It also became apparent that LLVM wasn’t being fully leveraged. While standard optimisation passes were in place, the possibility of going further was worth exploring.

So we set about investigating. What do other toolchains do? What does Visual C++ do? What does Rust do? What do other LLVM-based toolchains do, which are best practices we can also make use of?

What Is Island/Delphi?

Elements is our compiler with six language frontends: Oxygene (Object Pascal), C#, Swift, Go, Java, and VB. One compiler, multiple input languages, all of which can interoperate seamlessly; our own IDE is written using multiple languages in the same codebase, inheriting from and calling methods written in different languages with no bridging layer. It's a bit like Delphi & C++Builder, but six languages not two, and fully multidirectional across any language to any other.

Elements can target multiple platforms: .NET, JVM, WebAssembly, and native CPUs. The native CPU target is what we call 'Island', and it uses LLVM, the same compiler infrastructure as behind Clang, Rust, and Swift.

Island/Delphi is a mode where you can import a Delphi project and compile it with Oxygene, linking to Delphi packages. This includes using the VCL; the Water IDE imports the VCL and other standard Delphi packages, though third-party components need to be imported manually (a straightforward File > Import step, which you can also do in the Fire IDE on macOS, or within Visual Studio.)

Island/Delphi isn't at 100% Delphi compatibility yet: think of it as a v0.9. But we think it's amazing: for many projects you can import and rebuild. Your Object Pascal still works, your VCL forms still work; the difference is what happens at compile time, because you get the benefits of a modern LLVM-based toolchain, including a wide variety of modern language features that Object Pascal developers have asked for.

What We Improved Lately

Two things that work together:

1. A fast, vectorised math library

We looked at what other toolchains did to get faster math than the default system libraries. Rust developers who want vectorised math can use SLEEF, so we integrated it.

SLEEF is an open-source math library designed for SIMD operations, providing vectorised implementations of sin, cos, exp, log, and the rest.

What does vectorised mean? Rather than processing one value per CPU instruction, a vectorised operation processes multiple values at once. Modern CPUs have wide SIMD registers: 128-bit, or 256-bit with AVX2. A 256-bit register holds four 64-bit doubles, so a single instruction can process four values at once. This is how you get significant speedups on numerical code.

2. CPU target selection

You can now tell the compiler which CPU level to target:

• Win32: SSE2 (always)
• Win64: x86-64-v1 through v4 (default to v2; and we recommend v3 if your users have ~2013+ hardware)
• ARM64: Native Windows ARM compilation, which Delphi doesn't support yet

When you target a higher instruction set level, the math library uses more capable implementations. AVX2 for v3, for example, processes 256 bits of data per instruction instead of 128.

You can read more details on our general Elements blog post, since this benefits all six Elements languages.

The Performance Difference

We benchmarked 21 common math functions (sin, cos, exp, pow, log, sqrt, and so on) running each 10 million times on 64-bit doubles. Here's what we found comparing to Delphi 13.

Hardware: Intel Tiger Lake i7 (2.80 GHz), Windows 11 Pro 25H2. ARM tests on Apple M2 running Windows 11 Pro 25H2 ARM via Parallels.

Methodology: Each function runs in a tight, vectorizable loop (if the compiler takes advantage, which ours does.) Each processes an array of 10 million elements with random double values. Only the loop running the math operations is timed; the initialisation plus use of the results (to avoid the loop and results being optimized away) are outside the timing. Read more about the methodology here.

The reference compiler is normalized to 1.0. All reported results are expressed as multipliers relative to this baseline (for example, '4x faster' means four times the performance of the normalized compiler).

Win32

Oxygene Win32 (SSE2 default): 4.2x faster than Delphi Win32

Win64

• Oxygene Win64 v2 (default): 2.3x faster than Delphi Win64
• Oxygene Win64 v3 (AVX2): 5.5x faster than Delphi Win64
• Visual C++ Win64 AVX2: 2.7x faster than Delphi Win64

At our default settings we're roughly on par with Visual C++. With AVX2 targeting x86-64-v3, Oxygene is noticeably faster than VC++ also targeting AVX2.

Windows ARM

Delphi doesn't compile for Windows ARM, yet. If you have a Delphi Win32 or Win64 app running on Windows ARM, it's using Microsoft's Prism emulator to translate x86 instructions on the fly.

Oxygene ARM64 native: 11x faster than Delphi Win32 under emulation

This is not only the difference in using a highly optimising compiler, but it is also the difference between running translated code and running native ARM code.

Beyond Performance

Performance is what this post is about, but it's not the only reason to consider Oxygene.

Oxygene brings modern language features to Object Pascal: tuples, async/await, nullable types, soft interfaces, and more. You can use C# alongside Pascal in the same project. You can target platforms Delphi doesn't support: Windows ARM64, WebAssembly, Linux ARM, tvOS or watchOS...

If you've been looking for a way to modernise your Pascal development, a toolchain you can invest in that keeps up with current hardware and language design, Elements is worth evaluating.

The Practical Side

These are best-case numbers, i.e. tight loops of floating-point operations. Your real application probably doesn't consist entirely of sin() calls. But if you have code that does data processing, scientific calculations, signal processing, or anything else numerically intensive, you'll see real improvements.

The difference between "this calculation takes 10 seconds" and "this calculation takes 2 seconds" is highly noticeable.

In addition, instruction set supports means this applies to all code. Not just math code. Your string processing, or anything else, will be built with the same optimizing compiler that uses fast instructions and heavy optimization – just like C++, Rust, or Swift.

Try It Yourself

If you're curious:

1. Download Elements (there's a 30-day free trial)
2. Import your Delphi project: File > Import (Water on Windows, Fire on macOS, plus VS); the very first time, it will also import the VCL etc packages for you. At 4 seconds each for over a hundred, possibly for multiple bitnesses, it takes a few minutes. After this once-off step they'll be available right away for every other Delphi project you import in future.
3. Build with Oxygene targeting Island/Delphi (your imported project will be configured for this already)
4. Compare

Your VCL code works, your Object Pascal works; the difference is what happens at compile time.

This – modern CPU support, fast code – is the kind of work we do in Elements. If you try it, I think you'll find what it shows.

In our view, this work strongly supports Delphi by providing what it does not have inbuilt, whether that's platforms, compiler behaviour like optimizations or fast math, or language features. A compiler is just a component of your development environment, and since its beginning thirty years ago, Delphi has been all about replacing inbuilt components with third party ones: doing so is intrinsic to Delphi development and a big part of the Delphi ecosystem. Our suggestion you use Elements to compile means we directly recommend and support using the VCL and other Embarcadero technologies.

We are grateful to Embarcadero for their support as a tech partner ❤️, and hope our value for the Delphi ecosystem really shines 🌟.

We recently upgraded Elements' LLVM backend and, while we were there, got curious about our math performance. We had our own implementations of sin, cos, exp, and the rest, which were correct, but modern instruction sets offered an opportunity we hadn't yet taken.

We looked at what other toolchains did to get better math performance than the system libm (libmath, ie, inbuilt C RTL.) Our toolchain does not use the system C runtime in general, so we don't delegate to it, even for math.

Among other things, when researching, we found that Rust developers who want vectorised math or to not rely on the system libm can use SLEEF. It's open source, accurate, fast, and supports multiple instruction set levels.

We prototyped it. Got some exciting numbers. We integrated it.

There are not many math libraries of this calibre. There are others: GPL-ed, or commercial, or Intel-only, or ARM-only. SLEEF is absolutely amazing.

The results were significant enough that we wanted to share what we did and why it works.

What We Changed

Two things, which complement each other:

1. A new math library

SLEEF provides vectorised implementations of common math functions (sin, cos, tan, exp, log, pow, sqrt, and so on.)

What does vectorised mean? Rather than processing one value per CPU instruction, a vectorised operation processes multiple values at once. Modern CPUs have wide SIMD registers: 128-bit, or 256-bit with AVX2. A 256-bit register holds four 64-bit doubles, so a single instruction can process four values at once. This is how you get significant speedups on numerical code.

Taking advantage of this in general requires an optimising compiler that uses newer instruction sets – see the next section ;)

Sleef supports both Intel and ARM, and has both scalar (ie normal one by one) and vector (several at a time) versions of math operations. Its scalar functions can dispatch, that is, check the CPU and call a different internal implementation at runtime depending on what your CPU supports.

Its vectorised methods do not: you need to call and link the right ones depending on the target CPU.

Rather than building the math library multiple times for a target (like x64 with multiple levels of instruction sets) instead we use LLVM's support for vectorised math libraries, plus instruction sets, so that a version of the library - IslandMath.lib - contains all the various variants, and at compile-time/link-time our compiler instructs which set to use. This requires really tight integration with LLVM, including:

• LLVM's target CPU, and CPU feature set (supported instructions LLVM is allowed to use)
• LLVM intrinsics (because an intrinsic for trunc, say, needs to be able to be converted to this method call – including taking the intrinsic and using it in vectorised form)
• and LLVM's inbuilt awareness of math libraries: large tables of operations, widths, instruction sets, and methods to link to.

Thus we have a chain. In reverse it is: LLVM (target CPU and feature set, intrinsic, math library support) ⬅️ Elements compiler (specifies target CPU, specifies microarchitecture) ⬅️ EBuild build system (handles projects, passes the compiler its settings, handles automatic references to the math library.) Quite a bit to implement.

For your apps, IslandMath is an implicit reference. Our build system, EBuild, links it automatically. It is visible in the IDE: you always see what is being referenced and linked to in the Water or Fire IDEs, even if it's automatically managed.

2. CPU target selection

You can now tell Elements which CPU level to target:

• 32-bit Windows: Pentium 4
• 64-bit Windows: Choose x86-64-v1 through v4 (corresponding roughly to ~2000, ~2008, ~2013, ~2017 eras)
• ARM64: We handle this internally. Apple Silicon gets M1-specific targeting; Windows/Linux ARM gets generic ARM64.

Our default is x86-64-v2 for 64-bit, and 32-bit uses SSE2: conservative choices that work on any reasonably modern hardware.

These features enhance each other. When you target x86-64-v2, our math library uses SSE2+SSE4.1 implementations. When you target x86-64-v3, it uses AVX2+FMA implementations, which means 256-bit wide operations instead of 128-bit. More data processed per instruction means faster execution.

We also tuned our LLVM passes for better vectorisation. By customising passes, as well as customising how passes worked, we were able to ensure more code patterns that could be vectorised actually were vectorised. We believe this is similar to how the Intel C/C++ compiler works, which was famous for performance and we understand – don't quote us – made a similar set of analyses. It certainly worked for us.

The Results

We benchmarked 21 math functions (the standard C RTL set: sin, cos, exp, log, pow, sqrt, etc.), each running 10 million iterations on arrays of 64-bit doubles. We compared Elements to Visual C++ 2022 and  Delphi 13, running on the same hardware.

Hardware: Intel Tiger Lake i7 (2.80 GHz), Windows 11 Pro 25H2. ARM tests on Apple M2 running Windows 11 Pro 25H2 ARM, via Parallels.

Methodology: Each function runs in a tight, vectorizable loop (if the compiler takes advantage, which ours does.) Each processes an array of 10 million elements with random double values. Only the loop running the math operations is timed; the initialisation plus use of the results (to avoid the loop and results being optimized away) are outside the timing. Where possible, i.e. for Elements, we looked at the IR to verify the code was behaving as we expected. We report the geometric mean of per-function speedups across each toolchain, which gives a single representative number that isn't skewed by outliers.

Win32

What we haven't added here is Visual C++'s SSE2 support (see below, roughly the same as the Win64 chart), where they are a shade faster than us, gosh dangum darn it. ...but wait, Win64 is another story entirely. Oh boy:

Win64

Compared to Delphi Win64:

• Elements Win64 v2 (default): 2.3x faster
• Elements Win64 v3 (AVX2): 5.5x faster
• Visual C++ Win64 AVX2: 2.7x faster

At our default settings (x86-64-v2), we're roughly on par with Visual C++: as noted, their SSE2 support is a shade faster than ours. (Compare the Elements x86-64-v2 bar on the chart above with the VC++ SSE2 bar: 2.27x vs 2.6x.) But if you can target x86-64-v3 (most CPUs from ~2013 onwards) and compare against Visual C++ using AVX2, Elements is significantly faster than Visual C++.

Wow!

ARM64

Not all toolchains compile for ARM, and their apps run under emulation. This lets us see the performance difference from native ARM combined with our optimizations and math library:

Delphi doesn't compile for Windows ARM yet. If you're running a Delphi Win32 app on Windows ARM under emulation:

• Elements ARM64 native: 11x faster than Delphi Win32 under emulation

Why Is This Faster Than VC++?

We were curious about this too.

Our best explanation for Intel is that Visual C++'s runtime library likely doesn't have AVX2-optimised math routines, or at least not as aggressively vectorised as SLEEF. VC++'s SSE2 math is actually slightly faster than ours on a few specific functions (sqrt, ceiling, floor), but SLEEF's vectorised implementations pull ahead on the trigonometric and hyperbolic functions, and that's where the overall result (the geometric mean) wins.

This applies to all six Elements languages. We wrote the benchmarks in Oxygene (Object Pascal), but that's the compiler frontend layer: the backend where this takes effect is the same for C#, Swift, Go, Java, and VB.

Practical Impact

These benchmarks are tight loops of floating-point math, ie the best case for this kind of optimisation. Your real-world app probably doesn't consist entirely of math. Yet, your real-world app will have many parts that benefit from the optimizations we offer outside of math.

That said, if you have code that does real number-crunching (data processing, simulations, engineering calculations, audio/video processing) you'll see meaningful improvements. The difference between "my app processes this in 10 seconds" and "my app processes this in 2 seconds" matters.

Try It

This – performance, modern features and settings, deep-in-LLVM engineering – is the kind of work we do on Elements. If you try it, I think you'll find it shows.

This week's build of Elements 12, build .3047, introduces a major new feature for the Oxygene language: Raw Strings. Raw strings are a new way of declaring string literals that make it easier to define more complex strings without worrying about escaping things such as quotes or curly braces.

Raw strings can come in two forms that behave similarly in most ways: single-line raw strings and multi-line raw strings. Any raw string literal starts with one or more hash symbols (#) followed by one or more double quote symbols ("), and all raw strings support interpolation with curly braces ({).

Single-line Raw Strings

A single-line raw string starts with the opening sequence (#" or a variation thereof), is followed by one or more non-quote characters, and then terminated by the same number of quotes that started it. Inside the literal, quote (and hash) characters can be used at will, as long as they are fewer than the quotes in the opening sequence, and they are not the first or last character:

var x := #""He said, "Hodwy!"."";

In the above example, the opening sequence has two quote marks after the hash: #"". This means the string will continue until another set of two quotes is encountered. Using single quotes inside the literal, like around the "Howdy", is fine, and they do not need to be escaped.

This works for any (reasonable) number of quotes:

var y := #"""""Want four quotes? why not!"""". It's fine!""""";

Note: For ambiguity reasons, a single-line raw string cannot be empty, as it would be impossible to tell whether it's just starting, or done. But then, an empty raw string is pointless – just drop the # and make it a regular string literal ;).

A single-line raw string must be terminated on the same line that started it (duh! 🙃).

Multi-line Raw Strings

A multi-line raw string starts with the same opening sequence (#" or a variation thereof), immediately followed by a linebreak. No non-whitespace characters may follow on the same line, not even comments (comments inside a string aren't comments, anyways ;).

The actual content of the string literal will start on the next line, and may continue across as many lines as needed to express the string you need.

The closing sequence – the same number of quites that started it – must follow on its own new line, preceded by nothing but whitespace:

var z := #""
         As the water flows over the bridge
         As we walk on the floodland
         As we walk on the water
         We forget
         We forget
         Rain from heaven 
           - The Sisterhood, "Rain from Heaven"
         "";

As before, the number of quotes in the opening sequence determines how many quotes are needed to terminate the string (here, two, therefore, the individual quotes on the last line are accepted as part of the string).

Multi-line raw strings have one additional special behavior, and that is the trimming of leading whitespace. The compiler will look at the number of spaces (tabs count as two spaces) in front of the closing quotes ("";), and remove the same number of leading spaces from the beginning of every line in the string.

As a result, even though the string is indented in code to match its surrounding – loosely suggested by the length of the var z := – the lines of the lyrics will have no indentation in the final string, and the last line of attribution will have only two spaces of indent.

This means you no longer need to have your multi-line strings stick oddly to the left edge of your code, defying the indentation of its surrounding code.

Note: All lines of the string must be indented at least as much as the closing quotes. If a line "sticks out" to the left, the compiler will emit an error.

Also note that the string literal shown above does not include a leading or trailing line break. It starts with A and ends with ". Of course, empty lines can be added at the start or the end of the literal, to add additional linebreaks. The string literal will also not include any trailing whitespace on any line.

Interpolation in Raw Strings

All raw strings support interpolation, similar to the existing interpolated strings starting with $" that Oxygene has supported for a while.

Just like the number of starting quotes indicates how many quotes end the string, the number of hashes (#) indicates how many curly braces ({/}) are used for interpolation:

var a := #"It's {time} o'clock.";

In its simplest form, a single curly starts and ends interpolation, just as you're used to from classic interpolated strings. In fact (with a couple of small caveats noted below), you can probably change most of your interpolated strings over to raw strings, just by replacing the $ with a #.

What if you want literal curly braces in your string... literal? No problem, just use more than one # in the opening sequence, and you can have as many as one fewer consecutive curly braces in your string, anywhere. Need some inline Json, for example? easy:

var j := ##""
         { 
           "Title": "IT", 
           "Author": Stephen King",
           "Published": 1984
         }
         "";

Need more than one? Also no problem:

var k := ###""{{Hello in double curlies, {{{lName}}}}}"";

Here, the double curlies at the start are kept literally, but the triple curlies near the end will treat lName as interpolated code.

If a literal contains more consecutive curly braces than needed to start an interpolation, the additional curly braces are kept literally:

var l := ##"keep a curly here: {{{5+3}}}"; // "keep a curly here: {8}"

Note: as mentioned before, there are a couple of small behavioral differences between interpolated raw strings. These are especially important to keep in mind if you are changing your $" strings to #" for consistency:

In classic $" interpolated strings, two {{ would be used to "escape" the interpolation. Raw strings do not do escaping like that, so you'd want to use  ##" instead, to have single-curlies in your literal without the need to escape them:

var x := $"{{keep one curly}"
// equals:
var x := ##"{keep one curly}"

Also, classic $" interpolated strings (and non-interpolated strings with double quotes) may contain linebreaks at any point, and will preserve all leading whitespace. Raw strings, as outlined above, will not, and must start on a fresh line, if they are multi-line:

var x := $"this
 is fine";
// equals:
var x := #"
         this
          is fine
         ";

Editor Support

The code editor in Fire and Water has been updated to visually highlight (or rather, lowlight) the curly braces "swallowed" by the interpolation. Especially when you're surrounding interpolations with additional curlies, this is a helpful visual aide:

Also: Delphi Multi-line Strings

It's worth mentioning here that a short while ago we also added support for Delphi's new multi-line string syntax, for compatibility purposes. Delphi multi-line strings start with an odd number of three or more single quotes ('), and end with the same amount. Similar to Oxygene's (and C#'s) raw strings, they too require the content of the literal to start on a new line, have the closing sequence on a new line, and will remove any leading whitespace. They do not support interpolating.

var d := '''
   Delphi's multi-line
   string syntax 
   is supported too
   ''';

Get Elements .3047 Now.

Elements build .3047 – with the new Raw Strings on Oxygene and much more is available on the Stable channel now, as free update for all customers, and as free trial download for new users.

Enjoy!

A few months ago, we previewed an AI coding assistant for Delphi called CodeBot at Embarcadero's AI Code Camp. In October, we gave a preview of an early alpha to the attendees at EKON. On January 13th Embarcadero and RemObjects will have a special webinar on CodeBot, including info about the beta!

Join live on Youtube here – no registration required!
Tuesday 13th January, 12 midday US Central, 6PM UTC.

And we have a teaser for it:

We're really looking forward to this webinar – don't forget to sign up for CodeBot updates at the bottom of this page!

From all of us here at RemObjects Software, we would like to wish you Merry Christmas, Happy Holidays, and a Happy New Year!

2025 has been an incredible year for the company and for our products. We have expanded our team, shipped countless updates to all products with many exciting new features, as well as launched the first brand new product in a few years. And our Oxygene language has seen its twenty-year anniversary this past year!

We're still just getting started, and we can't wait to share with you what's coming next!

See you in 2026.

Take care
–marc

This weeks build of Water, our Windows IDE for Elements adds an exciting new visual feature that many of you have been asking for for a long time: themes!

On the Fire side, we have had support for light mode and dark mode for a while, including dark (and light) editor color themes that force the IDE into dark (or light) mode, as well as the default theme which adjusts with the system.

Folks on Windows, using Water, have been stuck using only the light editor themes, because the rest of the IDE was not made to go along with (or look good) in dark. No more!

First, there's now the Black theme. Same basic colors as White, but the entire IDE is in dark mode, for the nightowls:

If you don't like it quite as dark, there's also Dark Gray. It's very simialar to the existing Light Gray editor theme, except the rest of the IDE gets themed – well – dark, rather than staying white:

For a bit of nostalgia, check out the the Turbo Pascal 2 theme takes you back to the 80s, with a dark IDE and, gray and yellow text on pitch-black. If I could stand to work in dark mode myself, this one would be my go-to:

We've also added a Monokai-inspired theme, for those of you who are more down to earth(-tone colors), or used to the color theme from other editors or IDEs.

Finally, the entire IDE also gets a retheming for the existing Pink Dream theme we introduced a few months back:

Each theme expands thruout the entirety of the IDE, including secondary windows such as the Preferences sheet here:

Themes are available in Elements .3041 today. As always, this build is a free update for all active subscribers. Get your copy now!

I am super thrilled to announce the release of our next brand new product here at RemObjects: GitBrowser.

GitBrowser is a native Git version control client for the Mac that aims to be easy and comfortable to use for beginners and Git experts alike, and to make the most common day-to-day version control tasks of developers not just easy, but fun.

Like our other tools, GitBrowser focuses on not getting in your way, and being lightweight, as well as intuitive and quick to use. Is has a major focus on working with multiple (dare I say, many) different Git repositories at once – a main feature I found lacking in most, if not all, other popular Git clients, but it will still be a faithful companion if you only work on one or two Git repositories at a time.

When you first start GitBrowser, it will ask you to add one or more local Git repositories to it. You can do so with the "Browse..." button on the Welcome sheet, or you can drag your folders in from Finder (or anywhere else) to the sidebar, at any time.

The sidebar always gives easy access to all the repositories you work with. You can arrange them in groups, sort them as you like, and even give them custom names. Selecting a repository in the sidebar immediately activates it and allows you to work with it. And you can even perform actions on any repository (active or not) from the context menu. Of course, you can hide and show the sidebar by pressing ⌘1, at any time.

The center column of GitBrowser shows the version history of your repository. All commits of your current branch are listed, with local commits that still need to be pushed shown in bold at the top, and any remote commits you have yet to pull shown in italic, above them. In addition to date color-coded author and commit message, the commit log also indicates any tags, and highlights merge commits in blue.

Select any commit, and the right-hand pane of GitBrowser will show its details, with the list of files affected by the commit at the top, and an inline diff view of the selected file at the bottom. Switch between files to browse all the changes of a commit.

Of course, sometimes you want to explore a changed file in more detail. Simply double-click a file, and GitBrowser will open it for comparison in your favorite diff tool (currently supported are Araxis Merge – IMHO the gold standard of diff tools, and my personal favorite – as well as BBEdit (yes, BBEdit has a diff viewer built in!). More options will be added based on user feedback, so let us know what your favorite diff tool is!)

The commit log has one additional row at the very top, and that is your local changes. Depending on the local status of your work, it might show "No local changes.", or a summary of locally changed, added, or deleted files. Selecting this row will show you GitBrowser's staging area in the right-hand pane

The staging area looks very similar to when you were viewing a previous commit, but it instead shows your local changes and – well – allows you to stage them for commit. In the file list at the top, you will see all files that have local changes, as well as any new files that are not under version control yet. You can check or uncheck the checkbox at the very right to stage (or unstage) one or more files. You also have more options available – such as stashing away changes for later, in each file's right-click context menu.

If you select a file, you will see the local changes in the embedded diff view at the bottom, just as before. This make sit really easy to double-checkl them all before staging – a practice i highly recommend.And of course you can double-click the file to open itn in Araxis Merge or BBEdit, to explore the diff in more detail.

If a file has both staged and unstaged changes (e.g., you staged it, and then made more changes – indicated by the checkbox showing in intermediate state), it will open as a three-way diff in Araxis Merge, showing you the original, the staged changes, and your local changes compared.

To commit your staged files, simply type in a commit message and then click the button. You can also press ⌘Enter+Up to commit and push in one go.

Are you sometimes bored with writing commit messages from scratch? GitBrowser can do it for you! In the Settings window (⌘,) you can connect GitBrowser to your favorite AI account. Once you have done so, all you need to do is mark a file (or several) for staging, and GitBrowser will automatically get busy and, within a second or so, prefill the commit message field with a (usually pretty good!) summary of your changes. You can accept the message as is, tweak it, or, of course, just write your own to replace it.

GitBrowser can use OpenAI, Claude, Gemini, Grok and Mistral as AI provider, as well as a local LM Studio (same as CodeBot in Fire)

Some more niceties and small details...

• You can press cursor-up/down in the commit message field to easily "recycle" one of your previous commit messages. Very handy if you're making multiple related commits, or following up on a previous change. (cursor-up/down works if the field is empty, or the current message is AI-generated). You can also right-click any commit in the commit log to reuse its message.
• GitBrowser lets you easily pull all your repositories (or all in a group) from the "File" menu, or the sidebar's context menu. Nice when you come in in the morning and get up to date with what the rest of the team(s) have been up to.
• GitBrowser finds Elements solutions in your repository and lets you easily open them in Fire from the context menu in the sidebar.

• Press ^⌥⌘F or ^⌥⌘T at any time to open your repository folder in Finder or Terminal, respectively.
• You can drag any file from GitBrowser to copy or open it. Dragging a file from a previous commit will automatucally extract that revision. You can also drag your repository folders from the sidebar, e.g. to open them in BBEdit or other folder-based tools.
• The diff view shows tabs as 8 spaces. This is on purpose, as it makes it really stick out if your file accidentally mixes tabs and spaces form indentation (something that of course cannot happen if you use Fire ;).
• You can swicth between local branches (and check out new remote ones) from the braches popup button in the toolbar. Local branches eill show in bold, if they are ahead of your current branch (i.e. has new stuff your).

... and much more.

In Summary

Version control – and let’s be honest, today that means Git – is (or should be) an essential part of every developer’s workflow, and it all stands and falls with having a great tool that makes version control easy and – dare I say – fun, rather than a chore.

For me, for the past three years, that tool has been GitBrowser, and I would not want to miss it. Which is why i am so excited to now be able to share it the rest if the world – and for free, no less.

Please remember: the goal of GitBrowser is to make the common, routine, every-day tasks of version control easy and intuitive. Pull, push, review tour changes and commit them, review what your team is up to, etc. It is not meant to be the and-all swiss army knife for all your advanced Git needs, and it currently does not replace falling back down to the Git command line for more complex and esoteric tasks – nor will it ever, probably.

As time goes by, we will add more and more functionality to it to make these common day-to-day tasks easier, and to cover more common tasks that GitBrowser currently maybe does not handle yet (includindg, yes, some very obvious ones still missing). Please let us known in the forums what you're missing, or what you'd like us to add.

Get Your Copy, Now!

GitBrowser is available now, as free download, at remobjects.com/gitbrowser. It is completely free, but it does require you to sign up for a free license, after a 30-pday trial period, available.

If you have any questions, suggestions, feedback or complaints, please let us know on our support forum, RemObjects Talk, at talk.remobjects.com/c/gitbrowser

I hope you enjoy using GitBrowser as much as I enjoyed creating (and using) it, every day!

Nov 14 marc hoffman b7f6b866707aff6ea80e0cf591377285bd781dfc GitBrowser: GitBrowser 1.0 📌 .237
...
2022 Nov marc hoffman bd7a07cfffe2b0c60f78951319c951b7f26f6ba1 GitBrowser app (wip)

This week is the Android release for Elements.

I'm a bit ashamed to admit that over the past couple of years, we have been neglecting the Android toolchain a bit. Google introduced some significant changes to their tooling a while back, including the new d8 engine for converting Java byte code (which our compiler for Java and Android emits) to Android's Dalvik bytecode, and the new aapt2 tool for processing resources – a very messy system on Android, if you ask me.

These new tools broke a lot of things, and their usage (outside of Google's own Gradle build toolchain) wasnt'/isn't very well documented, and at some point we just kind of threw the towel 🤷‍♀️. Simple Android apps are still built, but anything more complex depends on dependencies and resources had problems getting past aapt2.

Over the past month or so, I've been working on the side to bring one of my personal pet projects back to life. At first, the plan was to only focus on the iPhone version (done and done), but my partners in crime at the Meteorological Department Curaçao convinced me to also take another stab at reviving the Android version – Android being a very popular platform here.

Just like with iOS, this started by taking a deep dive into our Android toolchain in EBuild, and making many improvements. And i'm happy to say that with the help of a good friend, I was able to finally sort out all the intricacies with getting aapt2 and the rest of the gang to work as they should, and consistently. This involved improvements and fixes to

• Gradle/Maven package resolving
• Pre-processing of resources from .aar ("Android Archive" – essentially a .zip with a .jar, resource files, and other stuff)
• Pre-converting ("pre-dexing") external .jar references
• Build caching
• Packaging the final product
• ...and more.

In the end, my existing (at this stage, pretty old) app once again builds okay – with virtually no changes to the code needed, so I'm now ready to work on it again.

Android Push Notifications

With that out of the way, I set out to do one more Android-related task that I had been postponing for a long time, and that is implementing a clean system for Push Notifications for Android – which leads me to a small teaser for an upcoming new product.

When I first started working on Curaçao Weather, almost 10 years ago now, one of my goals was to make the app essentially "serverless". Yes, there is a server component that performs regular, scheduled processing of data (such as gathering weather data from multiple sources and putting it into a consistent format that the app can rely on). But the app doesn't talk to that server. Instead, all the data is stored in a semi-public S3 bucket whenever the processing runs, and the app can just download all the information it needs from there. I simply didn't want to worry about scaling issues (even though I am, of course, sure our software stack can handle them – it's what it was designed for, after all). But just plain static HTTPS removed a lot of that complexity.

But there were two features we couldn't handle with just that, and those were letting users send reports for weather impacts from the app back to the server occasionally, and – more importantly – handling Push Notifications.

Being a big fan of Amazon AWS in general (we use it for all our hosting, and much more), I turned to two solutions provided by AWS for solving this – even though I was reluctant to rely on third-party abstractions like that, and would end up being proven right.

AWS provided/provides abstracted support for cross-platform push notifications that merely required some (convoluted) setup on their system, and use of Amazon's client library inside the app – both on iOS and Android.  The system worked well... until it didn't, some five years ago, when it just stopped working. And, being a convoluted abstraction on top of many lower-level AWS systems, it was impossible to get to the bottom of it – so I scrapped it all, and implemented Push myself (something I had done before), but for iOS only.

I still liked the idea of being "serverless" for this app, so I thought: if I did have to create a server for the app to talk to, why not make it a general-purpose server for any app that needs similar functionality?

And with that (and some other ongoing projects), a new set of twin projects had been born:

Quantum Server & RemObjects Infrastructure

QuantumServer and RemObjects Infrastructure are two new products we have in the works, and they are, if you will, flip-sides of the same coin.

RemObjects Infrastructure is a set of Enterprise-level libraries (primarily for .NET, but some cross-platform) that implement functionality commonly needed in enterprise server back-ends. It includes things such as login and identity management, abstracted file storage, Push Notifications and email, AI model access and AI chat, and much more.

It builds on top of Remoting SDK and Data Abstract (where applicable), built on Oxygene, and is meant to be used by developers creating their own backend. While not publicly available yet, it has been successfully deployed by a range of initial development partners who helped drive its development. CodeBot in Fire and Water is also built on the AI layer provided by Infrastructure.

It is also the foundation of Quantum Server.

RemObjects QuantumServer is a stand-alone precompiled server application that exposes (or will expose) much of the functionality provided by Infrastructure, but without the need to build your own backend. You just install and configure it, then focus on creating "client" applications that can depend on it.

Curaçao Weather was one of the first projects to use QuantumServer, and now uses it for Push Notifications on both iOS and Android, as well as "dead drop" for one-way delivery of reports users want to share with the weather department.

As a result, I was able to drop any third-party dependencies on the AWS client libraries and similar components from the app.

Read more:

• Curaçao Weather App (iPhone/iPad/Mac app is available now, Android will be back in the store soon)
• Vision Thing B.V., the company behind it (and some other cool apps)
• RemObjects Infrastructure teaser page (stay tuned for more details)
• QuantumServer teaser page (same)
• and of course Elements, the toolchain that makes it all possible