programagor / rainbrot Goto Github PK

All inputs need to be validated!

--iter=10,100,1000 results in file 10-99 which is full of zeros, regardless of other parameters.

When multithreading is enabled (--threads=2 or more), all threads compete for the last point. Consider this scenario:

+-----------------------------+-------------------------+
| Thread 1                    | Thread 2                |
+-----------------------------+-------------------------+
| Gets c1 from RNG            | Waits for RNG           |
| Runs preiterator            | Gets c2 from RNG        |
| Runs preiterator            | Runs preiterator        |
| Runs preiterator            | c2 valid, runs iterator |
| c1 valid, but runs exceeded | Runs iterator           |
| Quits                       | Returns c2 orbits       |
+-----------------------------+ Quits                   |
                              +-------------------------+

Here, c1 should have been the point to be ran through the iterator because it came first from the RNG, but c2 completed the preiterator first, so it entered the iterator stage first. This results in a race condition!

This is caused by 34412b9, which enabled multiple threads searching for the last point.

When one worker finishes its point and tries to go to the last one, but another worker is already working on the last one, the thread quits. Therefore, the search effort is not distributed.

I recently discovered this repository and have been attempting to run it, but am not entirely sure where to start. I've attempted to run raindraw_wrapper.m using MATLAB, but that just leads to an issue where the .rain file seems to not exist, not generate, or something else entirely. I'm a novice with MATLAB, though, so this might be entirely my fault...

[20-Sep-2023 12:41:19] Iteration 1 (10-49)
[20-Sep-2023 12:41:19]   Opening file...
[20-Sep-2023 12:41:19]   Reading file...
Error using fread
Invalid file identifier. Use fopen to generate a valid file identifier.

Error in raindraw (line 12)
        t(:,:,4-i)=fread(f,dim([2,1]),'uint64');

Error in raindraw_wrapper (line 10)
raindraw(dir,iter,dim,[r;g;b],1);```

Additionally, I couldn't figure out exactly how to use any of the documentation included in the `README.md`. This might be because I couldn't figure out how to open the files and get it to work to begin with, but... Again, that's likely just me. Apologies for my unlearned-ness; I'm very interested in this program regardless of how little I can understand its machinations. 

Thanks in advance for the help.

The --window parameter seems to produce unexpected results. The documentation specifies that it is supposed to be of the following format:

  -w, --window=RE_MIN,IM_MIN,RE_MAX,IM_MAX
                             Displayed area of the Gauss plane

However, during testing, it was found that the results are only ever consistent if -RE_MIN == RE_MAX and -IM_MIN == IM_MAX.

It looks like the lower bound is sometimes ignored.
bin/rainbrot-gen -v --threads 1 --iter 100000,1000000 --bail 2 --window -4,-4,4,4 --size 1000x1000 --runs 1 produces a file, which after summing contains less than 100000 hits. That seems wrong.

Use of rand() is discouraged, because the quality of the produced distribution has some undesirable characteristics. I haven't noticed any effects of that in the images, but better play it safe.

This code runs just fine, but wastes resources during the last run.

The idea is that instead of looping immediately, it waits after the check. A thread which writes into the OK Queue then broadcasts a signal, so that all threads which are waiting can recheck.

Currently, the distribution of the considered points is centered at 0+0i, and has a standard deviation of 1+1i
It would be nice to allow the user to pass their own custom parameters as a command line argument.

The associated code is here:

On top of showing progress as percentage, it would be good to estimate the remaining time of the batch. This can be done as remaining_time=remaining_runs*elapsed_time/completed_runs

For each .rain file which is being accessed, create a new .rain.lock file that is destroyed after the batch has completed. This is to avoid accidentally running 2 workers on a single file. Maybe it woj't cause issues, but I'd need to look at documentation of mmap().

Right now, the program can be interrupted while a thread is writing its buffer into the output memory/file. This results in a band visible in the output image.

Let's implement SIGTERM handling, which interrupts the worker threads only at specified points (i.e. not while writing to a file)

Probably some malloc() fails and return isn't checked against NULL. The segfault occurs after workers are started.

  - 6. worker   ... done.
All workers up and running
Segmentation fault (core dumped)

Currently, the entire file is locked if a row in it is being modified. This is done here:

When using the option --window with arguments much above 400x400, a segfault occurs after a few runs (and file syncs)

This file would store:

• resolution
• window
• iteration depth
• list of runs, each containing
  • dirtribution parameters
  • seed of PRNG
  • number of runs

This is useful for merging tiles.

When running rainbrot --size=AxB where A ≠ B, SEGFAULT is produced just after worker threads are spawned.

Moreover, the files produced have a wrong size, as if --size=BxB.