In the "old" days, the principle of locality was prevalent.
Most data allocation was static
or if not contiguous (the stack).
Code was also contiguous being
most of the time statically compiled
on several pages.

Memory was costly, its size remained
"reasonable".

Today, data is scattered
everywhere in a huge memory,
its location changes frequently,
code can be dynamically compiled, 
get loaded by small chunks, ....

Hardware wise they do what they
can to deal with this but I think
it's a lost battle.

We need a quantum jump at the
hardware level to get some
faster random access to memory.

This will probably shake the software
stack a lot. Which brings other issues...

Meanwhile we are stuck with
finding the least painful path to get
our stuff to run asap.

Luc P.

> 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.
> 
--
Luc Prefontaine<lprefonta...@softaddicts.ca> sent by ibisMail!

-- 
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.

Reply via email to