On 2/28/2012 3:21 AM, Loup Vaillant wrote:
Originally, the VPRI claims to be able to do a system that's 10,000
smaller than our current bloatware. That's going from roughly 200
million lines to 20,000. (Or, as Alan Kay puts it, from a whole library
to a single book.) That's 4 orders of magnitude.
From the report, I made a rough break down of the causes for code
reduction. It seems that
- 1 order of magnitude is gained by removing feature creep. I agree
feature creep can be important. But I also believe most feature
belong to a long tail, where each is needed by a minority of users.
It does matter, but if the rest of the system is small enough,
adding the few features you need isn't so difficult any more.
this could help some, but isn't likely to result in an order of magnitude.
it is much the same as thinking:
"this OS running on a single HW configuration will eliminate nearly all
of the code related to drivers";
very likely, it would eliminate a lot of the HW-specific parts, but much
the "common" functionality may still need to be there.
- 1 order of magnitude is gained by mere good engineering principles.
In Frank for instance, there is _one_ drawing system, that is used
for everywhere. Systematic code reuse can go a long way.
Another example is the code I work with. I routinely find
portions whose volume I can divide by 2 merely by rewriting a couple
of functions. I fully expect to be able to do much better if I
could refactor the whole program. Not because I'm a rock star (I'm
definitely not). Very far from that. Just because the code I
maintain is sufficiently abysmal.
this is elimination of redundancy, which is where I figured one would
have the most results.
I suspect that, at least on the small scale, programmers tend to reduce
redundancy where possible.
on the macro-scale, it is still a bit of an issue, as apps will tend to
implement their own versions of things.
consider, for example, said OS has a 3D FPS style game in it:
maybe, the VFS code can be shared with the kernel, and with other apps;
likewise for memory management, and things like reflection and types
management;
...
one may still have a big chunk of code for the 3D renderer.
ok, this is factored out, maybe a lot is shared with the GUI subsystem
(which now deals with things light texture management, lighting,
materials and shaders, ...);
...
but, one has a problem: what functionality is moved out of the 3D engine
into other components in turn makes the parts the functionality into
more complex, and leaving the functionality in the 3D engine means it
has to deal with it.
someone could be like "well, this engine doesn't really need shadows and
normal mapping", but people will notice.
if people are instead like, "this OS will not have or allow any sort of
3D games", people will likely not go for it.
I suspect, at best, all this is likely to result in around a 25-50%
reduction.
- 2 orders of magnitude are gained through the use of Problem Oriented
Languages (instead of C or C++). As examples, I can readily recall:
+ Gezira vs Cairo (÷95)
+ Ometa vs Lex+Yacc (÷75)
+ TCP-IP (÷93)
So I think this is not exaggerated.
I suspect this may be over-estimating it a bit.
say, eliminating C and C++ "may" eliminate some amount of bulk, say,
people endlessly re-rolling their own linked lists, or typing verbose
syntax.
but, a 100x average-case seems a bit of a stretch, even for this.
likewise: one still needs the logic to run said POLs.
a bigger problem though could be that it could become
counter-productive, if the overuse of POLs renders the code unworkable
due either to very few people being able to understand the POLs, or
change the code in them without catastrophic results, like "don't touch
this or your whole system will blow up in your face".
Looked at it this way, it doesn't seems so impossible any more. I
don't expect you to suddenly agree the "4 orders of magnitude" claim
(It still defies my intuition), but you probably disagree specifically
with one of my three points above. Possible objections I can think of
are:
- Features matter more than I think they do.
- One may not expect the user to write his own features, even though
it would be relatively simple.
- Current systems may be not as badly written as I think they are.
- Code reuse could be harder than I think.
- The two orders of magnitude that seem to come from problem oriented
languages may not come from _only_ those. It could come from the
removal of features, as well as better engineering principles,
meaning I'm counting some causes twice.
possibly.
I think more likely that is that a few things will result:
each thing has an effect, but not nearly so much, say if each stage only
works out to maybe on average 25-50%;
one runs into a diminishing-returns curve (making one thing smaller
makes it harder to make something else smaller, ...).
much like with data compression: 50-75% is easy to get reduction. the
last 25% though, may border on impossible...
but, anyways, features are sort of a "holy grail" in common software
development:
one does not forsake features easily.
most users don't like losing features either, and will either complain,
or bring in their own stuff to compensate:
say, Windows 7 drops MS-DOS support;
many people are very much annoyed;
so, they go and download DosBox.
if less in one place means more somewhere else, is there a gain?
but, anyways, even 1 Mloc would put it within the abilities of a single
human to understand, provided it is still understandable...
Loup.
BGB wrote:
On 2/27/2012 10:08 PM, Julian Leviston wrote:
Structural optimisation is not compression. Lurk more.
probably will drop this, as arguing about all this is likely pointless
and counter-productive.
but, is there any particular reason for why similar rules and
restrictions wouldn't apply?
(I personally suspect that similar applies to nearly all forms of
communication, including written and spoken natural language, and a
claim that some X can be expressed in Y units does seem a fair amount
like a compression-style claim).
but, anyways, here is a link to another article:
http://en.wikipedia.org/wiki/Shannon%27s_source_coding_theorem
Julian
On 28/02/2012, at 3:38 PM, BGB wrote:
granted, I remain a little skeptical.
I think there is a bit of a difference though between, say, a log
table, and a typical piece of software.
a log table is, essentially, almost pure redundancy, hence why it can
be regenerated on demand.
a typical application is, instead, a big pile of logic code for a
wide range of behaviors and for dealing with a wide range of special
cases.
"executable math" could very well be functionally equivalent to a
"highly compressed" program, but note in this case that one needs to
count both the size of the "compressed" program, and also the size of
the program needed to "decompress" it (so, the size of the system
would also need to account for the compiler and runtime).
although there is a fair amount of redundancy in typical program code
(logic that is often repeated, duplicated effort between programs,
...), eliminating this redundancy would still have a bounded
reduction in total size.
increasing abstraction is likely to, again, be ultimately bounded
(and, often, abstraction differs primarily in form, rather than in
essence, from that of moving more of the system functionality into
library code).
much like with data compression, the concept commonly known as the
"Shannon limit" may well still apply (itself setting an upper limit
to how much is expressible within a given volume of code).
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
