Announcement

Collapse
No announcement yet.

Facebook Is JIT'ing C++ Code To Treat It Like A Crazy Fast Scripting Language

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • throwaway209
    replied
    Originally posted by tuxd3v View Post
    That is one option indeed, since 1991.
    Another option is Lua, since 1993..

    Speaking About Lua,
    You already have:
    Luajit,
    About that... This was created to replace LuaJIT. Along with solving code reuse from a huge repository (in C++), debugability, and testability issues, the result in production is 4X faster execution of L7 handlers that were previously implemented in Lua and executed by LuaJIT.

    Leave a comment:


  • fulalas
    replied
    It's ironic that Facebook is trying to optimizing something by choosing another language. The same company that writes probably the worst softwares in terms of performance/usability; not just Facebook website, but also Instagram and WhatsApp. The amount of garbage they are pushing into their softwares are simply ridiculous.

    Just to give you an example: open any Instagram page, go to the source file and check for all JavaScript files/embed. It's around 90! This is insane. Endless requests, terrible interface, bad performance, omnipresent surveillance. And this is one of the most successful websites in the world.

    Or maybe I'm just reading too much things like this: https://tonsky.me/blog/disenchantment/

    Leave a comment:


  • audir8
    replied
    Originally posted by thebear View Post
    One does not necessarily need to deal with the cruft, xeus-cling is on conda-forge and can even be tried out in the browser (just click the binder link in the README here: https://github.com/QuantStack/xeus-cling)
    Thanks for the link.

    Leave a comment:


  • audir8
    replied
    Originally posted by Jonjolt View Post

    If it's got a front end for LLVM then Oracle is here to ruin your day https://www.graalvm.org/docs/referen...anguages/llvm/
    This still requires AOT compiling, atleast for C++ though clang.

    Having a REPL and JIT means you could have a C++ Jupyter kernel, or have HL-style consoles in whatever you wanted easily.

    Leave a comment:


  • Jonjolt
    replied
    Originally posted by uid313 View Post
    What's next?
    JIT for ALGOL, COBOL and Fortran?
    I would not want C++ as a scripting language.
    If it's got a front end for LLVM then Oracle is here to ruin your day https://www.graalvm.org/docs/referen...anguages/llvm/

    Leave a comment:


  • audir8
    replied
    It doesn't seem like this is a very generic implementation... But, a C++ REPL would be interesting, and Facebook's use case makes sense. LuaJIT might have some competition if this ever makes it as a open source project, even if only a reduced subset of C++ is supported.

    Leave a comment:


  • kpedersen
    replied
    Originally posted by soulsource View Post

    It seems I'm not getting what you mean with "scripting language" in that context. UE4 can be "scripted" with C++ just fine - everything that's exposed to blueprint can be called from C++ as well.
    I think you are using the term "scripting" in a Unity-like way, which is really more akin to "automation".

    The difference between them is subtle (and with modern technologies the gap is closing) but check out: https://www.geeksforgeeks.org/whats-...ming-languages

    C++ is not a scripting language in UE4. Each time you modify the code, the executable is built and relinked. We have hotplugging to help but effectively there is no "script environment" isolating your code and the engine. If you dereference a NULL pointer for example, the entire application crashes. This issue has given rise to questions such as this: https://www.reddit.com/r/unrealengin...dering_adding/

    Unreal Engine did have a scripting language called UnrealScript (Kismet 3). And now Blueprint (Kismet 4). C++ has never been intended as a scripting language; probably due to its upfront compiled nature and limited hotplugging.

    In some ways I do kinda see that with engines like Unity or UE4 most people are not actually "programming", they are "automating" but there is traditionally quite a difference between a scripting language and a programming language. There is also a good use-case for both.

    You can script with .NET (as with Unity) because the .NET VM creates that isolated environment I mentioned earlier. Any errors in your code takes that out but leaves the engine standing (or at least if Unity wasn't such a crashy piece of broken consumer sh*t, it would XD)
    Last edited by kpedersen; 04-29-2019, 06:46 AM.

    Leave a comment:


  • soulsource
    replied
    Originally posted by kpedersen View Post

    I believe Live++ is Windows only (and worse, Microsoft VC++ specific :/, though Clang support is being worked on).

    It speeds up the compilation time but I don't think it would ever be suitable for a scripting language.

    If they could use C++ as a scripting language, it could remove the need for Python and others, etc. It would keep things homogeneous and "simple".
    It seems I'm not getting what you mean with "scripting language" in that context. UE4 can be "scripted" with C++ just fine - everything that's exposed to blueprint can be called from C++ as well.

    Leave a comment:


  • uid313
    replied
    What's next?
    JIT for ALGOL, COBOL and Fortran?
    I would not want C++ as a scripting language.

    Leave a comment:


  • tuxd3v
    replied
    Originally posted by Jonjolt View Post

    I wouldn't say that yet, a good JIT could do PGO, it could ultimately get C++ with all the batteries included higher level constructs to run closer to C speed.
    That is true, but only wen everything runs well..
    A good PGO Jit, could also kills your application performance..

    In that case, C++ will have bash interpreter like performance..

    Leave a comment:

Working...
X