Log in

No account? Create an account
Havoc rules - brad's life — LiveJournal [entries|archive|friends|userinfo]
Brad Fitzpatrick

[ website | bradfitz.com ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Havoc rules [Mar. 16th, 2004|10:04 pm]
Brad Fitzpatrick
Good read:
Java, Mono, or C++?
Thoughts on the future of open source desktop development

[User Picture]From: jes5199
2004-03-16 10:14 pm (UTC)
"Coding efficiency. High-level languages are simply technically superior to C/C++ for most uses, desktop applications in particular."

is that really true?
(Reply) (Thread)
[User Picture]From: brad
2004-03-16 10:50 pm (UTC)
You have to ask?
(Reply) (Parent) (Thread)
[User Picture]From: jes5199
2004-03-17 10:38 am (UTC)
ok, so i don't know java or C#
but my experience with Pascal, C, C++, Delphi, bash, sed, javascript, and S2
taught me that all languages is equal
(Reply) (Parent) (Thread)
[User Picture]From: brad
2004-03-17 10:41 am (UTC)
They're all best at a specific problem domain.

Would you write an operating system in Perl? No.

Would you write a web app in C? Only if you were on crack.

The article was saying C/C++ (which are just glorified assembler) aren't good for writing desktop apps. High-level language features like garbage collection are many times over worth their minimal performance cost. Writing desktop apps in C is slow-going and asking for trouble.

Java/C# are good because they're garbage collected, sandboxable, and can be compiled/JITed, with a lot of errors caught at compile time due to their static typing. Not so with Perl/Python/Ruby/etc.
(Reply) (Parent) (Thread)
[User Picture]From: scosol
2004-03-16 11:08 pm (UTC)
Hmmmm generally I've used "external" (not libs, but interfaces to code written for a different compiler) code in get-it-done-now situations.
Where a bit o perl , some code shanks, and some syscalls to nc, ls, and a bucnh of pipes got shit done.
But now that I've been doing more in the AI field, I'm seeing the benefits of knowing exactly what is going on where-
And in keeping it all in a cohesive space.

With that, I see that for fundamental things- if you're making lots of calls to external code, it means you're using the wrong language.
So enough- my practice of late has been O'CaML- and with it I'm able to keep everything in spot.

With a desktop environment?
I see no reason why a robust garbage collector can't be built in to the Linux/BSD/whatever kernel itself, and all userland stuff executes within it.

Mono is built to be language-agnostic- right now it knows c#, but it's built with the ability to understand whatever it's told to understand- leaving the door wide open for what Havoc sees- I don't agree with a lot of his desktop philosphy, but right here he's on.
(Reply) (Thread)
From: evan
2004-03-17 09:22 am (UTC)

brad was probably already expecting this comment

yeah ocaml!
(Reply) (Parent) (Thread)
[User Picture]From: brad
2004-03-17 10:44 am (UTC)
I see no reason why a robust garbage collector can't be built in to the Linux/BSD/whatever kernel itself, and all userland stuff executes within it.

Ignoring the technical reasons why that wouldn't work and why userland is better for it, ....

A project like GNOME can't rely on kernel features that are in one OS's kernel. GNOME has to run on dozens of kernels from many years back.

(Reply) (Parent) (Thread)
[User Picture]From: scosol
2004-03-17 01:25 pm (UTC)
I just mean that functionally, these 2 are about the same:

1) having your apps depend on a VM that must be cross-platform and rock-stable and provide the same services to apps in the same way regardless of underlying Kernel/OS/Hardware

2) having your apps depend on a kernel-module that must be cross-platform and rock-stable and provide the same services to apps in the same way regardless of underlying OS/Hardware

In one situation you have to port a VM to different OSes, in the other, you have to port a kernel module's functionality to different kernels.

As for kernel VS userland- it's the same old argument right?
Stability VS speed- I personally find the idea of things like httpfs somewhat insane- but for a "proper" simple VM I think that kernel-space is appropriate.
(Reply) (Parent) (Thread)
[User Picture]From: tytso
2004-03-18 04:44 am (UTC)
First of all, the VM interfaces are well defined. You don't have to "port" the VM to different OS's, because no matter which VM you are using, there is a well defined POSIX interface to them. (i.e., mmap, msync, etc.)

Secondly, the VM interfaces are very simple, and do not require much low-level understanding of the application by the kernel. In contrast, in order to make GC work, the garbage collector needs to know which memory locations are valid pointers, and which are not. This means that the GC has to grok data structures, and how data structure elements are tagged. But this sort of data tagging (so that you know whether a memory location contains a pointer or something else) is not native to nearly all modern processors. As a result, programming run-times have to make them up, and there is no standard way of doing this. The simplest that would be required is a single bit to indicate "pointer-or-no-pointer", and some kind of length indication so that you know how big a data structure is when you decide to free it. (Assuming that you have data structures at all; if you only have integers, pointers, and cons cells ala primitive lisp systems, then that simplifies the problem.) Other run-times will want to use much more space when they tag their data structures, up to and including a full type-definition language. But there's no standardization here, and until there is, it's insane to think that the kernel should just dictate what that run-time standard should be.

Finally, it's not at all clear what the justification would be for putting a garbage collector in the kernel. What performance advantage would it have? The fact that the kernel would have to do a lot of access to user-mode memory (with special provisions of the memory has been paged out, and potential security holes if the kernel makes any mistakes in validating pointers before using them in the GC code) means that there are plenty of arguments why putting the GC in the kernel is a bad, bad, bad idea. What are the advantages?

A much better suggestion to have a standard run-time library that includes a GC, and use that instead. Say, like the Parrot project. That's actually a really sane idea, because the one thing that I worry about is that everybody decides they want to use their own interpreter, and we end up wasting a lot of space. So we have window managers that want to use Scheme, editors that want to use Lisp, etc., etc., etc., and that ends up wasting a huge amount of memory. What *would* be cool is a single run-time environment that can support multiple applications, and can share text pages for core libraries.
(Reply) (Parent) (Thread)
[User Picture]From: scosol
2004-03-18 03:30 pm (UTC)
Hmmmm maybe you got something out of that article that I didn't-
My takeaway from it was essentially that perhaps the time of using C/++ for app code was done.
That perhaps user programs should execute in a common VM, that provides common and standard facilities regardless of underlying OS- and that provides more "modern" coding conveniences like GC.

My comment was simply that if you're going to all that trouble to port a VM to a dozen different underlying OSes, performance would be better if you instead ran the VM in-kernel (when said kernel supports modules).

I didn't mean a simple garbage collector running in-kernel, wanking around with existing userland programs.
(Is that what you thought I meant?)

Anyway- I suspect that this is exactly what Sun wants to do with their Java Desktop-
(Reply) (Parent) (Thread)
[User Picture]From: tytso
2004-03-18 03:54 pm (UTC)
Ah, when you said VM, I thought you meant "Virtual Memory", not "Virtual Machine". And yes, I thought you were talking about putting the garbage collector in-kernel.

As far as moving the VM into the kernel, that would mean moving not just the garbage collector, but also the byte code interpreter into the kernel. It is not at all clear that the VM would be more performant if it is in the kernel. In fact, because you can no longer depend on the hardware to do access checks, but you now have to do it explicitly in the kernel code, it might actually be less performant to do it in the kernel.

A common VM is a great thing, and it can same space. But it's probably best done in a user-space library. How would you justify your claim that it would be more performant to put the VM in the kernel?
(Reply) (Parent) (Thread)
[User Picture]From: scosol
2004-03-18 04:17 pm (UTC)
Alright hahah- too many acronyms :P

Right- so I'm not "claiming" that a kernel-space VM would be faster- I of course have done no testing-
But I strongly suspect that it would.
My reasoning is just based around the layers that have to be penetrated in a situation like that.
You're talking about app->VM->OS->kernel->hardware

Hmmm thinking about it more, I think that to maintain any tight latencies in a VM environment, it would *have* to run in-kernel (except of course if the kernel already provides special interfaces for hard interrupts and such)

You can look at it 2 ways- running a VM in the kernel, or extending the kernel to provide some VM-like functionality.
(Reply) (Parent) (Thread)
[User Picture]From: tytso
2004-03-19 10:52 am (UTC)
Not all layers are created equal. Procedure activations (one layer calling another layer) are cheap, Secondly, the VM interpreting the byte-code layer is not really "one layer penetrating another". The one thing that you have to watch is userspace->kernel transitions, and kernel space needing to access userspace memory (which gets complicated because the kernel has to do manual security checks instead of being able to depend on the hardware MMU).

Anyway, I suspect that since you're not a kernel progammer, nothing I say is going to pursuade you. So I'll just invite you to try....
(Reply) (Parent) (Thread)
[User Picture]From: scosol
2004-03-19 11:07 am (UTC)
I'm not a kernel programmer- but I'm not beyond persuasion through intelligient discussion-

I don't understand why you say that the kernel would need to "access userspace memory".
Imagining a VM running in the kernel, and user apps running within the VM-managed memory space provided by the VM, the kernel just provides the VM "module" with access to memory just like anything else- and that would still make use of the HW MMU wouldnt it?
(Reply) (Parent) (Thread)
[User Picture]From: tytso
2004-03-19 11:23 am (UTC)
The kernel is running in privileged mode, which means it has unquestioned access to all parts of the memory --- including the kernel memory. So if the VM is running in the kernel, it follows that it is also running in privileged mode. So any time it references any memory on behalf of the application, the kernel must manually validate memory access to make sure it's legal. Also, any security bugs (or any kind of bugs that might result in a core dump if the VM was in userspace) become catastrophic when the VM is moved into the kernel.
(Reply) (Parent) (Thread)
[User Picture]From: scosol
2004-03-19 11:49 am (UTC)
> So any time it references any memory on behalf of the application, the kernel must manually validate memory access to make sure it's legal.

Right- I understand the issues with having to manually check the page maps when priviledged- but in this case (talking about *all* user programs running in the VM), this is a one-time cost.
Almost all the memory in the box (or a static amount etc) would be allocated to the VM upon startup.
From there, the VM handles "userspace" (VM space) memory management and GC the kernel is done with it.

And yes, having a secure, robust, stable VM is of paramount importance (in-kernel or not) :)
(Reply) (Parent) (Thread)
From: sheehan
2004-03-16 11:44 pm (UTC)


i don't get xaml... and i'm highly suspicious of anything that involves humans writing sgml...

(Reply) (Thread)
[User Picture]From: brad
2004-03-16 11:50 pm (UTC)

Re: xaml

XAML's just like XUL, and that's kicking some ass in the Mozilla world. Firefox and Thunderbird, and their extensions, really show some cool shit is possible.

Most people won't write the XML by hand. Visual Studio will do it for them, like how it already does template sections in C++/C#. The point is the text format will make it easy for people to modify/auto-generate.

The appeal of ubiquitous XUL/XAML is that you could finally get away with the brain-dead static-ness of HTML. Even with a standardized DOM and JavaScript (hah), the basic widgets are shit... no drop-down combo, no sliders, no tab panes, no stretchy box model for resizing flow, connecting events together is painful, etc.

I think the XUL concept (which XAML looks to be largely a copy of) totally kicks ass, and I'm sure MS will make it popular, just by virtue of making it installed everywhere.
(Reply) (Parent) (Thread)
[User Picture]From: haran
2004-03-17 08:20 am (UTC)

my USD.02

C#'s a really good language for desktop program development, provided that either it has a native-code compiler (unlikely) or the IL-based VM is efficient enough (where efficient enough means "a lot better than JVM"). Python would be really good for smaller utilities (such as system configuration tools). I think, as a language, it scales well, but its just too slow for larger apps. Maybe parrot will solve that. C++ isn't good for anything. C's good when the performance of the other languages just won't cut it.
(Reply) (Thread)
From: evan
2004-03-17 09:23 am (UTC)
here's what i wrote him

I'm sure you're inundated with emails, so I'll try to keep this short.

1) In my experience, "letting the community decide" is asking for a
quagmire; it's far better to have some strong voices (you, Owen, Miguel,
etc.) advocate their positions and then let the community follow.
I know that sounds dictatorial, but
a) a good enough argument would convince everyone;
b) I'd much rather have an intelligent/benevolent dictator.

2) I'd love it if you could comment on the non-Freeness of Java. I
don't really understand the issues except that it's a total hassle to
install in Debian. Didn't Sun pull some annoying[1] trick about making
the documentation non-free to those trying to reimplement it?
(Perhaps your essay will help convince them otherwise?)

3) It seems like a shame there can't be some way to agree on a lower
level. GTK, etc., have done such great work at making language bindings
work. Your shared runtime (haven't read the whole doc yet, sorry) seems
to be in this spirit, but in practice I don't know if it's possible;
have you ever used .NET from a non-C# language? It feels like you're
writing... well, C#, but with a different syntax.

Very Hard Problems abound. I'm eager to see where you go with it.

[1] To prevent Microsoft, yeah yeah, but it still sucks for us, too.
(Reply) (Thread)