 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> An entire OS is larger than a compiler? SAY IT ISN'T SO! :-P
"Image" means "jpeg".
> zlib.h - OK, I have no explanation for why this would be more than 1,000
> bytes long. It's only a header file, after all. (IOW, it tells you the
> name of the compress and decompress functions. Unless those names are
> *really* long, I can't see how two function names can be 80KB in size.)
zlib consists of a lot more than just two functions. There are probably
at least a hundred functions and a couple of dozens of types. (For example,
zlib contains wrapper functions that simulate the usage of the standard I/O
functions.)
> The touch command - no explanation.
It has multiple command-line parameters (which have to be parsed and
interpreted), a help text for all those parameters, probably tons of
different error messages and probably tons of code dealing with the unix
file system (as it might not be the same thing to 'touch' a file, a directory,
a soft link, a pipe, a device, etc). Some statically linked libraries might
add unused code to the executable as well.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> An entire OS is larger than a compiler? SAY IT ISN'T SO! :-P
>
> "Image" means "jpeg".
How do you take a picture of an OS?
Regardless, it's no secret that image data takes up far more space than
code does. I gather there was a time when people predicted that Moore's
Law would mean that you would be able to store your entire life on a
computer soon - after all, 10MB is enough space to store the contents of
an entire *library*, right?
>> zlib.h - OK, I have no explanation for why this would be more than 1,000
>> bytes long. It's only a header file, after all. (IOW, it tells you the
>> name of the compress and decompress functions. Unless those names are
>> *really* long, I can't see how two function names can be 80KB in size.)
>
> zlib consists of a lot more than just two functions. There are probably
> at least a hundred functions and a couple of dozens of types. (For example,
> zlib contains wrapper functions that simulate the usage of the standard I/O
> functions.)
And here I was thinking it just takes data and returns compressed data...
>> The touch command - no explanation.
>
> It has multiple command-line parameters (which have to be parsed and
> interpreted), a help text for all those parameters, probably tons of
> different error messages and probably tons of code dealing with the unix
> file system (as it might not be the same thing to 'touch' a file, a directory,
> a soft link, a pipe, a device, etc). Some statically linked libraries might
> add unused code to the executable as well.
The Turbo Pascal compiler also has many command-line options, and - I
would suggest - *far* more error messages than the touch command. Not to
mention a complete Pascal parser, AST manipulations, code generator,
etc. Clearly it "should" be way, way bigger.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> >> An entire OS is larger than a compiler? SAY IT ISN'T SO! :-P
> >
> > "Image" means "jpeg".
> How do you take a picture of an OS?
"iPhone 4S" is not an OS. It's a cellphone.
> after all, 10MB is enough space to store the contents of
> an entire *library*, right?
Not really. A medium-length book may well take 1 MB to store, especially
if you store layout and style as well.
> > zlib consists of a lot more than just two functions. There are probably
> > at least a hundred functions and a couple of dozens of types. (For example,
> > zlib contains wrapper functions that simulate the usage of the standard I/O
> > functions.)
> And here I was thinking it just takes data and returns compressed data...
It's not that simple. There are many places where you could be reading
from or writing to. For example if you want to decompress from RAM to RAM,
that's a completely different process than if you want to decompress from
a file to RAM streamed (iow. you don't want to load the entire compressed
file to RAM at once). Compressing is even more complicated because you have
all kinds of options. Then there are utility functions to make this process
easier so that you can skip the nitty-gritty details if you don't care about
them.
(Remember that zlib is in C, and hence there's not much abstraction.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> How do you take a picture of an OS?
>
> "iPhone 4S" is not an OS. It's a cellphone.
Hmm, interesting...
>> after all, 10MB is enough space to store the contents of
>> an entire *library*, right?
>
> Not really. A medium-length book may well take 1 MB to store, especially
> if you store layout and style as well.
I think my numbers are off slightly. Regardless, the original quote
[which I can't seem to find now] was that "in 10 years' time" computers
will have so much storage that you can easily store a textual
representation of everything that ever happens in your life.
Think about it. I've got a file somewhere which contains a complete copy
of The Holy Bible. It's 0.5MB. And that's quite big, as books go. So
with a 3TB HD, I ought to be able to store quite a few books. If we
assume 1MB per book, that's... over one million books. More material
that you can read in a single human lifetime.
The point being, when they wrote that, they were assuming that text is
all you would ever use computers to store. Consider the possibility of
storing graphics, sound and even video, and suddenly 3TB doesn't seem
very big at all. Suddenly it starts to actually look kinda small... and
that's something that writers decades ago wouldn't have foreseen.
>>> zlib consists of a lot more than just two functions.
>
>> And here I was thinking it just takes data and returns compressed data...
>
> It's not that simple. There are many places where you could be reading
> from or writing to. For example if you want to decompress from RAM to RAM,
> that's a completely different process than if you want to decompress from
> a file to RAM streamed (iow. you don't want to load the entire compressed
> file to RAM at once). Compressing is even more complicated because you have
> all kinds of options. Then there are utility functions to make this process
> easier so that you can skip the nitty-gritty details if you don't care about
> them.
>
> (Remember that zlib is in C, and hence there's not much abstraction.)
I had expected the zlib itself merely takes a pointer to a buffer full
of data, and a pointer to an empty buffer, and moves data from one to
the other, compressing or decompressing as requested. I'm surprised it
actually implements anything as high-level as file access.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> I had expected the zlib itself merely takes a pointer to a buffer full
> of data, and a pointer to an empty buffer, and moves data from one to
> the other, compressing or decompressing as requested. I'm surprised it
> actually implements anything as high-level as file access.
If the data you are decompressing doesn't fit into RAM, how are you
supposed to decompress it? (Answer: By streaming. In other words,
decompress small parts at a time. This requires more than one simple
"decompress this" function.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/31/2011 3:24, Invisible wrote:
> The Wikipedia page for C++. [...] But sure, 18 pages of rich formatted text plus
accompanying
> diagrams... I guess that's going to be fairly large.
I think his point is that the encyclopedia page for describing C++ is bigger
than the entire development environment for implementing TP.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/31/2011 9:35, Invisible wrote:
>>> How do you take a picture of an OS?
>>
>> "iPhone 4S" is not an OS. It's a cellphone.
>
> Hmm, interesting...
Again, he's pointing out that a *picture* of a computer is bigger than the
entire compiler that runs on that computer. He's making amusing
comparisons, not something you should really be deeply concerned about.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 31/10/2011 05:36 PM, Warp wrote:
> Invisible<voi### [at] devnull> wrote:
>> I had expected the zlib itself merely takes a pointer to a buffer full
>> of data, and a pointer to an empty buffer, and moves data from one to
>> the other, compressing or decompressing as requested. I'm surprised it
>> actually implements anything as high-level as file access.
>
> If the data you are decompressing doesn't fit into RAM, how are you
> supposed to decompress it? (Answer: By streaming. In other words,
> decompress small parts at a time. This requires more than one simple
> "decompress this" function.)
As I say, I would have expected a function that takes two buffers, and
then returns some sort of indication of how much data it processed. You
can then call it again to process the next chunk. The only really tricky
bit is flushing the end of the stream.
But yeah, I guess that might be complicated enough to merit having
functions especially for the common case of wanting to compress a file
on disk...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The Turbo Pascal compiler also has many command-line options, and - I
> would suggest - *far* more error messages than the touch command. Not to
> mention a complete Pascal parser, AST manipulations, code generator,
> etc. Clearly it "should" be way, way bigger.
The article mentions the size of the main executable only (the editor).
It doesn't list all the associated .OVL (ancestors to .DLLs) and text
files it required, and the fact that the actual compiler was a separate
executable called by the IDE.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/11/2011 12:27 PM, Francois Labreque wrote:
>> The Turbo Pascal compiler also has many command-line options, and - I
>> would suggest - *far* more error messages than the touch command. Not to
>> mention a complete Pascal parser, AST manipulations, code generator,
>> etc. Clearly it "should" be way, way bigger.
>
> The article mentions the size of the main executable only (the editor).
> It doesn't list all the associated .OVL (ancestors to .DLLs) and text
> files it required, and the fact that the actual compiler was a separate
> executable called by the IDE.
The article doesn't seem to even *specify* exactly what it measured the
size of. Because, as you say, the Turbo Pascal environment definitely
consists of more than just one file...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
