Considering amount of memory it is going to use and execution duration, which approach you would suggest?

These are the wrong criteria. The details you've provided are insufficient for anyone to reach a reasoned conclusion -- though many will try, based upon their own preferences, prejudices and dogmas.

The amount of memory your subtasks use is irrelevant provided that the total concurrent memory requirement is within the capabilities of your hardware. The same applies whether the subtasks are implemented as threads or processes.

The duration for which the subtasks run is equally irrelevant. Threads and processes are equally capable of running reliably for long periods.

The kind of criteria you should be considering

Do your subtasks need read-write access to shared data? If not, why are you considering threads?

Is the 1GB of data per subtask different for each subtask, or shared by all the subtasks? If the latter, then you may well find that the process model is more economic because of copy-on-write; but be aware of subtle internal factors that can cause apparently 'read-only' references to COW data to induce copying.

For example: if you load shared numeric data from a file, it gets stored initially as strings. If your subprocesses the use that in a numeric context, then the PV will get upgraded to an NV or IV and the 4096 page containing that value will be copied. And each time a new subprocess accesses that same value, that page will be copied again. And if every one of your 100+ subprocesses accessed every value -- or just one value on each page -- then the entire shared memory would end up get copied piecemeal 100+ times. (This scenario can be avoided by touching those numeric strings in a numeric context before spawning the subprocesses; but there are other, more subtle scenarios that can lead to similar affects.)

The bottom line is, if your application can be written to use processes without having to jump through hoops to make it work, and you are more comfortable with processes, then use them.

If however, you believe your application could benefit from, or be easier to write, using threads, then don't be put off by the threads-are-spelt-F_O_R_K dinosaurs. For many applications, threads are easier to use and reason about. Supply a few more details and we can compare possible solutions.