Am 18.07.2013 um 23:08 schrieb Charles Steinkuehler <[email protected]>:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/18/2013 3:50 PM, Michael Haberler wrote: >>> *) for instance, using mmap() on a file of intermediate >>> language, which makes the size problem go away; cost: an existing >>> interpreter likely needs modification. > > Doesn't mmap() limit you to the physical addressing of the processor? VM space and file size limits - for that particular approach (I did tag it with 'for instance' on purpose) > That might not be a huge issue on today's 64-bit systems, but it's > already a problem on the 32-bit architectures, and is very likely > directly responsible for the 1G file size limitation on a standards > compliant DVD. > > In my day job, I'm moving around 100s of MBytes of data a second, > pretty much continuously, so I tend to think more in streams and how > much context needs to be locally stored at any one time instead of the > overall size of whatever it is I'm processing. A single video frame > is only a couple Meg, but if you run one of our 8-input boxes for a > day straight (not at all uncommon) I've streamed about 83 TB of data. > > ...so I see the gcode interpreter as requiring a chunk of memory for > general state data, another chunk of memory to store "sub-routines", a > pointer to the gcode stream/file/whatever, and probably an elastic > buffer to decouple the real-time motion stuff from the non-real-time > "pull gcode out of the cloud" code. Very low system requirements, and > "file" size is not arbitrarily limited by anything but how long it > takes to process. I think that is an entirely valid consideration for video stream processing, which just has to be infinite by design However, one of several things your systems never have to do, but the LinuxCNC pipeline should be able to do is: backup in execution and recalculate parts of the stream so the video stream analogy isnt very helpful in addressing deficiencies even if describes the current architecture - Michael > > - -- > Charles Steinkuehler > [email protected] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlHoWVoACgkQLywbqEHdNFwyOQCdF0g2E3gMDeHIBE2aSzRnegi5 > YfkAoMSEnNZVVhkYZ5EL3ycnZ6OqECaq > =gacw > -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
