I would say that guidelines can help but curiosity is mandatory. I used to sleep with books on my bedside table about hardware design, operating system internals, io subsystems, networking, ...
I did this for 15 years after I started to work with computers. Aside from work related stuff of course, this was to increase my general knowledge and to be more relaxed on the job :) Knowing your enemy is essential... Luc P. > On 16/03/14 18:24, Softaddicts wrote: > > I think that significant optimizations have to be decided at a higher level. > > I doubt that any of that can be implemented at the hardware level alone > > and let it decide on the fly. This sounds like magic, too good to be true. > > > > I am also quite convinced that optimizing in hardware single threaded > > and muti-threaded processing are antagonist goals given the current > > hardware designs. > > > > Martin hits a number of significant nails, we need to be > > aware of hardware limitations and we need to measure the impacts of > > our choices and change these within some reachable goals. > > > > However achieving 10% or less cpu idle time on a specific server > > architecture > > to me is not a goal. > > > > I'm interested by the constraints I have to met (business and physical ones) > > and playing within a large playground to meet these wether it involves > > using more powerful/specially designed hardware or using better > > software designs. > I hear you well. Whether further progress comes from hardware and/or > software doesn't matter, I just hope progress is being made somewhere > and that we won't have to fiddle with hundreds of parameters as it's the > case for the JVM right now. Until then, tedious experimentation will be > the only way to ensure scaling does happen. > Sure Martin's case at LMAX was extreme, not many people will have such > concerns. But we're in an age where the need for scalability can be very > sudden (e.g. popular phone app.). With servers nowadays that can have > many CPUs and cores, and many Gb of RAM, one can easily hope that > vertical scaling can be sufficient, but it's often not as simple as > that. Vertical can even be more dangerous than horizontal, since in the > horizontal case you probably architect for scaling right from start. So > what works and doesn't work is valuable information, and initiatives > such as the Reactive Manifesto <http://www.reactivemanifesto.org/> are > helpful because they provide guidelines. > > -- > 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.
