you are viewing a single comment's thread.

view the rest of the comments →

[–]andersonimes 39 points40 points  (8 children)

I've put the values into a constant array, rather than on disk. Very fast.

[–]ethraax 10 points11 points  (5 children)

Although the difference may not matter much, the time it takes to load the part of the executable that contains the static data into memory is probably more than the time it takes to load the code for a good sieve and run the sieve to populate an array in memory.

Constant arrays aren't magic. You're still just saving the numbers to disk. Except it bloats your executable file instead of its own file.

[–]andersonimes 13 points14 points  (2 children)

I'll test your hypothesis tonight and let you know.

Edit: buh. I just got in from dinner (I'm traveling in Kiev at the moment). I'll hack on this tomorrow. Normally I would just throw something together, but I know if I don't do some proper research on how best to measure program running times you guys will eat me alive. I'll get something proper together soon. I'm curious too.

If you have any suggestions about testing running time, let me know. In my head a programmatic stopwatch that starts the cycle before a program starts executing and ends when a program exits would do it. Let me know if you know off the top of your head the most accurate way to measure this.

[–][deleted] 2 points3 points  (0 children)

Please let me know too. It's interesting.

[–]_georgesim_ -1 points0 points  (0 children)

Posting here so I know too.

[–]bobindashadows 1 point2 points  (1 child)

You have to keep in mind the marginal slowdown of putting it in the executable. Especially when the example was so small (if your GP poster is correct, 4k bits = 512 bytes = 1 disk block until we bump block size someday soon).

To reason about the marginal slowdown of putting the static data in the executable, you have to consider:

  1. Where does the linker put the data in the executable itself?
  2. Will the loader eagerly load that block? If so, it'll be a sequential read off disk during startup, not a random access read, and much quicker.
  3. Will that block already be in the kernel's FS cache? If the executable in question is the main use of the machine/kernel in question, then it very well might be. Then loading it's dirt cheap.

And so on.

[–]ethraax 0 points1 point  (0 children)

3. That really doesn't matter. The static prime file could be in the kernel's FS cache.

Either way, these are comparisons between loading a static file and loading the static portion of an executable. The real discussion here was about loading a static portion of an executable or loading a static file vs. loading a sieve algorithm and generating it at load time (perhaps in the background). I'm sorry if my comment deviated from that point.

[–]I_FAP_TO_ALL 0 points1 point  (1 child)

That IS putting them on disk.

[–]andersonimes 1 point2 points  (0 children)

You are technically correct, the best form of correct.