[Factor-talk] Factor on multicores
Hi everyone, I discovered Factor somewhat by accident and an attach of Forth nostalgia made me have a closer look. No regrets: this is really an impressive language with an impressive library and an impressive development environment (FUEL for Emacs). What I couldn't figure out is how Factor programmers deal with today's multicore processors. Threads are apparently cooperative, so that's not the answer. That leaves communicating processes as an option, but is there some support library? I also wonder if there are any real-life applications that one could learn from. I know the Factor compiler is written in Factor, but I am not a compiler expert so that is not the best example for me to look at. Are there any other Factor applications floating around? Konrad. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Factor on multicores
> > > What I couldn't figure out is how Factor programmers deal with > today's multicore processors. For GPUs, have a look at the cuda bindings: http://docs.factorcode.org/content/vocab-cuda.html IMHO, best way to deal with multi-cores is with multiple processes instead of threads. Can always use memory mapped files if redundant memory usage is a concern. Simplifies scaling across machines later. There are a bunch of toy apps in the factor distribution. I haven't used it for any big projects yet, but I think it would be cool to create squeak / scratch IDE with factor. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Factor on multicores
On May 29, 2012, at 12:42 PM, Konrad Hinsen wrote: > What I couldn't figure out is how Factor programmers deal with > today's multicore processors. Threads are apparently cooperative, > so that's not the answer. That leaves communicating processes > as an option, but is there some support library? Factor doesn't really handle multicore. There is some half finished code to support a one-VM-per-thread model, each with its own heap, but the benefits over simply using processes would be minimal. You may be able to leverage the IPC features of io.launcher with a serialization mechanism of some sort to build programs that share data across processes. > > I also wonder if there are any real-life applications that one could > learn from. I know the Factor compiler is written in Factor, but I am > not a compiler expert so that is not the best example for me to look > at. Are there any other Factor applications floating around? Factor's continuous integration system and the web server that runs all of the web applications on concatenative.org and factorcode.org are also written in Factor. -Joe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Factor on multicores
Joe Groff writes: > Factor doesn't really handle multicore. There is some half finished > code to support a one-VM-per-thread model, each with its own heap, but > the benefits over simply using processes would be minimal. You may be Indeed. The applications I have in mind would require shared read-only access by several threads to shared data. I don't know the design details of the Factor VM, but I suppose this would require a shared heap. > able to leverage the IPC features of io.launcher with a serialization > mechanism of some sort to build programs that share data across > processes. I suspect the serialization and communication overhead would be too important. Naveen Garg writes: > For GPUs, have a look at the cuda > bindings: http://docs.factorcode.org/content/ vocab-cuda.html I will! > IMHO, best way to deal with multi-cores is with multiple processes > instead of threads. Can always use memory mapped files if > redundant memory usage is a concern. Simplifies scaling across > machines later. Is there support for memory-mapped files? I'd have to be able to create data structures in such memory areas. Is there a technical reason for not having better thread support, or is it just something that nobody got around to do yet? At first sight, the language seems well adapted to parallelism: give each thread its own data stack, and use immutable data structures at the interfaces. If the VM could enforce the "immutable data structures at the interfaces" rule, it wouldn't have to worry about data access synchronization at all. Konrad. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
