Hacker News new | past | comments | ask | show | jobs | submit | speed_spread's comments login

It's like binoculars, The brightest minds see further but they also have immense blind spots that leaves them exploitable.

Would it possible to AOT-recompile from x86 to aarch64? Or will it all be emulated forever?

Yes i dont see why not. At least on the surface technical level.

I used to work at ms on xbox backcompat games and we AOT recompile PowerPC arch to x86. (Xbox 360 to Xbox one).

You could likely aot recompile any arch with enough resources to fix up issues and things.

One key difference is older games were fixed so no more updates. It can be a little trickier with modern games still taking updates but could be done.


Not possible to fully AOT for all applications because you don't know which ones do JIT compilation to generate x86 code at runtime. Many games make use of LuaJIT, for example.

LuaJIT would also work with ARM though, so would it be possible to swap it out?

Indeed, LuaJIT support for Windows/Arm64 was added in https://github.com/LuaJIT/LuaJIT/issues/593, and there’s experimental out-of-tree support for Windows/Arm64EC in https://github.com/LuaJIT/LuaJIT/issues/1096

Swapping out is possible only if there are shared libraries though.

For statically linked programs is there anything that can be done?


Very likely yes (Rosetta for the Mac already does this), but the big issue is that a ton of Unity games use JIT compiled Mono, and that would require dynamic recompilation, which as we've seen with Rosetta, would lead to terrible realtime performance

Rosetta does do AOT recompilation when it can.

Windows already AOT compiles x86 binaries to ARM64 when they are built with /ARM64EC option. It doesn't support AOT for older executables yet.

ARM64EC requires source and it produces an ARM64EC executable, which runs close to ARM64 speeds. x86/x64 executables are emulated.

Just to clarify: yes, it requires the source AND re-building it. But, with a simple switch, you make your x86 code JITtable on ARM64. That's why it runs at native ARM64 speeds. Sometimes, you can't build natively for ARM64 due to some dependency, and this allows portions of your code to be faster at least.

Otherwise, if you have the source AND budget to rebuild, just build it natively for ARM64 of course :)


ARM64EC doesn't really make your code JITable. It is ARM64 code with thunks to enable transitions to x64 code. That's why it runs at near native speeds; not because of the JIT. The x64 portions of the binary do get JITed though, but the ARM64EC portions are usually much faster.

All x64 code gets JITed but that's regardless of whether ARM64EC is used or not; ARM64EC allows ARM64 applications to interface with x64 binaries.


Okay, I had assumed JIT for x64 wasn't possible (yet) and ARM64EC enabled that partially. So, ARM64EC images are actually native ARM code that can interact with emulated (+JITted) components. For some reason, I thought native ARM64 binaries already had this capability, but they don't. Thanks, that's actually a better state of affairs in Windows on ARM land.

Yes, that's correct! Unfortunately ARM64 can't fully interface with x64 code (e.g. you can't translate an ARM64 CONTEXT to an x64 one directly due to differing numbers of registers), so the backwards compatibility is restricted to ARM64EC only.

Oh shoot, it's happening for real, /r/programmingcirclejerk is leaking back to HN. The great unraveling has begun, we're all doomed!

Too bad there's no details on the "modern" features vs Object Pascal. Or are they hidden?

Anyway, seems interesting. I gather that their business model is to find large institutional customers looking for a way to scale out their legacy code (Delphi, etc.) to new platforms?

I wonder where they find developers willing to learn their tools when the entry price to learn is non-free. Also, a closed ecosystem nowadays means depriving the devs of the rich ecosystems that have grown around open languages. Which can be a good thing... (looking at npm, ahem)


The new features are hidden in the documentation https://docs.elementscompiler.com/Oxygene/Delphi/NewFeatures...

Given that it doesn't support vcl I don't see a reason to ever move to it for existing delphi applications which I assume are mostly fat clients.


It's funny that they named "nil"lables "nullable".


Consider Phlebas is interesting and funny but is also a disjointed mess compared to later works. It reads like an Indiana Jones movie, it's entertaining but doesn't give that much to reflect upon once you've finished it.


If it doesn't give that much to reflect upon, then you didn't read it very carefully.

How about reflecting upon Horza's reasons to side with the Idirans? The later installments of the "Culture" novels are in comparison just the empty triumphalism "Rah rah rah, the good guys won and lived happily ever after."


This amounts to the machine equivalent of "you can't beat stupid". Even once server LLMs start accounting for possible chatbot nonsense, all that'll be required is to move to a very cheap client LLM to generate word soup. At a certain point, it will be impossible to reliably distinguish between a dumb robot and a dumb human.


What is it with USB drives that bothers you people so much? It's just storage. Apps could also come from a cloud drive, which would be no more dangerous.

All I hear is "ewww, physical media!"


It's not about USB. It's about executables, and syncing-over-cloud is equally dangerous w/ executables. Perhaps, syncing is worse than USB, because it will write executables right into your home directory, which isn't mounted with NOEXEC flag, where USB would be mounted with it by default (depending on the policy).

Security-wise, copying executables b/w systems amplifies the risk of escalating partial write access on one system to full system access on many other systems. This would be an easy building block for "Advanced Persistent Threat"[1] attacks.

[1]: https://en.wikipedia.org/wiki/Advanced_persistent_threat


Yes, only bad things.


So it's the same but without type annotations? Meaning that the clojure IDE has a much harder time providing completion and that you need to write all sorts of tests to get the same guarantees as the rust compiler provides for free. Type systems aren't just about memory representation, they also tell the next programmer about the intent and performance characteristics of the code at hand.


That's why I moved from Scheme to Common Lisp, it's nice being able to do...

  (defstruct Task
    (future :type Future)
    (task-sender :type Sender))
And have SBCL warn me when I try to jam the wrong type in.


If you really badly want types, you'd slap something like this below it:

    (s/def ::future atom?))
    (s/def ::task-sender async/chan?)
    (s/def ::task
      (s/keys :req-un [::future ::task-sender]))

    (s/fdef create-task
      :ret ::task)

    (stest/instrument `create-task)
But then I don't think you'd reach for something like Clojure if static typing is something that you require.


My perception when I tried to read it was that it was just getting off it's own word soup, like I caught the author in a feverish and very private session with himself. Being somewhat traumatized, I haven't tried anything else by Stross since then. I like density but at some point, you gotta tell a story. It was obviously a secondary objective in that case.


That's a deliberate technique in prose pacing, especially common in cyberpunk and allied sf subgenres.

The basic insight is that prose which reads faster with less complexity feels faster, as if the events it describes occur at like pace. That's why a skillful writer rarely brings an adverb to a gunfight. It's also why clubs don't play melody-heavy stuff at 60 BPM, or even the liveliest among Mozart's string quartets.

The variation here discussed modifies that approach by increasing the pace and not reducing the complexity. The intended effect is more or less as you describe: to dislocate the reader among ideas and concepts that seem to flow too fast to grasp. Given what the text seeks to express in this way, the technique fits perfectly. (The novel's not called Accelerando for nothing! If you aren't familiar with that word, now may be an unusually enlightening time to become so.)

Granted, it doesn't sit the same with every reader. But it is very much the product of deliberate design, not mania, and deserves to be understood as such.

(To be clear, I don't like Accelerando; with one exception I judge it the weakest of Stross's work, and it's very unreflective of his later work with a more practiced hand. But that I don't appreciate the work isn't the same as saying no respect is due the skill and artifice that went into its making - it's a piece I don't enjoy, but not a piece that's bad.)


what were the terms and examples that feel like word soup? it has been quite a while since i read it, but i remember the ideas being quite self consistent (with some serious sci-fi conceit of course)


I don't remember a specific word or sentence being problematic, just a general torrent-of-consciousness from someone else that prevented my own brain from forming images and putting things together as I read. I felt the author was really trying too hard being edgy while at the same time not giving a fuck about the intended reader. "Look how many novel concepts per paragraph I can fit!" Huh, ok bro. Might as well just write a list...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: