[HN Gopher] Cheerp 3.0: C++ compiler for the Web, now permissive...
___________________________________________________________________
Cheerp 3.0: C++ compiler for the Web, now permissively licensed
Author : apignotti
Score : 129 points
Date : 2023-03-14 15:57 UTC (7 hours ago)
(HTM) web link (leaningtech.com)
(TXT) w3m dump (leaningtech.com)
| dang wrote:
| Related:
|
| _Cheerp: A C++ Compiler for the Web_ -
| https://news.ycombinator.com/item?id=15727346 - Nov 2017 (9
| comments)
|
| _Cheerp 1.2 - C++ to JavaScript: faster than Emscripten with
| dynamic memory_ - https://news.ycombinator.com/item?id=11018516 -
| Feb 2016 (21 comments)
|
| _Cheerp 1.1 - C++ for the Web with fast startup times, dynamic
| memory_ - https://news.ycombinator.com/item?id=10524784 - Nov
| 2015 (20 comments)
|
| _Cheerp - A C /C++ compiler for web applications_ -
| https://news.ycombinator.com/item?id=8167536 - Aug 2014 (49
| comments)
| azakai wrote:
| > Cheerp directly uses the LLVM bytecode format as the
| intermediate representation, for both object files and libraries.
|
| The paragraph with this might be a little confusing. It suggests
| that this is a benefit of Cheerp, but upstream LLVM (and
| Emscripten, which uses upstream LLVM) can do the exact same thing
| if you build with -flto to enable LTO.
|
| The benefit of upstream LLVM is that it can do both LTO and non-
| LTO builds. Non-LTO builds link much, much faster in a large
| project, since the linker is only concatenating wasm object
| files, just like a normal linker. That can matter a lot for CI
| times and local debugging etc.
| Pet_Ant wrote:
| Apparently LTO = "Link-Time Optimisation" ?
| https://en.wikipedia.org/wiki/Interprocedural_optimization#W...
| azakai wrote:
| Yes, exactly.
|
| LLVM docs: https://llvm.org/docs/LinkTimeOptimization.html
| hummus_bae wrote:
| Thanks for the input. This paragraph is indeed a selling point
| of Cheerp. "if you build with -flto to enable LTO" is only true
| if you run on Linux since LLVM LTO support on Windows and Mac
| is limited.
| smeenai wrote:
| Limited in what way? LLVM LTO works seamlessly if you use LLD
| on both macOS and Windows; that's what Chrome does, for
| example. LLVM LTO also works pretty seamlessly with ld64 on
| macOS; the linker needs libLTO, but the driver takes care of
| that for you.
| azakai wrote:
| That is not true for compiling to wasm.
|
| You can use upstream LLVM (and Emscripten, which uses it)
| with -flto normally on all platforms. It is basically cross-
| compiling, so it does not matter at all on what platform you
| are building, and Windows/Mac/Linux all work the same.
|
| Just to confirm that, here is an Emscripten CI run on MacOS,
| where you can see among other tests ones that build with lto
| (search for "lto" in the "run tests" tab):
|
| https://app.circleci.com/pipelines/github/emscripten-
| core/em...
| goodpoint wrote:
| > Since its release in 2014 Cheerp has been licensed under a dual
| licensing scheme: GPLv2 for non-commercial users, and a
| proprietary license for anybody not willing to comply with GPLv2
| terms.
|
| Using exclusively GPLv3 would have been better.
| [deleted]
| dgfitz wrote:
| How is this much different than wt [1] or compiling qt to
| emscripten? Sincere question.
|
| [1] https://www.webtoolkit.eu/wt
| jawadch93 wrote:
| [dead]
| pull_my_finger wrote:
| Does Cheerp expose a C API or is it cpp only?
| apignotti wrote:
| Cheerp works with C code, it's also possible to use
| __attribute__((cheerp_jsexport)) as an equivalent to
| [[cheerp::jsexporp]].
|
| Accessing DOM / external JavaScript can be done by using the
| __asm__ syntax while in C, use of the client namespace is only
| possible from C++ code
| Laaas wrote:
| I'm waiting for the same thing to happen to CheerpX [0].
|
| Would be great to be able to sandbox x86 code trivially.
|
| [0]: https://news.ycombinator.com/item?id=25646022 [0]:
| https://docs.leaningtech.com/cheerpx/
| nunobrito wrote:
| CheerpJ is the one I'm waiting for. That thing is wicked cool
| for Java.
| Laaas wrote:
| https://docs.leaningtech.com/cheerpj/
| KRAKRISMOTT wrote:
| It's not open source
| Laaas wrote:
| Yes, unfortunately, the more advanced products are much
| more restricted.
| TeaVMFan wrote:
| While you wait for CheerpJ, please check out TeaVM:
|
| https://teavm.org/
|
| It has a permissive Apache license and numerous success
| stories:
|
| https://frequal.com/TeaVM/TeaVmBasedSites.html
|
| There is also a full SPA toolkit called Flavour Plus for
| making pure Java, web-native, full-stack web apps:
|
| https://frequal.com/FlavourPlus/
| nunobrito wrote:
| Thanks, I've checked it in the past and recognize all the
| effort you've placed into the platform. There are reasons
| why it is mostly ignored:
|
| + website itself is difficult to find the hello world
| example
|
| + after a long time digging one finds the hello world, but
| is hosted somewhere else with (again) very scarce
| documentation on how to get it started.
|
| + the number of examples on the site is 2, and only one for
| Java language.
|
| Please invest more on newbie first steps. It isn't that we
| (end-users) are lazy, it is just that our time is precious
| too and this kind of information being available makes a
| huge difference to gain confidence into quickly grasping
| the basics and grow into more complex cases. This isn't
| possible when losing so much time around the site for info
| and just 1 example as showcase. (I know more examples are
| on github, but again had to dig to find them). Even that
| second link you mention has interesting examples but again,
| not even listed on the main page.
|
| If you compare to similar projects like GraalVM, you can
| notice they include snippet examples after snippet examples
| for end-users to dive quick and deep on what can be done:
| https://www.graalvm.org/latest/reference-manual/wasm/
|
| My apologies for the long answer. It just pains me to see a
| good project and a motivated person like you answering here
| but still with the handicap of a site that pushes end-users
| away.
| merb wrote:
| Cheerpj or Teavm would be amazing if they would be able to
| convert pdfbox to wasm as a library that runs on wasi and
| the web.
| Karellen wrote:
| > You can download Cheerp here. For Debian/Ubuntu, consider using
| our PPA
|
| > https://launchpad.net/~leaningtech-dev/+archive/ubuntu/cheer...
|
| They recommend using an Ubuntu PPA with Debian? That's...
| definitely a bold strategy. Let's hope it works out for them.
|
| I mean, given that they themselves suggest doing so, I take it
| that's the PPA has been properly tested on Debian, and that
| they'll answer support requests and help resolving any issues if
| they crop up? There aren't any Debian releases listed in the
| "Display sources.list entries for:" dropdown.
|
| Hmmm....following a couple of documentation links, I get to:
|
| https://docs.leaningtech.com/cheerp/Ubuntu-Debian-installati...
|
| Which states "Manually edit sources.list (works on Debian testing
| / stretch)". Huh. testing / stretch.
|
| Yup, I'm sure it's fiiiiine.
| ihnorton wrote:
| Does the library side of this provide an emulated socket API? The
| CheerJ docs [1] say:
|
| > Not yet. The main problem is that RuneScape requires low level
| network connections primitives (sockets)
|
| So, I'm guessing the same applies to the C++ version?
|
| [1] https://docs.leaningtech.com/cheerpj/Frequently-Asked-
| Questi...
| apignotti wrote:
| We don't support sockets out-of-the-box yet, but we have built
| a solution for the "networking-from-the-browser" problem a few
| months ago and we may backport that to Cheerp eventually.
|
| https://leaningtech.com/webvm-virtual-machine-with-networkin...
| ognarb wrote:
| This looks interesting, does anyone tried it before and can
| comment on how good this work on a real world project?
| wyldfire wrote:
| I'm particularly curious on what parts cheerp adds to their
| clang+llvm base. Presumably it's something like the C standard
| target library for WASM/JS?
|
| For reference, here's examples of what you could do with the
| baseline clang with wasm (but not JS?) [1] [2] [3], referenced
| from a similar thread on HN.
|
| [1] https://github.com/ern0/howto-wasm-minimal
|
| [2] https://github.com/robrohan/wefx
|
| [3] https://github.com/PetterS/clang-wasm
| yuri91 wrote:
| Disclaimer: I work on Cheerp.
|
| We do include the C (Musl) and C++ (Clang's libcxx) standard
| libraries.
|
| And we do have some custom LLVM passes to improve code size
| and performance (See for example [1] and [2]).
|
| But the main selling point in my opinion is the ability to
| target JavaScript, and (almost) freely mix data and code
| compiled to either JS or Wasm.
|
| Emscripten can also target JS, but it still retains the
| linear memory model of Wasm (or X86, Arm, ...), which means
| that what you get in the end is a big TypedArray and
| operations on it using basic types.
|
| With Cheerp, code compiled to JS uses an object memory model:
| a C++ object will become a garbage-collected JS object. While
| this has some limitations (you can't do unsafe casts and
| treat your memory like it's a big array, because it isn't),
| it allows seamless integration with the Browser (or any
| third-party) APIs:
|
| - You can store a DOM element directly in your C++ objects
| (instead of doing everything through tables)
|
| - You can directly manipulate JS Strings instead of
| constantly converting back and forth to C strings
|
| - You can create nice zero-overhead interfaces to use your
| C++ classes from manually written JS
|
| - Or, you can just write your whole program in C++, including
| callbacks for DOM events and whatnot
|
| And you can still compile the peformance-sensitive or type-
| unsafe parts of your code to Wasm (losing access to some
| convenience in exchange for speed).
|
| You can get an idea from the Pong tutorial [3], although it's
| a bit of a contrived example to showcase what can be done.
|
| [1] https://medium.com/leaningtech/partialexecuter-reducing-
| weba...
|
| [2] https://docs.leaningtech.com/cheerp/Cheerp-
| PreExecuter.html
|
| [3] https://docs.leaningtech.com/cheerp/Cheerp-Tutorial-
| Mixed-mo...
| prideout wrote:
| > a C++ object will become a garbage-collected JS object.
|
| This sounds great for ease-of-use and cross-language
| binding. But, there's a downside with respect to
| performance. With Emscripten, you never see any GC events
| show up in the profiler.
| yuri91 wrote:
| Indeed, as I said it can be a downside.
|
| What we usually suggest is to compile most of the
| application to Wasm (which is also the default), and move
| the parts that most interact with the outside world to
| JS.
|
| This can actually result in a speedup if it avoids
| multiple back-and-forths between JS and Wasm, which is
| common if you use a Browser/JS api from Wasm.
| jeffreportmill1 wrote:
| Congratulations, looks like a great release! I'm a big fan of
| CheerpJ - these tools are making web development from other
| languages a reality.
| jokoon wrote:
| It can actually manipulate the DOM by writing JS code.
|
| This is really amazing.
|
| > The question is, what will you build with Cheerp?
|
| I don't really know, for now all I want is executing python in
| the browser like brython, and see if WASM can make things better,
| at least give more elegant errors.
|
| But other than that, I'd rather dump HTML as a format and have
| something better suited for it. I already thought about a
| replacement for HTML, because there are so many things to remove
| in HTML.
| CyberDildonics wrote:
| _It can actually manipulate the DOM by writing JS code. This is
| really amazing._
|
| Why is that amazing? Anyone can manipulate the DOM by writing
| javascript.
|
| _I don 't really know, for now all I want is executing python
| in the browser_
|
| You might want that, but do people using what you make want
| that? Python is already orders of magnitude slower than a
| native program, it's going to be even slower running in a
| browser.
| jokoon wrote:
| Manipulating the DOM with C++ means one doesn't have to write
| JS at all, and can use C++.
|
| Even things like TS still rely heavy machinery to translate
| ts to js.
|
| I don't really know how TS works and if it puts the generated
| JS in cache.
|
| Well brython is already quite fast already, so I don't think
| a WASM version would be worse.
|
| And python performance is not such a big problem, it's up to
| developers to write faster programs instead by picking
| relevant modules and not writing low-level code. Python
| performance has already improved a bit, and performance is
| rarely a real problem in software anyway.
| josephg wrote:
| > I don't really know how TS works and if it puts the
| generated JS in cache.
|
| Usually, typescript is compiled to javascript in a build
| step (eg on the developer's computer) using the typescript
| compiler. The output is javascript which can be run in the
| web browser directly, or bundled with webpack & friends,
| then loaded into the browser.
___________________________________________________________________
(page generated 2023-03-14 23:02 UTC)