Dear Marc,
Gambit on 32bit architectures suffer badly of the limitations on maximum string, vector and also fixnum sizes.
For some uses, this is more than enough as reason to disqualify 32bit architecture use altogether.
A thought struck me the other day - the reason for those low limits on 32bit architectures, is that Gambit delivers the native integer/pointer size of the underlying architecture, and that leads to those limitations because of how Gambit's type system is built. You could say that the overarching reason is speed.
My thought is, if a given user would like to take the speed argument out of the equation,
Would it be possible for you to easily provide a "forced 64bit word" compilation mode for Gambit, hence lifting the string, vector and fixnum size limits far beyond their current ones of 4M-chars, 16MB u8vector, and is it 2^29 as max fixnum value.
(The string and u8vector limits are the central concerns really.
The effect on fixnum would be higher speed of computation in the 2^29..2^61 interval at the cost of slightly lower speed in the 0..2^29 interval.)
This would only be relevant to run on some fairly standard architecture and platform.
If the tweak would be possible, would Gambit's total live objects be able to amount to 2GB or 4GB, or how much?
Thanks!
Afficher les réponses par date
Forcing 64 bit “words” on a 32 bit machine should be relatively straightforward to implement, but I question the utility of this (factor of 2 space usage). Better would be to change the object representation so that the header of objects would be always 64 bits (or better, split into a 32 bit length and 32 bit type and GC flags). The implementation complexity of both is about the same (roughly 2 days of work). However, too much work for me right now given the low need for this feature.
Aren’t 32 bit architectures pretty much a thing of the past? These days, even embedded systems are 64 bit architectures.
Marc
On Aug 3, 2016, at 3:49 AM, Adam adam.mlmb@gmail.com wrote:
Dear Marc,
Gambit on 32bit architectures suffer badly of the limitations on maximum string, vector and also fixnum sizes.
For some uses, this is more than enough as reason to disqualify 32bit architecture use altogether.
A thought struck me the other day - the reason for those low limits on 32bit architectures, is that Gambit delivers the native integer/pointer size of the underlying architecture, and that leads to those limitations because of how Gambit's type system is built. You could say that the overarching reason is speed.
My thought is, if a given user would like to take the speed argument out of the equation,
Would it be possible for you to easily provide a "forced 64bit word" compilation mode for Gambit, hence lifting the string, vector and fixnum size limits far beyond their current ones of 4M-chars, 16MB u8vector, and is it 2^29 as max fixnum value.
(The string and u8vector limits are the central concerns really.
The effect on fixnum would be higher speed of computation in the 2^29..2^61 interval at the cost of slightly lower speed in the 0..2^29 interval.)
This would only be relevant to run on some fairly standard architecture and platform.
If the tweak would be possible, would Gambit's total live objects be able to amount to 2GB or 4GB, or how much?
Thanks!
2016-08-07 20:34 GMT+08:00 Marc Feeley feeley@iro.umontreal.ca:
Forcing 64 bit “words” on a 32 bit machine should be relatively straightforward to implement, but I question the utility of this (factor of 2 space usage). Better would be to change the object representation so that the header of objects would be always 64 bits (or better, split into a 32 bit length and 32 bit type and GC flags). The implementation complexity of both is about the same (roughly 2 days of work).
Ah, I think you corrected a limited understanding on my behalf - actually it's the object header that would need to be tweaked, rather than the object representation, as the object header contains string and u8vector lengths.
However, too much work for me right now given the low need for this feature.
Great - right - this was only a question.
Aren’t 32 bit architectures pretty much a thing of the past? These days, even embedded systems are 64 bit architectures.
I would have hoped they were!
Tell me a single commodity ARM board on the market with a 64bit chip. I'm not aware of a single one.
On the X86 embedded side, there are some Intel Atom processors that do 64bit.
The world abounds of 32-bit boards however and they start from like 10 USD.
Thanks for answering that it indeed is possible
On Sun, Aug 07, 2016 at 08:34:43AM -0400, Marc Feeley wrote:
Forcing 64 bit “words” on a 32 bit machine should be relatively straightforward to implement, but I question the utility of this (factor of 2 space usage). Better would be to change the object representation so that the header of objects would be always 64 bits (or better, split into a 32 bit length and 32 bit type and GC flags). The implementation complexity of both is about the same (roughly 2 days of work). However, too much work for me right now given the low need for this feature.
Aren’t 32 bit architectures pretty much a thing of the past? These days, even embedded systems are 64 bit architectures.
I'm still using 32 bit machines. They work fine as long as I don't run out of RAM. Except for browsers, I don't have trouble with RAM running out.
-- hendrik
On Sun, Aug 07, 2016 at 07:02:00PM -0400, Hendrik Boom wrote:
On Sun, Aug 07, 2016 at 08:34:43AM -0400, Marc Feeley wrote:
Forcing 64 bit “words” on a 32 bit machine should be relatively straightforward to implement, but I question the utility of this (factor of 2 space usage). Better would be to change the object representation so that the header of objects would be always 64 bits (or better, split into a 32 bit length and 32 bit type and GC flags). The implementation complexity of both is about the same (roughly 2 days of work). However, too much work for me right now given the low need for this feature.
Aren’t 32 bit architectures pretty much a thing of the past? These days, even embedded systems are 64 bit architectures.
I'm still using 32 bit machines. They work fine as long as I don't run out of RAM. Except for browsers, I don't have trouble with RAM running out.
Mind you, if I used WIndows, I would have had to trow the machine out years ago.
-- hendrik