C++ unordered set out of memory - c++

Question

This program goes through every combination of 4 numbers from 1 - 400 and sees how many unique numbers can be made from the product.
I believe the unordered_set used to hold the already checked numbers is getting too large and thus it quits; task manager tells me it's at 1.5 GB.
Is there any way I can make this code run? I think maybe splitting up the set or somehow finding a more efficient formula.
Note: based on the comments, I would like to say again I am not storing all 25 billion numbers. I'm only storing ~100,000,000 numbers. The question has a RANGE of 400, but I'm looking for a comprehensive solution that can handle 500, or even 1000 without the memory problem.
#include <iostream>
#include <unordered_set>
using namespace std;
const int RANGE = 400;
int main(){
unordered_set<long long> nums;
for(long long a=1; a<=RANGE; a++)
{
for(long long b=a; b<=RANGE; b++)
{
for(long long c=b; c<=RANGE; c++)
{
for(long long d=c; d<=RANGE; d++)
{
unordered_set<long long>::const_iterator got = nums.find(a*b*c*d);
if (got == nums.end())
{
nums.insert(a*b*c*d);
}
}
}
}
cout << a << endl;
}
cout << nums.size() << endl;
return 0;
}

Answer 1

You will need to compile the code with a 64-bit compiler to allow allocating of more than around 2GB of memory. You will also need at least 4GB of RAM on the machine you are running this on, or at best it will take almost forever to finish.
A "bitset", using a single bit per entry will take up about 3GB of memory.
Using the code as it stands, it will use around 4GB of memory on a Linux machine with 64-bit g++ compiler, and it takes around 220 seconds to complete, giving the answer:
86102802
1152921504606846975
According to /usr/bin/time -v:
Command being timed: "./a.out"
User time (seconds): 219.15
System time (seconds): 2.01
Percent of CPU this job got: 99%
Elapsed (wall clock) time (h:mm:ss or m:ss): 3:42.53
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 4069336
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 679924
Voluntary context switches: 1
Involuntary context switches: 23250
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0

Answer 2

Your solution works by doing every unique permutation of four numbers between 1 and 400, multiplying them, and storing the results, and then counting them. At a minimum, this would take 400*400*400*400bits ~3GB, which is apperently more than your hardware/compiler/OS can handle. (Probably the compiler, which is easy to fix)
So what if we try to solve the program one step at a time? Can we count how many sets of these numbers have products between 1000 and 2000?
for(a=1; a<400; ++a)
{
bmin = max(1000/a/400/400, a); //a*b*400*400 is at least 1000
bmax = min(2000/a, 400); //a*b*1*1 is at most 2000
for(b=bmin; b<=bmax; b++)
{
cmin = max(1000/a/b/400, b); //a*b*c*400 is at least 1000
cmax = min(2000/a/b, 400); //a*b*c*1 is at most 2000
for(c=cmin; c<=cmax; c++)
{
dmin = max(1000/a/b/c, c); //a*b*c*d is at least 1000
dmax = min(2000/a/b/c, 400); //a*b*c*d is at most 2000
for(d=dmin; d<=dmax; d++) //this will usually be zero, one, or two numbers
{
res = a*b*c*d;
if (res>=1000 && res<2000) //a rare few WILL be outside this range
YES
We can simply count how many products between 0-1000 are accessible, then 1000-2000, then 2000-3000, etc, up to 400*400*400*400. This is a significantly slower algorithm, but since it takes very little memory, the hope is that the increased cache coherence will make up for some of the difference.
In fact, speaking of very little memory, since the target numbers in each batch are always in a sequential range of 1000, then you can use a bool nums[1000] = {} instead of an unordered_set, which should give a significant performance boost.
My full code is here: http://coliru.stacked-crooked.com/a/bc1739e972cb40f0, and I have confirmed my code has the same results as yours. After fixing several bugs, your algorithm still vastly outperforms mine for small RANGE with MSVC2013. (For anyone else testing this with MSVC, be sure to test with the debugger NOT attached, it makes a HUGE difference in the timing of the original code)
origional( 4) found 25 in 0s
duck( 4) found 25 in 0s
origional( 6) found 75 in 0s
duck( 6) found 75 in 0s
origional( 9) found 225 in 0s
duck( 9) found 225 in 0s
origional( 13) found 770 in 0s
duck( 13) found 770 in 0s
origional( 17) found 1626 in 0.001s
duck( 17) found 1626 in 0s
origional( 25) found 5135 in 0.004s
duck( 25) found 5135 in 0.002s
origional( 35) found 14345 in 0.011s
duck( 35) found 14345 in 0.015s
origional( 50) found 49076 in 0.042s
duck( 50) found 49075 in 0.076s
origional( 71) found 168909 in 0.178s
duck( 71) found 168909 in 0.738s
origional( 100) found 520841 in 0.839s
duck( 100) found 520840 in 7.206s
origional( 141) found 1889918 in 5.072s
duck( 141) found 1889918 in 76.028s
When I study the issue, what finally occurred to me is that my algorithm requires a large number of 64bit divisions, which seems to be slow even in 64bit operating systems.