views:

99

answers:

4

I need to generate uncompressible data (therefore pseudorandom), and have been trying with the code below. But it's only producing about 10MB/s of data. I need about 100-200 MB/s. Do you have any advice?

if ($length > 8*1024*1024){ //Default max string length in php.
    while (($length - $bytesGenerated)>8*1024*1024){
        $bytesGenerated = $bytesGenerated + (8*1024*1024);
        print(openssl_random_pseudo_bytes(8*1024*1024));
    }
}
print(openssl_random_pseudo_bytes($length - $bytesGenerated));
+4  A: 

if you are working under linux you could just read from /dev/urandom, its kernels fast pseudorandom generator.

on the other way you could use openssl rand and pipe that into php.

damir
U sure it can give you 200Mb/sec? I vote for 10-20Mv/sec max )
BarsMonster
Regarding the speed of /dev/urandom a quick google tells me I should expect atleast 20MB/s
Robert Foss
Google told me it's 3.5Mb/sec :-)dd if=/dev/urandom of=foo bs=1M count=100000100000+0 records in100000+0 records out104857600000 bytes (105 GB) copied, 30104.4 s, 3.5 MB/s
BarsMonster
+2  A: 

That's gonna be hard on PHP, even with accelerators. I would write C++ module specifically for that feature (but even on C++ it's not very easy).

BarsMonster
+4  A: 

Do you need cryptographic-safe pseudo random numbers? Otherwise you could try to implement a Linear feedback shift register

Silfverstrom
I'd use "high quality" rather than "real" in this context: try defining when a messy looking stream is "really" pseudo-random... But if real time generation is a requirement ask if you really need a cryptographic quality stream. Crappy and fast may be the way to go...
dmckee
You're right of course.
Silfverstrom
No way PHP implementation would give 200Mb/sec. Just impossible, until PHP would feature JIT compiler :-)
BarsMonster
Yeah i think it's a tough task to do in PHP. Maybe by writing a c-extension
Silfverstrom
+1  A: 

At peak theoretical maximum performance on a 3GHz CPU (x86), you would have a budget of just under 4 CPU instructions per random byte, if you were trying to hit 200MB/s. Real-world performance is going to be considerably less than this. I'd posit that this is going to be extremely difficult in any language. You're well into the kinds of speeds which tend to employ dedicated hardware accelerator (i.e. you're attempting to do 1.56Gbit per second). In networking or video applications, there is a considerable amount of external hardware dedicated to permitting this kind of throughput. An extremely efficient implementation in C or assembly might allow you to hit this constraint, but you're really hitting the limits of what is possible using just general-purpose hardware.

I would consider either pre-generating the data (as has already been suggested) or employing some kind of hardware crypto-accelerator in order to hit anything resembling these kinds of throughputs. I found this list of crypto accelerator hardware vendors.

As a final thought, you did in fact mean 200 mega bytes per second, right? If you meant mega bits then this problem is much more easily solvable.

Gian
The amounts are that considerable but speed is of the essence. A cached solution would be fine./dev/urandom @ ~20MB/s is going to be fine for the time being. A 4cored x64 CPU would alleviate the raw performance issues, however the system would be strained (if at all possible). (bytes intended)
Robert Foss