I work for NVIDIA doing 3d graphics engines and editor platforms on both PC and embedded platforms.
Konrad, the extra memory allocation is often the difference between something fitting inside a cache line on a CPU and hitting main ram. Last time I looked, I believe the difference is a factor of 100. This is exacerbated on embedded platforms such as ARM where your on-chip cache is anemic and you CPU is still quite bandwidth starved in terms of main-memory. The inability to exactly position datasets in memory is the key performance difference between c++ and java in my book. Creating some piece of information lazily that sits outside my current dataset for no reason is absolutely not acceptable. I have pretty full confidence that I could produce a java-based graphics runtime that would work fine on most cell-phones, android or otherwise and produce graphics on par with anything currently done in C or any other language *if* I can pack objects into distinct contiguous blocks of memory that I will then run through and sequentially access each render step. Currently Java doesn't give me this ability (for no obvious reason) and thus I can't easily produce very performant code. Lazy sequences hurt my limited ability (due to their extra memory allocation) to control memory layout and access semantics of what I am doing and thus have an extremely serious impact on what I am doing. C# and Mono, btw, do allow this as their generics implementation is allows their struct datatypes in lists. Should clojure provide a wrapper on the trusty old int array that allows me to use it like an array of structures then we would be at least halfway there, assuming I could force JVM to put the array into contiguous memory. Closures and runtime-generated code in general, btw, represent a possible way for me to beat a C based runtime as I can create specialized functions instead of having a bunch of branches and if- statements. So there is a tradeoff going the other way. Anyway, any extra memory allocation I don't specifically require is going to have severe impacts if I can't disable it. So streams fit the bill *much* better than lazy seqs. I am apparently someone who loves doing stream processing. Chris On Jan 23, 10:34 am, e <evier...@gmail.com> wrote: > people who love doing stream processing would attack an extra allocation. > > On Fri, Jan 23, 2009 at 12:09 PM, Konrad Hinsen > <konrad.hin...@laposte.net>wrote: > > > > > On Jan 23, 2009, at 14:04, Rich Hickey wrote: > > > >> Then why not make a pipeline using lazy sequences right from the > > >> start? I don't see anything that I could do better with streams than > > >> with lazy sequences. > > > > There are a couple of advantages. First, streams are faster, at least > > > 2x faster. Since a lazy sequence must allocate per stage, a multi- > > > stage pipeline would incur multiple allocations per step. A stream > > > could be built that has no allocation other than the results. If your > > > calculations per step are significant, they'll dominate the time. but > > > when they are not, this allocation time matters. > > > > Second, streams are fully lazy. Seqs could be made fully lazy, but > > > currently are not. > > > > Third, stream iters currently provide transparent MT access. Doing the > > > same for a seq means wrapping it in a ref. > > > Thanks for those explanations, that makes a lot of sense. > > > I just wonder about the performance aspect. If I have a pipeline > > stage with very little computational cost, say adding 1 to every > > element, the I would expect the overhead of the iter layer and the > > thread-safeness to dominate CPU time anyway. Does an allocation > > really add that much on top of that that it makes a difference? > > > Konrad. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
