3 ms·

Right? > In effect, Romu generators are infinitely fast when inlined. What the hell does "infinitely fast" even MEAN in this context? They can be parallelized

Right? > In effect, Romu generators are infinitely fast when inlined. What the hell does "infinitely fast" even MEAN in this context? They can be parallelized easily? The computational cost amortizes well? That it literally requires zero operations to generate output? This may be something interesting if it packs a lot of the features claimed. But there are a LOT of ill-defined claims on the website, and a fair bit of time spent pointing to the state of current research in OTHER algorithms/proposals as if open questions are an automatic disqualification ("[H]ow can you know whether such a generator has enough capacity for your large job? You don’t know."). I don't think the guy is a crank, per se-- just excited. But this is the sort of stuff that makes me think that he hasn't done the requisite level of research required before claiming a breakthrough.

clarry 7y ago
> What the hell does "infinitely fast" even MEAN in this context? It's nonsense, but their argument seems to be that instruction level parallelism allows the RNG's user to keep executing simultaneously while the RNG pre-computes its next output. So the application doesn't have to delay execution to wait for the RNG to spit something out.
- blattimwind 7y ago
  Well that clearly assumes that the user code is not utilizing most of the issue bandwidth or rather that the unutilized issue bandwidth is sufficient to run the RNG and that there are enough EUs left over to actually run it. In that case you do indeed get operations "for free" (in terms of wall-clock time), because your extra operations are exactly contained within the increased IPC. It doesn't mean that it is infinitely fast. It does however mean that in this particular case it adds no latency for adding random number generation; an infinitely fast algorithm would also add no latency for random number generation. Doesn't mean one implies the other.
  - MarkOverton 7y ago
    Yes, the output latency is zero clock cycles. The paper contains ILP tables that detail what happens in each clock cycle. The generator computes its next output while the application is running. But you are correct in that the statement (and ILP table) assumes that the application is not using all available issue-slots.

clarry 7y ago

> What the hell does "infinitely fast" even MEAN in this context? It's nonsense, but their argument seems to be that instruction level parallelism allows the RNG's user to keep executing simultaneously while the RNG pre-computes its next output. So the application doesn't have to delay execution to wait for the RNG to spit something out.

blattimwind 7y ago
Well that clearly assumes that the user code is not utilizing most of the issue bandwidth or rather that the unutilized issue bandwidth is sufficient to run the RNG and that there are enough EUs left over to actually run it. In that case you do indeed get operations "for free" (in terms of wall-clock time), because your extra operations are exactly contained within the increased IPC. It doesn't mean that it is infinitely fast. It does however mean that in this particular case it adds no latency for adding random number generation; an infinitely fast algorithm would also add no latency for random number generation. Doesn't mean one implies the other.
- MarkOverton 7y ago
  Yes, the output latency is zero clock cycles. The paper contains ILP tables that detail what happens in each clock cycle. The generator computes its next output while the application is running. But you are correct in that the statement (and ILP table) assumes that the application is not using all available issue-slots.