Re: idiomatic filter-not or inverting predicate
Hi, Thanks a lot for hints. remove was what I needed. This (filter (complement #(apply = %)) '([1 2] [1 1])) also looks very clean now. Regards, Andy On Thu, Aug 21, 2014 at 1:07 PM, Daniel Solano Gómez cloj...@sattvik.com wrote: On Thu Aug 21 13:01 2014, Andy C wrote: Hi, I was wondering what is the nicest way to do filter-not in Clojure. Here are 3 expressions: user= (filter #(apply = %) '([1 2] [1 1])) ([1 1]) user= (filter #(apply not= %) '([1 2] [1 1])) ([1 2]) user= (filter #(not (apply = %)) '([1 2] [1 1])) ([1 2]) First one is just a base filtering. Second is taking advantage of having inverted predicate. Now let's assume that we have only a positive predicate, hence we would have to invert it by hand. That leads me to 3rd expression above. I was wondering though is it is possible to somehow get not closer to =, so the fact that we invert it is more obvious ... Is it possible to do that? Or perhaps there is an easier way to code it up all together ? What about 'remove' instead of 'filter'? Sincerely, Daniel Thx, Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
idiomatic filter-not or inverting predicate
Hi, I was wondering what is the nicest way to do filter-not in Clojure. Here are 3 expressions: user= (filter #(apply = %) '([1 2] [1 1])) ([1 1]) user= (filter #(apply not= %) '([1 2] [1 1])) ([1 2]) user= (filter #(not (apply = %)) '([1 2] [1 1])) ([1 2]) First one is just a base filtering. Second is taking advantage of having inverted predicate. Now let's assume that we have only a positive predicate, hence we would have to invert it by hand. That leads me to 3rd expression above. I was wondering though is it is possible to somehow get not closer to =, so the fact that we invert it is more obvious ... Is it possible to do that? Or perhaps there is an easier way to code it up all together ? Thx, Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: STM and persistent data structures performance on mutli-core archs
This is a slightly different result as this time I measure elapsed time
(see appendix and excuse not so nice code) as opposed to a clock time.
Results are similar (unless you have more processes than cores). I am
planning to release the code to github soon.
+--++---+
| # of | seq | rdm |
|processes || |
+--++---+
|1 | 1.00 | 1.00 |
+--++---+
|2 | 1.96 | 1.75 |
+--++---+
|4 | 3.20 | 1.83 |
+--++---+
|8 | 3.78 | 1.83 |
+--++---+
|16| 3.61 | 1.81 |
+--++---+
|32| 3.56 | 1.81 |
+--++---+
This is great stuff.
Let me make sure I read it correctly.
Having 2 processes makes a value 1.97 times higher than with 1 core in the
random case, and 1.76 times higher in the linear case, but what is that
value being measured?
Some form of throughput I suppose and not time, right?
I think you could call that a normalized throughput. Here are more details.
First column is the number of separate O/S test processes running in
background concurrently, started by the shell script virtually at the same
time. Then I collected the output which simply logs how long it takes to
iterate thru 40MB of memory in sequential or random manner. Second and
third column are
number_of_processes/elapsed_time*elapsed_time_from_first_row_process for
sequential and random access respectively. In ideal conditions,
elapsed_time should be constant as we use more and more cores/CPUs.
Indeed. It also means single threaded linear access isn't going to be very
much faster if you add more threads.
BTW, are you sure the threads were running in parallel on separate cores
and not just concurrently on a smaller number of cores?
As you said, this should be dependent on hardware and running this on
actual server machine would be as interesting.
I wanted to see the worse case, separate processes and memory , which was
simplest to implement. Yes, I am sure that cores were utilized by OS as the
number of processed added. I watched MBP Activity Monitor and CPU History
which was hitting 100%. Also I did not optimize the output (should not
matter).
One interesting thing, I heard somewhere, that O/Ss bounce long lasting CPU
intensive threads between cores in order to equalize the heat generated
from the silicon. I did not observe that but longest running test took
about 15 sec using a single core.
Thx,
Andy
Appendix 1:
{
int n;
int j;
struct timeval begin,end;
gettimeofday (begin, NULL);
for(n=0;n100;n++)
for (j=0;jlen;j++)
i_array[rand()%len]=j;
gettimeofday (end, NULL);
printf([:rdm %s %d %d %f]\n,des,len,m,tdiff(begin,end));
}
{
int n;
int j;
struct timeval begin,end;
gettimeofday (begin, NULL);
for(n=0;n100;n++)
for (j=0;jlen;j++)
i_array[j]=j;
gettimeofday (end, NULL);
printf([:seq %s %d %d %f]\n,des,len,m,tdiff(begin,end));
}
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: STM and persistent data structures performance on mutli-core archs
Memory access patterns make a huge a difference to memory throughput. I've explored this in some detail in the following blog. http://mechanical-sympathy.blogspot.co.uk/2012/08/memory-access-patterns-are-important.html Thanks for sharing. From the Clojure perspective and using reducers, it seems we are hitting the worse case. Not sure if it worth effort of using it (at least in my applications). Thx, Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: STM and persistent data structures performance on mutli-core archs
Hi, So this is a follow-up. I claimed that 1 CPU core can saturate the memory but it turns out I was wrong, at least to some extend. Driven by curiosity I decided to do some measurements and test my somewhat older MBP 2.2GHz Inter Core i7. While it obviously all depends on the hardware, I thought it could be still a good test. In order to rule out the GC and JVM out of equation I went back to old good C and wrote a simple program which accesses a 40MB chunk of memory in both linear and random manner. All tests run a few times to ensure proper warm up and allocations within OS, however saw a great deal of consistency. It is not scientific by any means, but gives a rough idea what we are dealing with. Here are results where numbers are normalized gains. ++---++ | # of processes | random | linear| ++---++ |1 | 1.00| 1.00 | ++---++ |2 | 1.97| 1.76 | ++---++ |4 | 3.51| 1.83 | ++---++ |8 | 4.24| 1.86 | ++---++ The conclusion is that in practice two cores can easily saturate memory buses. Accessing it in certain patters helps to some extend. Although 8 cores is pretty much all what makes sense unless you do tons of in cache stuff. Best, Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: STM and persistent data structures performance on mutli-core archs
So, the following test puzzles me. Not because it takes virtually the same time (I know that Fork/Join is not cheap and memory is probably the biggest bottleneck here). But because I do not get why map (as opposed to r/ma) uses all 8 cores on my MacBookPro. All of them seem to be running according to Activity Monitor at more less the same level. user= (def l (into [] (range 6000))) #'user/l user= (time (def a (doall (map #(Math/sin (* % %)) l Elapsed time: 19986.18 msecs user= (time (def a (doall (into [] (r/map #( Math/sin (* % %)) l) Elapsed time: 18980.583 msecs -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: STM and persistent data structures performance on mutli-core archs
On Wed, Mar 19, 2014 at 11:14 AM, Raoul Duke rao...@gmail.com wrote: I like FSMs, but they do not compose well. some have argued for generative grammars that generate the fsm, because it is generally easier to compose grammars, and then generate the final fsm. iiuc. I thought about it too but composing FSMs out of some patterns really transcends my mind unfortunately. In another words, I have hard time to see patterns in FSMs - they tend to be quite complex in the first place. Sometimes a single transition might ruin the perception and completely the properties of everything. There is a very good book treating about subject: http://www.amazon.com/Practical-Statecharts-Quantum-Programming-Embedded-ebook/dp/B0017UASZO/ref=sr_1_3?s=booksie=UTF8qid=1395284883sr=1-3keywords=C%2B%2B+state+machine A. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: is it good?
Thx for hints. As for the main function, my tendency would be to avoid taking cases on the number of args Is that due to performance implications, I mean that it takes longer to check cases every time? Or just a style. BTW, I followed https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L1084 (def mimasuco (juxt #(apply min %) #(apply max %) #(apply + %) count)) It indeed seems that juxt scans source multiple times, which is something I wanted to avoid. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: STM and persistent data structures performance on mutli-core archs
As a co-author of the reactive manifesto I'd like to point out that reactive can be considered a superset of async. Good reactive applications are event driven and non-blocking. They are also responsive, resilient, and scalable which async can help with but does not prescribe. What are the bad connotations? I'm curious to understand other perspectives on this. I would say the opposite. Asynchronous or not happening, moving, or existing at the same timehttp://www.learnersdictionary.com/definition/synchronous does not necessarily imply non-blocking. It simply emphasizes that things might coexist without an explicit dependency (in a time dimension) on each other. At the same time (pun not intended) reactivehttp://www.learnersdictionary.com/definition/reactivelimits itself to responding to events which implies a control by some sort of FSM. Perhaps concurrency could be modeled using FSMs, but I do not believe it is always a simple transition. Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: STM and persistent data structures performance on mutli-core archs
I've never heard of imperative model. I'm aware of imperative programming. Can you expand on what you mean? I meant mutable data model. Sorry for mixing up terms. http://blog.codinghorror.com/separating-programming-sheep-from-non-programming-goats/ Hope this helps clarify. It does. I absolutely agree and get the point that persistent data structure + multiple cores/threads approach does solve much here, in fact probably makes things worse. And indeed it is better to queue Updates from multiple threads and get it handled by the mutator thread. But at the same time I hate to have my imagination be limited by the hardware designs. That really hurts :-). Best regards, Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: STM and persistent data structures performance on mutli-core archs
On Tue, Mar 18, 2014 at 11:06 AM, Raoul Duke rao...@gmail.com wrote: some sort of FSM. Perhaps concurrency could be modeled using FSMs, but I do not believe it is always a simple transition. http://www.cis.upenn.edu/~stevez/papers/LZ06b.pdf I like FSMs, but they do not compose well. A. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: STM and persistent data structures performance on mutli-core archs
From what I understand, a single core can easily saturate a memory bus. At the same time L2 and L3 caches are so small as compared to GB of memory systems yet growing them does not necessarily help either due to larger latencies. It all limits the number of practical applications which could really take a full advantage of multi core architectures. Having said that I just wonder if a typical async Clojure application can even be efficiently performed on a multi-core architecture. In any case, immutability helps writing reliable multi execution context software there is no need for explicit synchronization in most of cases. BTW, I absolutely love the async name itself chosen by Clojure authors as opposed to reactive as in http://www.reactivemanifesto.org. Reactive comes with bad connotations and really does not reflect the intentions well. Best, Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: STM and persistent data structures performance on mutli-core archs
Today, data is scattered everywhere in a huge memory, its location changes frequently, code can be dynamically compiled, get loaded by small chunks, It describes my case actually - I am loading about 2-8GB of stuff in the memory and to tons of mapping, grouping by and filtering. That works reasonably well now but will not scale up soon. A. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: STM and persistent data structures performance on mutli-core archs
In my personal experience I cannot get within 10X the throughput, or latency, of mutable data models when using persistent data models. Hi Martin, Thanks for finding this thread :-). Let me ask a reversed question. Given you come from a persistent data model where code remains reasonably simple. How much effort it really takes to make an imperative model working well with relatively low number of defects? How deep you go to make sure that data structures fit CPU architecture in terms of topology as well as of size of caches? And how it scales in terms of writing the code itself (I mean are code alternations are easy straightforward or you have to write it from scratch)? I do not mean to troll, just sincere curiosity ... Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
is it good?
Hi, trying to convert some Scala code I have into Clojure and would like as for a feedback. Following code is suppose to scan a sequence and combine min, max, sum and count: user= (defn combine [x y] (let [[mi ma su co] x] [(min mi y) (max ma y) (+ su y) (+ 1 co)])) #'user/combine user= (defn mimasuco ([x] [x x x 1]) ([x y] (reduce combine (mimasuco x) y))) #'user/mimasuco user= (mimasuco 1 2 3 4) [1 4 10 4] user= (mimasuco 100) [100 100 100 1] I try to stick to classic scheme like coding but wonder if there is more Clojure idiomatic way of doing this. Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: STM and persistent data structures performance on mutli-core archs
Maybe one day this idea http://en.wikipedia.org/wiki/Lisp_machine will come back, I mean in a new form .. In any case, I think that it would be great to see some performance benchmarks for STM A. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
STM and persistent data structures performance on mutli-core archs
Hi, So the other day I came across this presentation:http://www.infoq.com/presentations/top-10-performance-myths The guy seems to be smart and know what he talks about however when at 0:22:35 he touches on performance (or lack of thereof) of persistent data structures on multi-core machines I feel puzzled. He seems to have a point but really does not back it with any details. There is also a claim that STM does not cooperate well with GC. Is it true? Thanks, Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: STM and persistent data structures performance on mutli-core archs
On Thu, Mar 13, 2014 at 11:24 AM, Timothy Baldridge tbaldri...@gmail.comwrote: I talked to Martin after a CodeMesh, and had a wonderful discussion with him about performance from his side of the issue. From his side I mean super high performance. [...] Hi Tim, Thanks for explaining the context of Martin's work - I did not know that it was so advanced. I did some research back in good times on http://en.wikipedia.org/wiki/Connection_Machine (via telnet 56kb/s telnet connection from east Europe to US - that was super cool back then) and can only atest to what he says in the presentation. You can achieve amazing levels of performance provided that patterns of data flow and control in software match exactly parallel nature of given architecture. However his point is somewhat more serious. He directly attacks a premise that using immutable data is inherently mutli-core friendly which comes from the deduction that writing reactive software reduces the use locks and guards hence enables more flow and less waiting. Now his point is that GC acts a super GIL which effectively kills all the hard work done on the language and application design level. Now, I wish Marin eats his own dog food and as pointed out numerous times in the presentations, he backs up his points with a real experiments and data. At least it was not apparent wether his conclusions were purely theoretical or grounded in some experience. I am in the process of transitioning from Scala to Clojure ecosystem (just finished SICP videos and have some hard 4clojure problems behind me, but a lot of to learn) so not yet fluent in all aspects of the language but I think at some point I will try to write some simulations of STM performace following some of Martin's intuitions. I think that it will be very cool. Best, Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: why Clojure/Lisp is so fast
On Tue, Feb 18, 2014 at 11:38 PM, Devin Walters dev...@gmail.com wrote: You need to use the lein plugin for no.disassemble, not the dependency. The README explains how. Thanks - now I can see disassembled code - quit neat. I misread do not use this way as a following as opposed to above (being not a native speaker does not help). I actually tried it as a plugin but something else came into play so it did not work :$ Best, Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: why Clojure/Lisp is so fast
The OP almost certainly intended CLISP to mean Common Lisp. I recall it now - it was Allegro CL which somebody demoed to me almost ten years ago. I wish I started learning Lisp yet cannot believe that Clojure I am learning now (and Scala I am actively using) did not exist back then. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
why Clojure/Lisp is so fast
Hi, There are many performance benchmarks showing that compiled CLISP is almost as fast as C++ or Clojure as Java. Being a dynamically typed language though, I wonder how it is possible. Is it because the compiler is able to sort out actually used types and assemble appropriate byte code or the cost of calling virtual methods is negligible. I probably should check out generated JVM byte code to see the answer firsthand but still would appreciate a higher level answer. Thanks in advance, Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: why Clojure/Lisp is so fast
Thanks for the insight and link to http://benchmarksgame.alioth.debian.org. WRT dynamically typed languages, I have some 5 years experience with Python circa 2.4ish timeframe. I remember that a practical raw speed was not that bad, but still was in average like 10 times slower from C++. Good enough though. We used it along with Twisted to run some performance tests of certain closed source messaging system. I was okay until we started playing with threads/GIL. For obvious reasons it was very taxing and is not even remotely comparable with modern reactive kind of architectures and STM. I remember someone presented me how common lisp can disassemble compiled code in fly - very impressive it was. Not only the possibility but the quality of a generated machine code as well. Following that experience I ended up trying https://github.com/gtrak/no.disassemble with no beginners luck :-( with first steps with lein ... Any idea what went wrong? $ cat project.clj (defproject my-project myREPL :dependencies [[nodisassemble 0.1.2]]) $ lein repl nREPL server started on port 62154 on host 127.0.0.1 REPL-y 0.3.0 Clojure 1.4.0 Docs: (doc function-name-here) (find-doc part-of-name-here) Source: (source function-name-here) Javadoc: (javadoc java-object-or-class-here) Exit: Control+D or (exit) or (quit) Results: Stored in vars *1, *2, *3, an exception in *e user= (require 'no.disassemble) nil user= (in-ns 'no.disassemble) #Namespace no.disassemble no.disassemble= (println (disassemble (fn []))) java.lang.NullPointerException at org.eclipse.jdt.internal.core.util.ClassFileStruct.u4At(ClassFileStruct.java:61) at org.eclipse.jdt.internal.core.util.ClassFileReader.init(ClassFileReader.java:76) Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: map semantics
On Sun, Feb 9, 2014 at 4:46 AM, Michał Marczyk michal.marc...@gmail.comwrote: The Contrib library algo.generic provides a function fmap which does preserve the type of its input. Thanks for the pointer. So, these are some of the available conceptual arguments. There is also a rather convincing practical argument in the form of the existing body of Clojure code, written using the existing Clojure core library and its conventions and achieving, in many cases, amazing levels of clarity and concision Clojure is indeed very coherent with a few exceptions called design trade-offs :-). Deriving from Lisp wisdom and expanding those powerful concepts into a modern programming is priceless. It is all good now. Pozdr, Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: map semantics
On Sat, Feb 8, 2014 at 12:06 AM, Sean Corfield s...@corfield.org wrote: But you're misunderstanding what map does: it converts its collection arguments to _sequences_ and then it processes those sequences. Map doesn't operate on sets, or vectors, or maps, only on sequences. Your assertion that I am misunderstanding something is wrong. One cannot convert amorphic set into linear sequence without assuming certain order. And as with every assumption, it always comes with some less or more pragmatic but arbitrary decision which might change over time and ruin peoples programs. I would expect Clojure to throw IllegalArgumentException Don't know how to create ISeq from: clojure.lang.PersistentHashSet or document it well in map somewhere. Perfection is the enemy of the good. Now judging by your sig, it all does not surprise me LOL -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: map semantics
Every persistent collection in Clojure supports conversion to the sequence of items. This is clearly documented in the official docs and there is no surprise here. Would you mind to point me to that piece where doc describes what order seq chooses when converting a set to it. (I honestly tried to find it but could not.) The order or items in the resulting sequence is dependent on the collection type. As the conversion to the sequence is a referentially transparent function, you will always get the same order for the same collection. So for particularly huge sets, I understand Clojure will not attempt to sort them (read be inefficient) before producing the sequence, is it correct? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: map semantics
First, thanks everybody for explanations of design decision behind map and collections. I should in fact change subject to seq semantics ;-). For me the bottom line is that while I do not care about order so much I still can count on that seq function will produce consistent sequences. Or wait a sec: This might be too detailed a point, but I wanted to mention that while you will always get the same order for the same collection (same as determined by identical?, or Java ==, i.e. it is the same object in memory), you are *not* guaranteed to get the same order for collections of the same type that are equal to each other as determined by Clojure = or Java .equals. In particular, if two values have the same hash value, then if they are used as a set in a Clojure PersistentHashSet or a key in a PersistentHashKey, they are put into a linear list in a hash bucket for that hash value, and their order in that list can be different in different sets/maps, and the order that (seq ...) returns on those sets/maps will be different. I am not certain, but this might violate referential transparency (replacing a value that is equals for another value in an expression will always give you an equal result). This is not too detailed. In fact this is the ultimate question. It would mean that two logically identical sets can produce different LazySeq's depending how they came to existence ... -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: map semantics
On Sat, Feb 8, 2014 at 1:46 PM, Jozef Wagner jozef.wag...@gmail.com wrote: Two collections equivalent by their values may easily have a different order of their items. It all boils down this: is it possible to have two clojure.lang.PersistentHashSet with identical values (in mathematical sense) but producing different seqs? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: map semantics
user (= s1 s2) true user (= (seq s1) (seq s2)) false Thx. If a=b then f(a) must = f(b). Something is broken here. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: map semantics
I can ensure all of you that it is very uncomfortable for a newcomer with a goofy nick to just come in and say things are broke LOL . So at that point I have two choices: 1) as suggested, find another programming language but that would mean that I would have to erase my Clojure tattoo (very painful). 2) stop making enemies and pretend that seq on sets is cools and neat and we really do not need to stick to fundeaments of FP: a=b = f(a) = f(b) in critical part of the language. It ain't going to happen either. Although, the worst part about it all is that my carefully crafted piece of software used for controlling nuclear power plants relies on Clojure set-s. As we above some part of it is non deterministic as the calculated controls paramters depends on the order of adding elements to set That literally sucks! In any case, see you at Clojure West conference and thanks again for all the replies, Best regards, Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
map semantics
Hi,
I have a short question, why map builds up a LazySeq instead of an input
collection as found below:
user= (type (map #(mod % 3) #{3 6}))
clojure.lang.LazySeq
user= (type (map #(mod % 3) '(3 6)))
clojure.lang.LazySeq
user= (type (map #(mod % 3) [3 6]))
clojure.lang.LazySeq
user= (type (map #(mod (% 1) 3) {:a 3, :b 6}))
clojure.lang.LazySeq
One would expect to (map #(mod % 3) #{3 6}) evaluate into #{0}. Is it
arbitrary decision or there is a theory behind it?
Best,
Andy
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: map semantics
user= (map #(mod % 3) #{3 6})
(0 0)
user= (set (map #(mod % 3) #{3 6}))
#{0}
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: map semantics
I do perceive sets, lists, vector as atoms which are indivisible (well, this is not true but this is popular meaning) from semantics standpoint. Therefore map is just a function which processes them as whole, again from semantics point of view. Implementation and laziness should not matter really and we still should get the same result. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: map semantics
I actually like the laziness by default but as you suggest, wish there is a way to switch it on/off for blocks of the code (rather than compiler option). Scala guys did some research and in most practical cases Lists are very short hence they are not lazy and evaluated at once. Just an interesting tidbit, not an argument. But what really bothers me is that laziness / not laziness affects the result of evaluation as in above example. That is against some fundamental rules of FP (gotta check how Haskell does it :-P). Again, question is what map really is, and why it gotta be invertible. Let's say that we have a new collection type, a tree. And mapping every node in the tree to a new value rearranges entire construct. Having map to produce a lazy seq implies that the input must be serializable (or linear). -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Clojure development laptop battery usage
On Wed, Jan 22, 2014 at 5:29 PM, John Chijioke johnben...@gmail.com wrote: Not true. More RAM, more power. Why? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
