On 06/12/2012, at 12:15 PM, srean wrote:
>
> Thanks ! this is quite interesting and slightly coincidental. I really have
> to teach myself the terminology and notation to understand these things.
>
> Have played some with GNU's parallelized STL algorithms that specialize the
> (parallel) algorithm on the basis of iterator_categories. The old C++
> standard munges the two separate concerns (i) navigation and (ii)
> readability/writeability into a single hierarchy. I dont know if this has
> changed.
I think so. Unfortunately iterators are plagued with the
failure of const to propagate correctly (that is .. it doesn't :)
>
> I said slightly coincidental because the last couple of days have been
> implementing laziness into iterators, i.e. defining a new iterator as a
> composition of dereferenced iterators by some binary function.
hang on. Let me think. You mean something like:
it p = plus (it a, it b)
*p --> *a + *b
++p --> ++a, ++b
Using generators in Felix:
gen binop (f: int * int -> int ) (a: 1 -> int, b: 1 -> int) () => f (
a(), b() );
one liner :)
Using channels, something like:
proc binop (f: int * int -> int ) (a: ischannel[int], b:ischannel[int]
) (c:oschannel[int]) =>
while true do
write (c, f( read a, read b));
done
> That was so painful, more so because I wanted to avoid virtual functions !
> and I Still dont know if I have covered all the cases that I care about.
> Sadly no exhaustiveness checks on types.
>
> Will see how well the parallel part works. GNU uses OMP for parallelization,
> with a begin and an end OMP section in each of these STL algorithms. Those
> sections are expensive to step into, and that hurts, because for me these are
> a part of an iteration, and the parallel sections cannot be fused across
> function boundary. But still better than writing my own parallel code from
> ground up.
I would like to put parallel stuff, including OMP, into Felix.
My problem is I only have a dual core CPU, which is not enough
to test if it is working.
The costs with only two cores can easily outweigh the advantages,
particularly if you need locking. I think you really need 4 cores to test,
and 8 is a lot better (the speedup should be observable).
CUDA on the other hand would also be much fun, especially
the Kepler GPU .. since that has 3072 cores, and is designed
to run oversaturated at around 10K threads for optimal performance.
This should reduce things like matrix multiplication to O(1) real time
up to some pretty big matrix sizes.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
