6:02 a.m.
had forgotten to reply also to the list... doing it now:
[cut the part where it was suggested to make package that contains LLVM
Intermediate Representation bitcode rather than CPU specific assembler]
On 2020-05-29 1:01 a.m., John M. Harris Jr wrote:
Paul,
What benefit do you see in the overhead of LLVM IR, compared to standard
packages?
John,
Where do you see overhead in the distribution of LLVM IR?
Advantages:
* more space on the hard disks of the servers, because they contains
repositories only for LLVM IR packages rather than one by supported
architectures
* less use of the CPU time of the servers because they don't optimize
code for specific CPUs
* very reduced cost for supporting more architectures, as code is
client-side generated
* faster code on clients with recent CPUs, because code is optimized for
them, and was not in the old way of doing because you had to distribute
for a common base CPU
* CPU specific code generation and optimizations can be done on idle
time of the clients... there is not much idle time of the servers
3:11 p.m.
On Friday, May 29, 2020 4:02:40 AM MST Paul Dufresne via devel wrote:
had forgotten to reply also to the list... doing it now:
[cut the part where it was suggested to make package that contains LLVM
Intermediate Representation bitcode rather than CPU specific assembler]
On 2020-05-29 1:01 a.m., John M. Harris Jr wrote:
> Paul,
> What benefit do you see in the overhead of LLVM IR, compared to standard
> packages?
John,
Where do you see overhead in the distribution of LLVM IR?
See below responses.
Advantages:
* more space on the hard disks of the servers, because they contains
repositories only for LLVM IR packages rather than one by supported
architectures
This may be a valid point, but I'm not sure it's really all that important.
I'm currently mirroring 3 different arches of the Fedora repos, and the total
disk space is 495G. That's not a lot of storage space these days, at least not
for servers. Additionally, there are a number of packages that cannot be LLVM
IR, which are needed to support running LLVM IR. Please also consider how
initramfs would be handled. Statically compiled software or LLVM IR and the
supporting software?
* less use of the CPU time of the servers because they don't
optimize
code for specific CPUs
Not handling this on the build servers means doing it on the end system, every
time the program is run.
* very reduced cost for supporting more architectures, as code is
client-side generated
Does LLVM IR have a way of handling arch-specific code?
* faster code on clients with recent CPUs, because code is optimized
for
them, and was not in the old way of doing because you had to distribute
for a common base CPU
How does LLVM IR accomplish this? Would it be slower on older CPUs, or does it
specifically compile for the host CPU's micro-arch?
* CPU specific code generation and optimizations can be done on idle
time of the clients... there is not much idle time of the servers
If it's going to be done on idle time of client systems, this is definitely
not going to work in Fedora in general. Perhaps in Silverblue or other systems
not designed to be a general purpose operating system? It actually might even
work in Fedora Workstation, but then you'd have to separate Workstation from
the base distro, assuming GNOME doesn't eat CPU idle time.
--
John M. Harris, Jr.
Splentity
3:56 p.m.
Perhaps in Silverblue or other systems not designed to be a general
purpose operating system?
What, where did you get that? Silverblue is general purpose.
Anyways, my 2c on this topic: Once WebAssembly supports threads (it's coming)
there's going to be a lot of interesting discussion about potentially using it in
places where we compile native code in the operating system and applications today.
IOW, it doesn't make sense to invest much in LLVM IR versus WebAssembly.
7:01 p.m.
On Friday, May 29, 2020 1:56:16 PM MST Colin Walters wrote:
> Perhaps in Silverblue or other systems not designed to be a
general
> purpose operating system?
What, where did you get that? Silverblue is general purpose.
Well, Silverblue is mostly GNOME. It's not meant for servers, etc.
Anyways, my 2c on this topic: Once WebAssembly supports threads
(it's
coming) there's going to be a lot of interesting discussion about
potentially using it in places where we compile native code in the
operating system and applications today.
Err, what does WebAssembly have to do with real programs?
IOW, it doesn't make sense to invest much in LLVM IR versus
WebAssembly.
WebAssembly is just in web browsers. It's not for normal software you'd
install with your package manager. Unless I'm missing something?
--
John M. Harris, Jr.
Splentity
7:15 p.m.
On Fri, May 29, 2020, at 8:01 PM, John M. Harris Jr wrote:
WebAssembly is just in web browsers. It's not for normal software
you'd
install with your package manager. Unless I'm missing something?
You are indeed missing
https://webassembly.org/docs/non-web/
https://wasi.dev/
More random links, and I'm sure others have better ones:
https://github.com/enarx/enarx/wiki/WebAssembly-(Wasm)
https://deislabs.io/posts/introducing-krustlet/
https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/
https://rustwasm.github.io/2018/10/24/multithreading-rust-and-wasm.html
https://hacks.mozilla.org/2019/08/webassembly-interface-types/
10:22 p.m.
On Friday, May 29, 2020 5:15:45 PM MST Colin Walters wrote:
On Fri, May 29, 2020, at 8:01 PM, John M. Harris Jr wrote:
> WebAssembly is just in web browsers. It's not for normal software you'd
> install with your package manager. Unless I'm missing something?
You are indeed missing
https://webassembly.org/docs/non-web/
https://wasi.dev/
More random links, and I'm sure others have better ones:
https://github.com/enarx/enarx/wiki/WebAssembly-(Wasm)
https://deislabs.io/posts/introducing-krustlet/
https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/
https://rustwasm.github.io/2018/10/24/multithreading-rust-and-wasm.html
https://hacks.mozilla.org/2019/08/webassembly-interface-types/
How does this compare to LLVM IR in terms of performance? What software do you
believe it would make sense to ship as WebAssembly? Would it actually be
beneficial compared to shipping software normally?
<rant>
With WebAssembly, it's getting to the point where I really just have to ask
"Why?" when this sort of thing comes up. It seems that we're just looking
for
ways to overcomplicate things at this point, pulling in "Web" technologies for
things that are surprisingly simple. Web browser vendors continue to surprise
me with how overcomplicated these things are getting. I remember when web
browsers didn't need gigabytes of RAM to function properly, when they didn't
need to run in multiple processes.
</rant>
--
John M. Harris, Jr.
Splentity
12:27 p.m.
On 5/29/20 4:02 AM, Paul Dufresne via devel wrote:
* more space on the hard disks of the servers, because they contains
repositories only for LLVM IR packages rather than one by supported
architectures
LLVM IR is not really arch-independent -- by the time you get to this
level, all of the arch-specific assumptions of the source language are
baked in. For a simple example, a C "long" will be just "i32" or
"i64"
in LLVM IR, depending on the target.
So you would still need separate LLVM IR packages for each target.
1429
days inactive
1432
days old
6 comments
4 participants
participants (4)
-
Colin Walters -
John M. Harris Jr -
Josh Stone -
Paul Dufresne