Re: [Emc-users] How EMC face with the chanllege of hard, platform development? (muti-core, 64 bit processor etc)
On Saturday, Jeff Eppler wrote, in part: > Building the kernel and rtai are usually more time-consuming than > building emc itself. That leads us to build for a very small number of > operating system releases, and to build with conservative options that > we judge will work on the greatest number of machines. With the next > release we'll probably look at enabling SMP; we know that this will > restrict rtai to working only on systems with APIC, but in 2010 it's > probably only a small minority of machines that don't have APIC. If > testing proves us wrong, we'll take it out and remain restricted to > using a single CPU or core. In another few years, maybe we'll be in a > position to make a similar decision about 64 bits as the standard that > will work on all but a few uninteresting machines. > "To be (backward compatible) or not to be (backward compatible), that is the question". During my working life, I saw this problem crop up over and over again, both in hardware and in software. There will always be a "small minority" of working systems that don't meet new criteria. I wouldn't be surprised if a significant number of them are in machines being used to make a living. To the extent that the EMC2 developers can separate extensions and repairs of the EMC2 application-level software from the evolution of the underlying real-time O/S, the problem remains relatively manageable, since users of existing systems can stay abreast of the features that directly affect their ability to machine parts without the necessity (as opposed to desirability) of upgrading their computing platform too. I trust you and the other primary EMC2 developers to keep wrestling with the dynamic tension this situation creates. I trust the EMC2 users to be understanding that nothing is forever. Keep up the good work. Regards, Kent -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] How EMC face with the chanllege of hard platform development? (muti-core, 64 bit processor etc)
Thanks for Jeff nice reply which lead me know clear about that issue. 2010/3/7 Jeff Epler > Emc works properly on 64-bit and SMP systems. I routinely use and > develop emc on such a system with --enable-simulator (no realtime, no > hardware control). > > For realtime hardware control, emc depends on the underlying realtime > system (rtai). In 2007 I did a bit of work in this area, as detailed on > my blog >http://emergent.unpy.net/01180573281 >http://emergent.unpy.net/01181319466 > but I don't use a 64-bit or SMP kernel on the PC that controls my mill. > > Emc doesn't really derive any specific benefits from these systems; it > doesn't need large address spaces, and its CPU usage isn't particularly > high, at least in systems with no base_thread where you're not running a > resource-hungry GUI. Smart I/O boards like pico and mesa, and realtime- > friendly accelerated opengl (if you want to run axis) would be much > bigger contributors to a responsive system than SMP would be. > > Ultimately, it's the time to build and test each new platform that keeps > us from offering pre-built packages for every system our users would > like. Building the kernel and rtai are usually more time-consuming than > building emc itself. That leads us to build for a very small number of > operating system releases, and to build with conservative options that > we judge will work on the greatest number of machines. With the next > release we'll probably look at enabling SMP; we know that this will > restrict rtai to working only on systems with APIC, but in 2010 it's > probably only a small minority of machines that don't have APIC. If > testing proves us wrong, we'll take it out and remain restricted to > using a single CPU or core. In another few years, maybe we'll be in a > position to make a similar decision about 64 bits as the standard that > will work on all but a few uninteresting machines. > > Jeff > > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] How EMC face with the chanllege of hard platform development? (muti-core, 64 bit processor etc)
Emc works properly on 64-bit and SMP systems. I routinely use and develop emc on such a system with --enable-simulator (no realtime, no hardware control). For realtime hardware control, emc depends on the underlying realtime system (rtai). In 2007 I did a bit of work in this area, as detailed on my blog http://emergent.unpy.net/01180573281 http://emergent.unpy.net/01181319466 but I don't use a 64-bit or SMP kernel on the PC that controls my mill. Emc doesn't really derive any specific benefits from these systems; it doesn't need large address spaces, and its CPU usage isn't particularly high, at least in systems with no base_thread where you're not running a resource-hungry GUI. Smart I/O boards like pico and mesa, and realtime- friendly accelerated opengl (if you want to run axis) would be much bigger contributors to a responsive system than SMP would be. Ultimately, it's the time to build and test each new platform that keeps us from offering pre-built packages for every system our users would like. Building the kernel and rtai are usually more time-consuming than building emc itself. That leads us to build for a very small number of operating system releases, and to build with conservative options that we judge will work on the greatest number of machines. With the next release we'll probably look at enabling SMP; we know that this will restrict rtai to working only on systems with APIC, but in 2010 it's probably only a small minority of machines that don't have APIC. If testing proves us wrong, we'll take it out and remain restricted to using a single CPU or core. In another few years, maybe we'll be in a position to make a similar decision about 64 bits as the standard that will work on all but a few uninteresting machines. Jeff -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] How EMC face with the chanllege of hard platform development? (muti-core, 64 bit processor etc)
hi all, Ijust have a question,since emc is on base of orgin 32 system.But now with improvement of technology,can emc fully take advantage of them? RCS is a good idea for hierarchy control,and I just see some implementation of communication between processes (one computer),or different computers with UDP protocol. BUT how about muti-core or 64bit processor? Is it a problem? best regards shining 3.5 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
