Call for Submissions - First Workshop on Languages and Tools for Parallel and Distributed Programming (LTPD 2007)
First Workshop on Languages and Tools for Parallel and Distributed Programming (LTPD 2007) http://computacao.ucpel.tche.br/ltpd/ Gramado, RS - Brazil Co-located with SBAC-PAD 2007 (24-27 October 2007) *** Submissão de artigos: 24 de Agosto *** The objective of this workshop is to bring together researchers working on the design and implementation of programming languages, tools and techniques for distributed, parallel and mobile programming. Submitted papers should present original research that is unpublished and not submitted elsewhere. We encourage the submission of work in progress, especially by MSc and PhD students. We plan to provide a friendly environment where researchers can discuss current and future trends in programming languages for parallel and distributed programming. Papers can be written in English, Portuguese and Spanish. Papers should have 4 pages, following the IEEE Computer Society Proceedings Manuscript Formatting Guidelines. All accepted papers will be published in the On-Line conference proceedings, and as a technical report. The SBAC-PAD organization will also publish the electronic proceedings in CD. We plan to publish selected high quality papers from the proceedings in a local brazilian journal. At least one author of an accepted paper must attend the workshop and all workshop attendees must be registered to SBAC-PAD. Topics of Interest -- -- Topics of interest include, but are not limited to: * Programming Multi-Core Machines * Coordination Languages * Concurrent and Parallel Garbage Collection * Type systems and semantics for parallel, distributed and mobile languages * Declarative parallel, distributed and mobile languages * Languages for mobile and ubiquitous computing * Calculi for Mobility and Concurrency * Design Patterns * Distributed Objects * Distributed Component Models * Mobile Agents Languages * Software issues for multicore or multithreaded processors Important Dates - - * Deadline for paper submission: August 24, 2007 * Accepted Papers Notification: September 10, 2007 * Camera-Ready Submission: September 17, 2007 Organizing Committee -- - André Rauber Du Bois (Chair) - UCPel Francisco Heron de Carvalho Junior (Chair)- UFC Program Committe --- Adenauer Correa Yammin - UCPel Alcides Calsavara - PUCPR Álvaro Freitas Moreira - UFRGS André Rauber Du Bois - UCPel André Santos - UFPE Claudio Fernando Resin Geyer - UFRGS Cristiano Vasconcellos - UFPel Francisco Heron De Carvalho Jr - UFC Hans-Wolfgang Loidl - LMU, Germany Iara Augustin - UFSM Jorge Luis Victoria Barbosa - Unisinos Marco Túlio de Oliveira Valente - PUC-MG Phil Trinder - Heriot-Watt University, UK Rafael Dueire Lins - UFPE Ricardo Corrêa - UFC ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
About unsafeThaw and unsafeFreeze efficiency ....
Hello, in GHC documentation, it is said : "unsafeThaw :: (Ix i, IArray a e, MArray b e m) => a i e - > m (b i e) Converts an immutable array into a mutable array without taking a copy. This function is "unsafe" because any subsequent modifications made to the mutable version of the array will be shared with the immutable version. It is safe to use, therefore, if the immutable version is never referenced again. " I am trying to use unsafeThaw in a parallel program written in a parallel language that I am developing. A process have to transmit a UArray Int Double to another process. I used unsafeThaw to translate the UArray into a StorableArray. Thus, using the function withStorableArray, it is possible to access the array elements (double's) in a contiguos buffer that could be sent directly through MPI. The receiving process fetch the message (MPI_Recv) in a buffer and copy their elements (including array bounds information) in a StorableArray (using withStorableArray and copyArray). Then, using unsafeFreeze applied to the StorableArray, the original UArray Int Double sent by the sender is obtained. But this is efficient only if the conversion from UArray to StorableArray, using unsafe versions of thaw and freeze, does not take a copy, as GHC documentation suggests to the reader. However, my experiments (profiling, measurements, etc.) have detected a source of ineficiency in the application of unsafeThaw and unsafreFreeze. It appears to be more efficient to translate the array to a list (using elems) and then copy the list in a "Ptr" array using pokeArray. unsafeThaw is really "free of copy" ?? Any exception ?? I need a way to access an unboxed immutable array in a contiguos buffer in constant time, in order to minimize marshalling overheads for preparing a message to be sent through a network, using MPI. This is important for parallel scientific code, that makes extensive use of arrays and have to transmitt them between processes. Any suggestion ? Heron __ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - É grátis! http://antipopup.uol.com.br/ ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UArray question....
Hi, thanks for your answer. In the distributed parallel extension that we are developing, programmers are free to use immutable or mutable arrays and to transmit them between processes (the language have mechanisms to make transparent send/recv operations). Thus, it is important to give efficient marshalling for any array type. With StorableArrays, GHC offers good support, but for immutable arrays types, we have to copy element by element (worse performance). But someone can explain how unboxed arrays are stored in memory ? Heron > AFAIK, no. That's the whole point of StorableArrays. Why can't you use > these instead of UArrays? > > - Hal > > On Mon, 27 Oct 2003, heron_carvalho wrote: > > > Dear colleagues, > > > >In GHC/FFI, is there some way (is it possible ?) t o > > access DIRECTLY an array of UArray type (immutable) i n a > > sequential contiguous memory buffer (in C side, for > > example) without to need to copy the array elements o ne > > by one ? GHC hackers and implementors are wellcome... :-) > > My interest is to transmit the array over a network u sing > > MPI, but avoiding marshalling overheads. > > > > It is easy to do this with StorableArray's in the IO > > monad, of course, but I need to use UArray. > > > > > > Heron de Carvalho > > > > > > > > > > _ _ > > Acabe com aquelas janelinhas que pulam na sua tela. > > AntiPop-up UOL - É grátis! > > http://antipopup.uol.com.br/ > > > > > > ___ > > Glasgow-haskell-users mailing list > > [EMAIL PROTECTED] > > http://www.haskell.org/mailman/listinfo/glasgow- haskell-users > > > > -- > Hal Daume III | hdau [EMAIL PROTECTED] > "Arrest this man, he talks in maths." | www. isi.edu/~hdaume > > ___ > Glasgow-haskell-users mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/glasgow- haskell-users > __ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - É grátis! http://antipopup.uol.com.br/ ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
UArray question....
Dear colleagues, In GHC/FFI, is there some way (is it possible ?) to access DIRECTLY an array of UArray type (immutable) in a sequential contiguous memory buffer (in C side, for example) without to need to copy the array elements one by one ? GHC hackers and implementors are wellcome... :-) My interest is to transmit the array over a network using MPI, but avoiding marshalling overheads. It is easy to do this with StorableArray's in the IO monad, of course, but I need to use UArray. Heron de Carvalho __ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - É grátis! http://antipopup.uol.com.br/ ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
?? Redirecting standar error output ...
Hello, How can I redirect standard error output to a file in GHC 5.02 ?? Something like -odump flag in GHC 4.08 ... Best Regards, Heron de Carvalho __ Quer ter seu próprio endereço na Internet? Garanta já o seu e ainda ganhe cinco e-mails personalizados. DomíniosBOL - http://dominios.bol.com.br ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FORTRAN and HASKELL
Hello GHC users, We want to reuse FORTRAN libraries within Haskell code. How can we use FFI to implement this interface directly ? We know that we can use C to implement it indirectly with FFI, but how can we do this directly ? Any suggestion ? Thanks, Heron de Carvalho > --- clusterpoli <[EMAIL PROTECTED]> wrote: > > Somebody works with together FORTRAN and Haskell. Exists > > some funcao to transform codigo FORTRAN into codigo > > HASKELL? > > TXL might help, but it's its own functional language. > It can probably convert FORTRAN to Haskell given the > EBNF for each language, but I'm not sure how it works... > http://www.research.avayalabs.com/user/wadler/realworld/l s2000.html > http://gatekeeper.dec.com/pub/misc/txl/ > > Otherwise, I would look at what algorithm the FORTRAN is > implementing, the either write it in Haskell, or look for it > on the Internet using http://www.google.com/ > > For example: http://www.cs.chalmers.se/pub/haskell/library/ > http://www.cs.chalmers.se/pub/haskell/library/bevan/index > > __ > Do You Yahoo!? > Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. > http://geocities.yahoo.com/ps/info1 > > ___ > Glasgow-haskell-users mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/glasgow- haskell-users > __ AcessoBOL, só R$ 9,90! O menor preço do mercado! Assine já! http://www.bol.com.br/acessobol ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
