Closed rzuckerm closed 1 year ago
@rbergen I think I addressed all your comments. Please approve the workflow so that I can see if anything else needs to be changed. Thanks!
@rbergen I think I addressed all your comments. Please approve the workflow so that I can see if anything else needs to be changed. Thanks!
I don't think I agree, for the following reasons:
My apologies, I overlooked some of the changes you made when I wrote the previous text. My actual response is that I don't think we're there yet, because a CHAR definitely does not have a bit size of 1, but at least 8.
A question I have is if you've definitely established that a "delete" of an instantiated struct is not something you can trigger?
I'd (still) really like to have a "semifinal" version of the solution (i.e. one without open topics) in place before I trigger CI. Otherwise, it will have to run after every change that is made, even if it only concerns documentation.
My apologies, I overlooked some of the changes you made when I wrote the previous text. My actual response is that I don't think we're there yet, because a CHAR definitely does not have a bit size of 1, but at least 8.
I change the bit size to 8
A question I have is if you've definitely established that a "delete" of an instantiated struct is not something you can trigger?
Algol automatically implements garbage collection, so there is no way to directly trigger a delete. However, garbage collection can be forced with the sweep heap
function. I have added this. I also added some heap debugging to show how many bytes were recovered due to garbage collection in the main loop. This is currently disabled, but I ran it once with it enabled, and here's what is showed:
+0
+4000664
+4000664
+4000664
+4000664
+4000664
...
I really appreciate you triggering the garbage collection manually, but it's not necessary to take it to that level. We don't demand this of any other managed memory language/platform either. At the same time, I think your debug run actually shows that the number of bits per prime is not 8, but 32; the sweep heap
function seems to clear a little over 4 million bytes for 1 million prime candidates. Which makes sense if the CHAR type actually represents UTF-32 characters.
I'd like to propose the following:
sweep heap
/heap debugging combination to determine the size of the BOOL type. Base the bit count in README and program output on that.sweep heap
and anything related to heap debugging from the source code.After these changes have been made, I'm happy to trigger CI and move forward towards merging this.
I changed back to BOOL
, and the heap didn't change by much:
4000896
Since I only store odd values, there are only 500000 bins. Based on this, it looks like it might be 64-bits, which seems really wasteful. :frowning_face:
I'm just going to use unknown
and be done with it. I suspect, the value changes based on machine word size, which is 64 for my case.
It would be wasteful. It could just be that under the hood, every integer type is implemented as a "long int". I have seen that before. You may also be right that it is machine dependent. I'm happy to accept your findings as support for a prime candidate bit size of 64, but you can also choose to stick to "unknown" as you seem to prefer. Do note that in the benchmark output line that the program outputs, the "bits" flag then needs to be removed. Its absence in the output is the indication that the actual bit size is unknown.
I've taken the liberty of removing the flag from the benchmark output myself. I hope that's ok. It does come with the benefit that CI is triggered immediately.
Looks like the CI worked. Thanks for your help @rbergen !
Description
Initial Algol 68g implementation.
Contributing requirements
drag-race
as the target branch.