An integer's life span?

[Sam Kong]

Hello!


Here's my code.

---------------------
class Integer
def prime?
return false if self < 2
return @is_prime if @prime_cached
@prime_cached = true
(2..(self ** 0.5)).each do |i|
return (@is_prime = false) if i.prime? and self % i == 0
end
@is_prime = true
end
end
---------------------

I want each integer to remember if it's a prime number or not.
As the calculation uses cache of smaller prime numbers, it runs fast.
But I'm not sure if the cache is preserved after GC runs (when nothing
refers to the integers).
If the cache is not preserved, it's no use.

My first idea was keeping the cache in a class variables like
@@prime_numbers and @@max_cached.
But I think it would be better if each object remembers its own state.

What do you think?

Sam

 

[Eric Hodel]

I want each integer to remember if it's a prime number or not.
As the calculation uses cache of smaller prime numbers, it runs fast.
But I'm not sure if the cache is preserved after GC runs (when nothing
refers to the integers).
If the cache is not preserved, it's no use.

IIRC an Integer's instance variables are eternal due to various
implementation details.

 

[Gregory Brown]

IIRC an Integer's instance variables are eternal due to various
implementation details.

Specifically due to the fact that integers are immediate values in ruby.
(Thus, are never collected)

So, attr_accessor prime would probably due the trick.

 

[Gregory Brown]

So, attr_accessor prime would probably due the trick.

err, typo there, and here is an example of what i mean.

bash-3.1$ irb=> [1, 2, 3, 5, 7]

might want to add a prime? method too.

 

[Sam Kong]

Specifically due to the fact that integers are immediate values in ruby.
(Thus, are never collected)

Thank you for the answer.
This is good news for my purpose.
However, that creates another worry.

(1..100000).each {|i|...}

Now there are 100000 integers in the memory which won't die.
Is it okay?

Sam

 

[Gregory Brown]

Thank you for the answer.
This is good news for my purpose.
However, that creates another worry.

(1..100000).each {|i|...}

Looks like in this case, they are garbage collected?

at startup
bash-3.1$ pmap 7764 | grep "total"
total 4560K

after each
bash-3.1$ pmap 7764 | grep "total"
total 4560K

Now there are 100000 integers in the memory which won't die.
Is it okay?

but after adding an accessor for x, and setting it to true:
(1..100000).each { |i| i.x = true }

bash-3.1$ pmap 7764 | grep "total"
total 16308K

Big increase, but still not *that* bad.

 

[Rick DeNatale]

Hello!


Here's my code.

---------------------
class Integer
def prime?
return false if self < 2
return @is_prime if @prime_cached
@prime_cached = true
(2..(self ** 0.5)).each do |i|
return (@is_prime = false) if i.prime? and self % i == 0
end
@is_prime = true
end
end
---------------------

I want each integer to remember if it's a prime number or not.
As the calculation uses cache of smaller prime numbers, it runs fast.
But I'm not sure if the cache is preserved after GC runs (when nothing
refers to the integers).
If the cache is not preserved, it's no use.

My first idea was keeping the cache in a class variables like
@@prime_numbers and @@max_cached.
But I think it would be better if each object remembers its own state.

What do you think?

I'm pretty sure that your concern about GC is moot, but just as long
as you stay with in the range of Fixnums. Fixnums are 'immediate'
objects, and never get collected. I Bignums are another matter.

For Fixnums your code works as is. The @prime_cached iv is not needed
however, here's another way to do it:

class Integer
def prime?
return false if self < 2
return @is_prime unless @is_prime.nil?
(2..self**0.5).each do | i |
return (@is_prime = false) if i.prime? and self % i == 0
end
@is_prime = true
end
end

--
Rick DeNatale

IPMS/USA Region 12 Coordinator
http://ipmsr12.denhaven2.com/

Visit the Project Mercury Wiki Site
http://www.mercuryspacecraft.com/

 

[Jeremy Henty]

(1..100000).each {|i|...}

Now there are 100000 integers in the memory which won't die.

No there aren't. Immediate values don't allocate anything in memory.
They aren't pointers (even though under the hood Ruby coerces them to
the same type as non-immediate values that *are* pointers). Immediate
values aren't garbage collected because there is *nothing* to garbage
collect. They don't point to anything. What is there to collect?

Think of C. Does "long i ; i = 0 ; i = 1 ; i = 2 ; i = 3" consume any
more memory than "long i ; i = 0"? No, because the only memory
allocated is for the long variable "i". The values 0, 1, 2, 3, are
just constants that are copied (one after the other) into that single
previously allocated space. Ruby's immediate values are just like C
longs (in fact, under the hood, they *are* just C longs). Creating
them doesn't consume memory, it just copies them into a pre-existing
chunk of memory that was already allocated by the Ruby interpreter.

If you create lots of *references* to immediate values, eg. by writing
" a = (1..100000).collect {|i| i } ", then that *will* consume memory.
But that memory isn't being used to create immediate values, it's
being used to store those values inside an object. Once that object
is no longer referenced the memory is available to be recycled by the
garbage collector. All memory allocation/deallocation is associated
with the non-immediate object that holds those references. The
immediate values themselves allocate no memory at all.

Regards,

Jeremy Henty

 

[Eric Hodel]

(1..100000).each {|i|...}

Now there are 100000 integers in the memory which won't die.

No there aren't. Immediate values don't allocate anything in memory.
[... an accurate description of class Fixnum's implementation]

Also, since a Fixnum is immediate, it doesn't "have" instance
variables because there's no Object to store them in. Instead they
are stored somewhere else. (Where isn't terribly important.)

The instance variables will consume memory, of course.

 

[Sam Kong]

Hi Jeremy,

No there aren't. Immediate values don't allocate anything in memory.
They aren't pointers (even though under the hood Ruby coerces them to
the same type as non-immediate values that *are* pointers). Immediate
values aren't garbage collected because there is *nothing* to garbage
collect. They don't point to anything. What is there to collect?

Think of C. Does "long i ; i = 0 ; i = 1 ; i = 2 ; i = 3" consume any
more memory than "long i ; i = 0"? No, because the only memory
allocated is for the long variable "i". The values 0, 1, 2, 3, are
just constants that are copied (one after the other) into that single
previously allocated space. Ruby's immediate values are just like C
longs (in fact, under the hood, they *are* just C longs). Creating
them doesn't consume memory, it just copies them into a pre-existing
chunk of memory that was already allocated by the Ruby interpreter.

I understand what you said.
But the integers that I created have additional information.
So not that simple.
Can you read the code I wrote and reconsider such a case?

Thank you.

Sam

 

[Eric Hodel]

I understand what you said.
But the integers that I created have additional information.
So not that simple.
Can you read the code I wrote and reconsider such a case?

It will work. The instance variables are stored elsewhere.

 

[Jeremy Henty]

Also, since a Fixnum is immediate, it doesn't "have" instance
variables because there's no Object to store them in. Instead they
are stored somewhere else. (Where isn't terribly important.)

Thanks for pointing that out. I had never thought to wonder where
immediate objects put their instance variables. Live and learn!

Jeremy Henty

 

[Rick DeNatale]

Thanks for pointing that out. I had never thought to wonder where
immediate objects put their instance variables. Live and learn!

I hadn't either, and it once again impressed me with Ruby.

About 20 years ago there was a raging discussion between advocates of
REALLY dynamic OO languages like self, and more traditional dynamic OO
languages like Smalltalk.

Dave Ungar, who did most of if not all of the implementation of
Berkley's Smalltalk, and wrote his PhD dissertation on analysing it's
performance, and then went on to develop self, used to love to ask
people who had done Smalltalk implementations to dynamically add an
instance variable to Object, something which invariably crashed, or
inf-looped whatever Smalltalk VM it was tried on.

Ruby not only can do that, but it can add instance variables to instances.

Nice job, Matz!