On 23/08/2014, at 12:58 PM, srean wrote: > The problem with most newcomers to Felix are they're not trusting > > To be fair, there is a reason for that. The code produced is quite a bit > opaque, so have to depend on you on almost every step. Thats a strong hurdle.
Sure, although that's not quite what I meant: I actually meant: "look, this thing may have bugs and issues but it is worthwhile if you put some effort into it". The product has amazing potential. > See even now it is not immediately clear to a new comer how to initialize a > named val with a type and a literal. That ought to be one of the first things > mentioned. Vals are deliberately obscure: use vars. They're easier to explain. > I have seen people go > > "Yay! huge matrix, huge vector, so parallel, much fast, so speed" > > to actually coding it up with threads etc and then get bitten by the reality > that it is slower than a dumb serial implementation, Of course this can happen. However Intel CPU's have a separate cache for each core. And separate FPUs. The real problem with concurrent operations is noted in the Atlas mailing list. Note "Tragedy of the Commons". You can make some operation use 4 threads on a 4 core machine. If you're the only process running, that's great. But if its a library, and someone (even you) uses it, and decides their problem should be split into 4 as well, each calling the library subroutine .. .. well you now have 16 threads. -- john skaller skal...@users.sourceforge.net http://felix-lang.org ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
