[Pharo-project] [Vm-dev] Re: Can OSProcess functionality be implemented using FFI instead of plugin?

[Denis Kudriashov]

2016-01-22 22:35 GMT+01:00 Eliot Miranda <eliot.miranda at gmail.com>:

> Let's measure this.  Let's say we have 8 platforms (that's an
> underestimate, because different Linux distributions may have different
> values for certain constants), but 8, which is 4 basic platforms times 32-
> & 64-bits.  We have Mac x86 32-bit, Mac x64 64-bit, Windows x86
> 32-bit, Windows x64 64-bit, Linux x86 32-bit, Linux ARM 32-bit, Linux x64
> 64-bit, and soon enough there will be more.  Further, there may be
> different versions over time.
>
> So each of those initialization methods has
> - 1 slot for the global variable to be assigned
> - 1 slot for the literal value to assign to it
> - 3 bytes of bytecode per initialization for small methods, 4 for large
> methods.  Let's say 4.
>
> So the overhead in 32-bits is 12 bytes per constant, and in 64-bits is 20
> bytes.  So the overhead per constant for all platforms is 96 bytes per
> constant in 32-bits and 160 bytes per constant for 64-bits.  A full system
> with sockets, files, a database connexion etc could easily exceed 100
> constants.  I think it would be nearer 1000.  So the overheads are in the
> 10- to 100-k byte range (100k ~= 0.5% of the image) on 32-bits.  That's low
> but it's also pure overhead.  Every GC has to visit them.  Every senders
> and implementors has to visit them, but they offer nothing of value.
> Whereas the small parser for whatever notation is used to store the
> constants externally (if they are needed in a given deployment) has a small
> constant overhead; its simple code.
>
> Further, you still need the machinery to export the constants to be able
> to generate these initialization methods.  If you've got the machinery and
> you don't need the methods why bother to generate the methods?
>
> As the Scots say, many a mickle makes a muckle.


Thank's Eliot for such detailed explanation. It makes sense.
But personally I prefer Smalltalk solution although Smalltalk itself is
pure overhead comparing to C.

My question was raised by Mariano idea to save ston files in methods. I
think it can reduce problems which you described.
But then literal array syntax can be more suitable than ston.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160123/2543ddcf/attachment.htm