Cambridge gallery lends art to students 'with none damaged' in 60 years - <AUTHOR> https://www.bbc.com/news/uk-england-cambridgeshire-49897431 <comment><USER2> My college does this as well. It's been happening since 1940 [1], so 79 years, longer than Cambridge. More info in [2]. The collection even includes some works by Picasso.

It's very popular here — students camp out overnight to maintain their spot in line, and the art up for rental tends to run out quickly.

[1]: [https://www.oberlin.edu/news/art-rental-behind-scenes- look](https://www.oberlin.edu/news/art-rental-behind-scenes-look)

[2]: [https://www.oberlin.edu/news/visionary-behind-art- rental](https://www.oberlin.edu/news/visionary-behind-art-rental)

<comment><USER3> Ha! I came into the thread to mention Oberlin. I remember the madness around trying to get a piece.

</comment></comment><comment><USER4> MIT has something similar for its students - they lottery off an entire gallery of art to students to keep in their dorm rooms for the year every fall [0].

I have no idea what the damage statistics are for it, but this just reminded me of it.

[0] [https://listart.mit.edu/collections/student-lending-art- prog...](https://listart.mit.edu/collections/student-lending-art-program)

<comment><USER5> I was just going to mention this. Apparently they'll only loan prints to students. Faculty can get the better stuff: [https://listart.mit.edu/collections/campus-loan-art- program](https://listart.mit.edu/collections/campus-loan-art-program)

<comment><USER6> In this context, prints mean "original prints" which doesn't translate to junk or reproductions. Some original prints are worth in excess of half a million dollars.

<comment><USER5> That's true. I don't know enough to know what the prints they're lending out are worth.

</comment></comment></comment></comment><comment><USER7> Trust with accountability and respect seems to go a long way some times but not others. Anyone have a theory why this system worked so effectively but other systems involving trust don't?

<comment><USER8> Trust works well if you have decent people. Exactly what makes people decent is hard to say, but it is not unthinkable that students who got into Cambridge are a bit more decent than average.

<comment><USER9> Or, are at least more likely to go for the long con than the smash & grab.

</comment></comment></comment><comment><USER10> When it comes to long-term storage of art, damage can be calculated in more ways than whether a piece of art is noticeably defaced.

The biggest threat to these pieces lies in being stored outside of a climate, light, and humidity-controlled environment. When the lifespan of a thing is hundreds or thousands of years, this matters just as much.

However, if the museum doesn't normally keep its stored pieces in a controlled environment, then this should be no different.

But kudos to these organizations for trusting the students enough to do this.

<comment><USER11> Storage has other problems; A painting stored away in a climate controlled vault where no one can look at it is just a dusty canvas rectangle.

A painting requires a viewer for it to become art.

<comment><USER12> A copy of the painting can serve for viewing nearly as well as the original. But a copy can't answer some questions so preserving the original for future study (and new questions, ideas, and technology) is valuable.

<comment><USER13> The point is though that future study doesn't necessarily have a higher value than current study. Especially if the art is likely to degrade over time in some respects anyway.

</comment></comment></comment></comment><comment> dan-robertson I didn't know about this when I was a student but my college had a similar programme. I don't think the artists were so well known. As I recall, the bigger issue was that if you had picture rails then you needed to acquire picture hooks and if you didn't have picture rails then there wasn't really a good way to hang paintings

I don't think there were deposits but we maybe had to write down what we had borrowed.

</comment><comment><USER14> The libraries in Berlin have a similar thing going, for free and open to everybody.

[https://www.zlb.de/fachinformation/spezialbereiche/artothek....](https://www.zlb.de/fachinformation/spezialbereiche/artothek.html)

</comment><comment> jagged-chisel I have questions: 0) How widespread is this program announced, and which students take advantage of it? Maybe students of art are more cautious. Maybe business students don't know about the program. 1) Are they all framed and behind glass/plastic/whatever? If so, they're mostly protected from casual damage. 2) Are these originals or copies? 3) Is there a policy, communicated to the borrowers, that damage has punitive consequences? If so, that could be a deterrent.

<comment><USER15> It's not particularly popular/widely advertised. The handful of people I know who have done it are all art enthusiasts. Probably the mild inconvenience of getting the painting back to your room is a factor here. There's a £30 deposit per painting [https://www.cambridge-news.co.uk/news/cambridge- news/kettles...](https://www.cambridge-news.co.uk/news/cambridge-news/kettles- yard-art-loan-cambridge-13695555)

</comment></comment><comment><USER16> Would be really funny for an art student to paint many copies of the lent art, then return a half dozen copies with the original.

<comment><USER17> Copying works of art is a longstanding tradition when learning to draw/paint. This would likely get kudos from the art department, not laughs.

<comment><USER18> 100%. They would be impressed you were able to recreate a great work on your own, and it might end with an assistantship in a studio somewhere on campus.

</comment></comment></comment><comment><USER19> Interesting article it sounds like they're putting a lot of (warranted) trust in the students. They were a bit coy about it, but I'd be curious to see what the values of the paintings are.

This is slightly off-topic but it was interesting to learn that "homely" has a very different meaning in the UK. Similar to "homey" in the US

</comment><comment><USER20> Our library in does the same. The Graphotek only charges a small fee of €2.50 per painting. [http://www1.stuttgart.de/stadtbibliothek/bvs/actions/profile...](http://www1.stuttgart.de/stadtbibliothek/bvs/actions/profile/view.php?id=64)

</comment><comment><USER21> If you have to register with I.D., it's not purely based on trust.

<comment><USER22> Sure it is, it just moves the trust to trusting the verified person and away from simply trusting the system.

<comment><USER21> But that's not what a phrase like "purely based on trust" means; that means "purely based on trust in the person" (rather than trust in various "social collateral" that creates obligations in the person).

</comment></comment></comment><comment><USER23> Trinity College Dublin does the same thing. It's for free as well -- I think maybe just for students with rooms on campus but I'm not sure.

</comment><comment><USER24> I borrowed some of these. And returned them.

</comment><comment><USER25> UC Berkeley also has a similar program, FYI

</comment><comment><USER26> Speaking as a semi-famous artist. Art is a feast. After the feast you poop. Then the collectors come and hoard the poop for all eternity, occasionally lending the precious stuff out to students.

<comment><USER27> Say I printed this comment. Put it in a frame and auctioned it as art.

Would you be the artist for creating the comment? Or would I be the artist for using the comment and framing it in a creative way?

<comment><USER22> When Andy Warhol printed soup cans and put the prints in galleries, were the Campbell's logo designers the artists, or was Warhol?

<comment><USER28> I'm having art school flashbacks please stop hurting me.

</comment></comment></comment></comment><comment><USER29> I wonder if any came back improved</comment>


I think I broke Google - <AUTHOR> https://www.google.com/webhp?hl=en&tab=ww&authuser=0#hl=en&authuser=0&sclient=psy-ab&q=%22unable+to+setup+stack%22&oq=%22unable+to+setup+stack%22&gs_l=hp.3..0i8i30l4.7756.7756.2.79184.108.40.206.0.0.0.152.152.0j1.1.0...0.0...1c.1.7.psy-ab.zCe6YfHkDT8&pbx=1&bav=on.2,or.r_cp.r_qf.&bvm=bv.44158598,d.b2I&fp=5a614b0e7cec9842&biw=1061&bih=784

<comment><USER2> you're explicitly looking for something that I think would be more like "unable to setup protocol stack". I'm sure there are a lot of explicit phrases I could google and get no return hits.

</comment><comment><USER3> What is this?

<comment><USER4> unable to english</comment></comment>


Scientists have confirmed a brand new phase of matter: time crystals - <AUTHOR> http://www.sciencealert.com/scientists-have-just-announced-a-brand-new-form-of-matter-time-crystals#.WI9CxqtckGB.facebook <comment><USER2> Time Cubes.</comment>


User Interface Design Principles for Web Applications - <AUTHOR> http://aralbalkan.com/687

<comment><USER2> > 5\. Test Early, Test Often, Then Test Again

I'm not convinced that the kind of Usability Testing(TM) presented is actually the best way. There is still a physical barrier (a wall) and a communication barrier (the usability tester) between the developers and the users. Why is that a good idea?

Despite saying it's "not rocket science", the requirements listed are still a lot heavier than it need be. We aren't doing impartial science here. We are trying to understand users. Why not just _talk_ to them and interact together?</comment>


AI For Language? Programming Content And Intuition In Semantics - <AUTHOR> http://www.science20.com/news_articles/artificial_intelligence_language_programming_content_and_intuition_semantics-114399 <comment><USER2> "why not mine a vast body of texts (which are a reflection of human knowledge) and use the implicit connections between the words to create a weighted map of relationships"

Isn't this essentially a markov chain?</comment>


The Fallacy of Premature Optimization (2009) - <AUTHOR> https://ubiquity.acm.org/article.cfm?id=1513451 <comment><USER2> People seem to always talk in absolutes, black and whites, concerning this topic.

In my experience most engineers take a situational approach. Sometimes it is worth it to optimize early, sometimes it is not. Some things are worth optimizing, some not. Also some things are worth optimizing to certain level.

These types of articles and claims conjure up a debate because everyone is imagining a different scenario in their heads. It is entirely plausible that each claim could be the best solution in a different scenario.

Do these articles assume that engineers are incapable of thinking flexibly and need to follow some absolute truths that have to be debated? Have I been around too good engineers that I have not noticed this issue?

<comment><USER3> I read somewhere else yesterday that "it's easier to throw hardware at a problem than people." It certainly does not hold true for all cases, but turning this aphorism into a question seems to give us some good heuristics--- provided you do know the what the root cause of your performance issues could be, of course.

<comment><USER4> It's easy to throw hardware at a problem that can be parallelized efficiently. It's very hard to throw hardware at inherently sequential solution.

<comment><USER5> It _was_ easy to throw hardware at a sequential problem, a decade ago. CPUs were still improving their single-core performance year after year, and memory access and all kinds of IO devices kept getting faster and better. I'm guessing that time was where this idea originates from.

Today, things are different. Single-threaded performance isn't going to be improving much in foreseeable future; the effort shifted to improving parallel performance and, more recently, power consumption. So if you write slow code - perhaps by choosing a slow software stack - your code will _remain_ slow.

</comment></comment></comment></comment><comment><USER6> One thing I haven't seen in the comments yet is the simple observation that premature optimization is, by definition, a mistake -- otherwise it'd merely be "optimization". The real question is, what makes it "premature"?

I think Knuth (in his famous "... root of all evil" quote) was referring specifically to programming, and to spending time on optimizations prior to functional completion. The mantra, "First make it. Then make it work. Then make it better." [or similar] holds water. But it's pointless to debate in general terms what precisely constitutes a "premature" optimization, vs a merely timely one, or adherence to best practices, given the infinite combinations of circumstance and context relating to software development projects.

<comment><USER7> > "First make it. Then make it work. Then make it better."

That only works when you do simple things, for harder things the "make it better" part usually requires a complete rewrite if you didn't properly think things through from the beginning.

A better mantra would be "First make it, then make it again, then make the real version".

<comment><USER8> No. Engineering is an iterative process. Even if you're 're-writing' everything, you're still not starting again from scratch, rather you're building off your previous approaches.

</comment></comment></comment><comment><USER9> So recently John Carmack posted:

[https://twitter.com/ID_AA_Carmack/status/1210997702152069120](https://twitter.com/ID_AA_Carmack/status/1210997702152069120)

"My formative memory of Python was when the Quake Live team used it for the back end work, and we wound up having serious performance problems with a few million users. My bias is that a lot (not all!) of complex "scalable" systems can be done with a simple, single C++ server."

And so a lot of people seem to feel the need to once again bring back all the discussion in absolutes of optimisation being useless, or the only thing that matters.

I've found the same as John Carmack btw. Taking some component of a customer system, translating it to C++, can make a system that needed 10+ servers suddenly run a lot faster on a single server (meaning higher throughput AND lower latency, because in addition to the raw speed advantage of C++ there's so much you can do in C++ that's not really feasible in, say Python. For example, mmapping files).

But C++ is not exactly the first thing I reach for when something new springs to mind, or I want some data analysis done, or ... (even though C++ is excellent for running production data analysis jobs)

<comment><USER10> Python is probably the wrong tool for this though, that doesn't make it bad. Writing this in erlang, elixir or scala or even Golang would be a better choice. That's not premature optimisation, that's understanding what problems are requirements up front. Choosing most of these when you have zero users is probably wrong; python might be better as with its libraries it could get you to market faster!

</comment></comment><comment><USER11> Premature Optimization can hold back the release of software, and make it more complicated to debug.

.

Say you already have a function that returns the list of children in a node..

.

But you need a function that brings back only the first child if it exists.

.

1\. Do you copy the function and return just the first item when you have it (with the associated code around the function) for efficiency sake.

2\. Or.. Call the existing function and return the first item if there is at least one element?

.

1 Will be the best answer if you have a million records to load from disk.

2.Will be the best answer if you only have 20-30 records on average.

.

But 2 is the best answer before debugging, check that the code works properly before duplicating it and modifying it.

Answer 3 would be to add a limit parameter, and call the other two functions with it. That way, if limit=0, return all records. if limit=1, return one record maximum.

.

Sometimes the answer is to think differently about the problem altogether.

<comment><USER12> To be pedantic, the answer is neither. You use an abstraction that supports either answer with similar ease, provided by the language/framework/tools you used.

You bring up a very real point, but the most obvious cases are also most obvious to the people developing the stack below you and have almost certainly gone through the trouble of solving those problems.

This issue rears its head when edge cases are non-obvious and typically manifest through profiling, not through design meetings.

</comment></comment><comment><USER13> When starting a project, I prefer to have a "performance budget'.

For example "The application must start in under one second".

Then during development you can divide up the budget - 400 milliseconds for loading dependencies, 200 milliseconds for rendering the UI, etc.

Then you can decide if any given optimization is needed or necessary to meet your goals.

<comment><USER14> The problem with this way of thinking is that those budgets can lead to pathological behaviors. Start time is a great example. Let's say you have 1 second to start, but everything you need to do takes 1.2 seconds.

Okay... We'll defer some work and show a dummy screen to be "started" in less than 1 second, except now we're loading/drawing the dummy screen, so we're usable in 1.4 seconds, and after a double-start flash, so let's smooth that out with a transition to the interactive UI and we're usable in 2.2 seconds, but we "started" the app in 0.4.

Yay?

It may sound contrived, but I've seen this very response to strict start KPI's before. People end up optimizing the micro-goal (KPI) rather than the macro- goal (better experience).

The flip side problem is, when you have multiple people responsible for parts of the work, people will stop optimizing when they hit their budgeted allotment, rather than working to better the whole. A Dev with a 400ms budget might sleep for 390ms to buy himself three years of squeezing out optimizations...

More likely, he'll stop when he gets to 350ms, even though he could have gotten to 250ms without too much effort.

<comment><USER15> Reminds me of the apocryphal story of the game that was trying to get under it's memory budget to be able to run on one of the early consoles, and after scrimping and saving and crunching, they were still over. Until one of the senior engineers commented out an unused buffer that allocated a couple kb "just in case"

<comment><USER16> This one?

[https://news.ycombinator.com/item?id=776296](https://news.ycombinator.com/item?id=776296)

<comment><USER15> That's the one, although I've seen many different variations on the theme.

</comment></comment></comment></comment></comment><comment><USER17> How much optimization you need depends on the situation. The first question is for how many concurrent users are you going to write it for. In most cases O(n^2) is too much unless you know that in practice n is always going to be less than 10. Even then you should be quite certain that n is never going to become bigger, which you very often aren't. Removing constant factors, i.e., turning 3*n into n, should only be done if it is not difficult and is not bad for code quality in most cases. But at some point you should start removing these constant factors. Maybe if you need to handle more than 10000 requests a second. These numbers are highly variable depending on the application, the language and the use.

<comment><USER18> Upvoted you for the first half. Hell, if algo is cubic or exponential out of pure simplicity, then as little as x3-10 input will bring it to its knees. It is not worth revisiting it later with all surrounding costs, if that's inevitable anyway.

Optimization is premature only if the code is not already fantastically stupid, which may happen too often irl to ignore that.

Couldn't agree with constant factors though. These are pretty random, n-independent (i.e. scalable) and the net expense of making code less obvious is usually bigger than throwing more/better hardware at it, but ymmw.

<comment><USER19> This falls apart when you consider one common scenario:

We are loading a number of data files and the source of truth is remote. This is O(n) the amount of data.

Two ways to do it: always request the remote data, or cache it, and only ask the remote for changes.

These differ by a constant factor, and it's always a good idea to maintain a local cache when it's possible. Otherwise there's a very good chance that startup time will be dominated by network requests.

<comment><USER18> Yeah, it depends on how big that const is.

But this also falls into "fantastically stupid" category. Just like all web 2.0 e-stores I have to use, which rerequest their dataset every time you touch sort or filter controls. When their largest category is 150kb json and the entire site json is 10x smaller than their ui/ad frameworks.

</comment></comment></comment></comment><comment><USER20> This article is more current than when it was written.

We are deep into the Post-Moore's Law era, where a new generation gives, now, 120% rather than 200% of the previous generation's performance. Next generation we might get 115% of this, or 110%.

Another consequence is that the improvements we get have become dodgier and less reliable, so that tiny, irrelevant-looking changes in the code may mean a 2x speedup, but more commonly a 2x slowdown. (This is in no way an exaggeration.) The bargain we get from pervasive penetration of more kinds of caches is that sometimes our programs are faster, but we no longer know how fast they should be, or whether another factor of two or ten has been left on the table.

Sorting algorithms are quite mature now, so that a 20% improvement in a relevant case is important, yet a factor of 2 or more may come from the compiler choosing one instruction over another.

Compiler regression bug reports now routinely complain of a 2x performance loss from that instruction choice, but fixing them would result in 2x losses in some other set of programs, instead. We get new unportable compiler intrinsics to patch the failure, that often don't, for obscure reasons.

<comment><USER21> Moore's law was always about transistor density increases, not performance, and definitely not about serial performance in a single core, no matter how much people want to reframe it. Transistor density is still improving, just not as quickly and CPU speed is still increasing, just not on a single core.

<comment><USER20> Not so. Earlier generations came with higher, often doubled clock speeds. Many programmers today have never seen such a doubling, yet policies still assume them.

<comment><USER21> Clock speeds have nothing to do with Moore's law, which was about transistor density. I'm not sure how you can say that a doubling in density hasn't happened when there are "7nm" 64 core CPUs out there. Transistor density has slowed but not stopped. Moore also predicted an exponential increase in price for density improvements which has also seemed to happen.

<comment><USER20> Previously, die shrinks enabled faster clocking. It is a shame you missed those days, but to deny they happened is just sad.

We did not go from 1MHz 6502s to 4GHz Pentiums without a generous series of doublings. Twelve, in fact.

<comment><USER21> I get that you are being intentionally condescending and obtuse here, but you were talking about 'the end of Moore's' law, which only talks about transistor density increases in addition to cost, and both of those are still increasing. Clock speeds, instructions per clock, cache, latency, prefetching, out of order execution and many other aspects of CPU performance were not the trend Gordon Moore outlined. You are conflating things that stem from transistor density with Moore's Law.

<comment><USER20> While Moore's original, concise expression was in terms of transistor areal density, the faster clock rate was implied and expected, just as lower latency is implied by the faster clock. Thus, the stagnation of clock rates is rightly recognized as the beginning of its end. Allocation of the newly available transistors to caches, functional units, execution units, and ultimately extra cores was also implied: _the transistors are not decorative_ : they are there to be used.

With feature sizes approaching a single lattice unit cell, its final stage will be reached shortly.

To insist that transistor count is the only point of Moore's Law is to be deliberately obtuse: it was the exactly the extra value provided by the extra transistors and the machinery built of them, and the faster clocks, that would (and did) generate the capital investment needed to develop each succeeding, more expensive, generation.

<comment><USER21> This is all rationalizing whatever you were trying to say about performance stalling. People only talk about 'the intent' when they realize they have been regurgitating news headlines and haven't looked any deeper. The point is that performance hasn't stalled at all just because clock rates aren't going up. Faster clocks are diminishing returns in performance due to memory latency. Transistor density was the point and performance is still increasing due to transistor density, even if you don't know how to use multiple cores.

<comment><USER20> It is an objective fact that performance increases are much, much smaller than 20 years ago. It is easy to see why, and why continuing (for now) shrinkage of transistors is failing to deliver as much as before.

You are welcome to die on your "Moore's Law is about feature size and nothing else" hill, but you will have sparse company there.

<comment><USER21> "Moore's law is the observation that the number of transistors in a dense integrated circuit doubles about every two years. "

[https://en.m.wikipedia.org/wiki/Moore%27s_law](https://en.m.wikipedia.org/wiki/Moore%27s_law)

It doesn't matter how forcefully you repeat yourself without backing it up.

Also performance has increased with transistor density with more cores.

<comment><USER20> I see that you are convinced that Gordon Moore was an idiot who cared only for counting transistors, and had no interest in how they are used.

I also see that you have confused "much smaller increase", which is observed by everyone, with "no increase", which literally no one has said.

<comment><USER21> I quoted Moore's Law and linked you the actual history, you have some reading to do.

<comment><USER20> I read it in the '80s. And understood it. You could, too, with some thought. It's not too late.

<comment><USER21> Don't you think maybe you should take a step back when you repeat the same things over and over, never back them up and have multiple people link you different Wikipedia articles to correct you?

<comment><USER20> Now you are multiple people?

Anybody can read Wikipedia, but evidently not everybody can understand what it says.

<comment><USER21> [https://news.ycombinator.com/item?id=21926724](https://news.ycombinator.com/item?id=21926724)

[https://en.m.wikipedia.org/wiki/Moore%27s_law](https://en.m.wikipedia.org/wiki/Moore%27s_law)

[https://en.m.wikipedia.org/wiki/Dennard_scaling](https://en.m.wikipedia.org/wiki/Dennard_scaling)

[https://en.m.wikipedia.org/wiki/Cognitive_dissonance](https://en.m.wikipedia.org/wiki/Cognitive_dissonance)

[https://en.m.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effec...](https://en.m.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect)

[https://en.m.wikipedia.org/wiki/Wishful_thinking](https://en.m.wikipedia.org/wiki/Wishful_thinking)

<comment><USER20> And anybody can link to Wikipedia, but very evidently need not understand what it says.

<comment><USER21> [https://en.m.wikipedia.org/wiki/Proof_by_assertion](https://en.m.wikipedia.org/wiki/Proof_by_assertion)

<comment><USER20> Proof by Wikipedia link does not even make the list of fallacies.

2015, Gordon Moore: _" I see Moore's law dying here in the next decade or so."_ <[http://spectrum.ieee.org/computing/hardware/gordon-moore- the...](http://spectrum.ieee.org/computing/hardware/gordon-moore-the-man- whose-name-means-progress>)

Brian Krzanich, the former CEO of Intel: _" Our cadence today is closer to two and a half years than two."_ <[https://blogs.wsj.com/digits/2015/07/16/intel- rechisels-the-...](https://blogs.wsj.com/digits/2015/07/16/intel-rechisels- the-tablet-on-moores-law/>)

John L. Hennessy; David A. Patterson (June 4, 2018): _" The ending of Dennard Scaling and Moore's Law also slowed this path; single core performance improved only 3% last year!"_ <[https://iscaconf.org/isca2018/turing_lecture.html>](https://iscaconf.org/isca2018/turing_lecture.html>)

<comment><USER21> You didn't confront anything I linked. Again, Moore's law is about transistor density, which hasn't stopped yet and has gone into to more cores. It was never about single core performance. Now it seems like you are including dennard scaling after someone else mentioned it.

You have a quote about the time frame increasing which has never been disputed either.

I'm sure you can find links to some tech blogs that have the same misunderstandings as you do, why don't you go hunt those down too?

<comment><USER20> I will pass your comments along to Mr. Moore.

<comment><USER21> I showed him already and he wondered why someone would say computers aren't getting faster when AMD released a 64 desktop.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> If optimization is going to be a concern, the thoughtful choice of the algorithm(s) up front is not "premature".

Currently, I'm working on a project with a ring buffer (a kind of FIFO buffer). It isn't fast (not lockless) but has a well defined interface so I can swap it for fast one later if I need to.

</comment><comment><USER23> Wikipedia has the quotes: [https://en.wikipedia.org/wiki/Program_optimization#When_to_o...](https://en.wikipedia.org/wiki/Program_optimization#When_to_optimize)

We shouldn't reinvent a phrase. Premature optimization has always been about programming efficiently, ie. a newbie programmer or even expert "elite" programmer could easily fall into the trap of optimizing prematurely. That means: Spending too much time on very little gain performance-wise, thinking it's important to eke out every little drop of performance. It's a programming lesson only. Experience even show that premature unproven tweaks can both reduce performance and make code harder to read and maintain.

Then there's the business lesson: Since for the last decades we've had Moore's Law and then more, it's been very hard to make the effort pay off by programming for performance. So businesses have learnt to focus on reducing programming time. Coincidentally, it's been shown that quick lead times are beneficial in the competitive marketplace as well. This is a business lesson (not about the programming phrase "premature optimization"!).

We're seeing a reintroduction of optimization and performance, because meeting a ceiling in CPU cycles and the need to utilize more cores efficiently. So we have Golang, Rust, WebAssembly, etc. Having a snappy website and not annoy your users will pay off as well (hello there multiple choice agreement- notices!).

But the programming lesson still stands: For many types of workloads, it doesn't make sense to spend too much time optimizing, _performance wise_ , unless you see proven benefit outweighing the costs. In most cases, it's actually better to optimize afterwards (ie. prototyping and iterating), unless one has a specific algorithm or solution in mind beforehand.

The business lesson is similar, with the added twist of being a criteria wether you make it or break it. For programming, you could just do it for fun or a hobby, and can premature optimize to your hearts content if you like. But it'll be harder _now_ to fall into that trap instead of making something more worthwhile! ;-)

</comment><comment><USER24> I've never heard anyone actually say that optimization is evil... probably, because people seem to actually enjoy optimizing code.

What's "evil" is optimizing without benchmarks/profiles/etc. Naive implementations are usually easier to write, and can give you a baseline for how much there is to gain (as well as providing "correct examples" for more complicated algorithms).

</comment><comment><USER25> For some parts of a system if you write it correctly the first time there will be no need for optimization, premature or otherwise.

If you know you will need to cache something just cache it, it's not premature, it's best practices.

Exercise the Pareto principal during development and the areas that truly need optimized will present themselves in time.

</comment><comment><USER26> My team at work is extremely guilty of this, and half the time they aren't even correct.

I have coined the term "voodoo optimization" in response to a point Martin Fowler made in his book "Refactoring 2nd Edition": When running Javascript, for example, you are working with a compiler and engine that has had thousands of man-hours and millions of dollars invested into it.

The compiler is throwing away variable declarations. It's merging for-loops. What you put in is not what comes out. You need concrete numbers and FACTS to optimize your code. Deciding "this looks slow" is not an effective optimization method.

</comment><comment><USER27> This article is terrible, just full of straw man arguments and holier-than- thou attitude. Meanwhile, the article completely fails to present any data, completely fails to identify why organizations fail to optimize, and completely fails to provide any solutions. The article basically just pretends there's some large anti-optimization movement so he can knock it down. And even while proving the obvious (that optimization is important), the article uses appeals to authority rather than actual data. Ugh.

> Today, it is not at all uncommon for software engineers to extend this maxim > to "you should never optimize your code!" Funny, you don't hear too many > computer application users making such statements.

Funny, you don't hear too many computer application users asking for optimization, either. The rare, high-profile cases where people complain that something is slow get a lot of attention, but the majority of the time, the feedback you get from users is a resounding silence. I _wish_ users would give me unsolicited actionable feedback on my software, but the reality is, it takes effort to get feedback, and usually people don't complain about performance, they just have a general feeling of malaise about the software that doesn't rise to the level of an explicit complaint. In 11 years of software development, I've had only a handful of users ever complain about performance. The times I've optimized are almost always a result of performance logging. Performance logging lets me say to stakeholders, "This DB query is taking a full second, and 30% of users are exiting the application on that screen--can I spend time to optimize this?"

Funny, you don't _actually_ hear too many software engineers _actually_ saying "you should never optimize your code", either.

I stopped reading at the "observations" section, which were just too full of cringe.

I skimmed the rest, though, and noticed that the author's suggests a few books on assembly language. Good call, guy, I'll be sure to tie my application to a specific processor architecture so I can make it _extra_ difficult to understand why memory is getting thrashed or thread switches are happening at such inopportune times.

</comment><comment><USER21> I think a lot of programmers still don't realize that this idiom comes from doing micro optimizations early.

Software does need to be architected for performance up front. If you aren't able to work on data with a lot of locality or have latency between fundamental operations, you won't get fast software until you address these issues.

If you are really starting from scratch you will barely understand the problem, but once you do, you can make sure your architecture will align with what you are doing. After that, optimization becomes much lower hanging fruit.

</comment><comment><USER28> On a modern full-sized laptop etc, sure code efficiency doesn't matter much. But in anything smaller e.g. embedded device, radio card, cheap phone, it means the world. The difference between a product and a fail.

Embedded programmers can probably be identified by their insistence on code efficiency. Speed, space, storage, all critical to them.

<comment><USER29> "On a modern full-sized laptop etc, sure code efficiency doesn't matter much"

Well it really mattered to me when I lost my patience and replaced a piece of code written in Python that was doing some data manipulation/processing with the native one. Suddenly what used to take an hour got down to less then 1 minute.

<comment><USER28> Yeah big data can always beat the cpu. For apps, not so important I guess.

<comment><USER29> I have made quite a few enterprise grade desktop apps. They'd normally involve device control, real time data processing, graphics multimedia etc all running in many threads communicating using my own internal publish-subscribe and in memory EAV database. For each one performance mattered a great deal.

Yes I understand it may not matter much for many database front end apps but the world does not end on those.

<comment><USER28> Well you're a saint. The average desktop app repaints with stuttering, hangs for seconds, and has all modal controls. So few care about these things any more.

Is 'performance' the right word for this? Its more like user experience or latency - the controls/graphics should be run on a different thread than the data processing.

<comment><USER29> _" Is 'performance' the right word for this? Its more like user experience or latency..."_

It is both. All my desktop apps are strictly native and written with care. Many use DirectX graphics for output. Also I've never bought into this Microsoft's move to .NET on desktop propaganda. Electron etc. - would not touch such frameworks with the wooden pole.

</comment></comment></comment></comment></comment></comment><comment><USER30> Brilliant article. I am currently implementing a programming language and have had to think very hard about representation (in particular). I would highly recommend this for any serious programmer wanting to learn a bit more about performance.

</comment><comment><AUTHOR> This is a reup of [https://news.ycombinator.com/item?id=13505721](https://news.ycombinator.com/item?id=13505721)

I think that this is important to be shared once in a while

</comment><comment><USER31> Premature optimisation, to me, is spending days working out a new algorithm for 5% saving on something that looks inefficient to you but you haven't actually any idea if it's really a problem.

I've never met any of these engineers who think optimization is always wrong.

<comment><USER32> To you premature optimization means spending days eking out 5%, but that's not how everyone sees it. Lots of people I've seen would also call e.g. spending 1 hour vs. 30 minutes on a solution that'd be (say) >= 3x faster "premature optimization" due to the fundamental design decisions (not micro- optimization).

<comment><USER33> Dogmas are a poison to programming.

"No gotos" "You aint gonna need it" "No benefit for the customer"

And of course, the topic of this link.

<comment><USER34> Yes. Experts (and salespeople, when asked for a price) know that the answer to almost everything is "it depends" ;)</comment></comment></comment></comment>


Alternatives to short unconditional jumps on x86 - <AUTHOR> http://www.corsix.org/content/lxi-trick <comment><USER2> Are there problem with CPU cache management? IIRC Intel Sandy Bridge and later generations has micro-ops cache (which lie after the decoder). Wouldn't this and other instruction-level polymorphism tricks severely mess up such cache?

<comment><USER3> The issue with jumps/branches during instruction fetch is that _the CPU doesn 't 100% know whether an instruction is a branch or not_. OK, how is this an issue? Well, the instruction prefetcher will end up fetching useless instructions!

So "modern" (1980s+) CPUs add a branch predictor[1] to the fetch stage. The job of the branch predictor is to determine two things:

(1) Is this instruction a branch? [2]

(2) If it's a branch, is it taken or not?

For the case of unconditional jumps, we can just focus on (1). Therefore, given that the branch predictor is never 100% accurate, even an unconditional branch can result in garbage instructions fetched into the CPU pipeline. So replacing some key unconditional jumps might in fact improve performance.

[1]: Actually, I was lying. There is also the BTB, collapsing buffer, and trace cache.

[2]: The fetch stage doesn't know what an instruction is; that's the job of the decode stage.

<comment><USER2> I understand your point. However, branch prediction is so good nowadays that it rarely matter, especially for short branch [1]

My main concern about trace cache/micro-ops buffer is how it would act when it encounter an instruction boundary change? Would it get flushed? Decoding can be bottleneck for some workload (e.g. SIMD Integer).

[1]: [http://yarchive.net/comp/linux/cmov.html](http://yarchive.net/comp/linux/cmov.html)

<comment><USER4> Branch prediction has gotten a lot better, that's true. Especially by taking more preceding branches into account.

But saying that branch mispredictions rarely matter seems a _way_ too strong statement. In a lot of halfway performance critical software a large number of pipeline stalls are caused by wrongly predicted branches, and utilizing the pipeline efficiently is IMO becoming Mir, not less, important.

</comment></comment></comment></comment><comment><USER5> It would be nice to know when its appropriate to use these. An unconditional jump has no pipeline penalty and doesn't require speculative execution. These alternative jumps save a single byte per if statement (making code size a tiny bit smaller, and slightly reducing pressure on the I-cache).

Is there a risk of introducing a false dependency? I think the answer is no, because if the following code depends on a flag value or the exact contents of %rax then it's probably incorrect.

Maybe modern processors wouldn't like seeing the same instruction bytes decoding to two different micro-ops? That might trigger some horrible slow fallback path.

<comment><USER6> It will probably confuse disassemblers and debuggers. Which might be a bonus, depending on what you're after.

<comment><USER7> IDA certainly complains a lot when it sees this.

</comment></comment></comment><comment><USER8> Techniques like these were extremely common on the NES and other game consoles of the time, where packing as much code into the ROM (fixed-size and expensive to expand) as possible was important. Embedded systems of the same era, and even PC software would often contain them too.

<comment><USER9> So are these techniques only about reducing code size and therefore better utilization of instruction cache? Or is there some penalty to unconditional jumps that may be avoided using such techniques?

</comment></comment><comment><USER10> I don't understand what the author is talking about. He's writing as if people are familiar with this already or can read his mind (the #1 failure of all technical writing). I say this as somebody who understands x86 assembly. What is the following trying to convey?

"For example, jmp $+1 encodes as EB 01 ?? where ?? is the one byte to be jumped over. If burning a register is an option, then mov al, imm8 (encoded as B0 ??) might be an alternative (that is, the byte being jumped over becomes the imm8 value)."

<comment><USER11> Yeah, it's a little opaque. I'll try to rephrase. You have some code, with an if and else. if (cond) X else Y. After that comes code Z. When you compile this, the compiler emits instructions to check the condition, and if it's zero, jump to the else. Otherwise it proceeds to run X. At the end of X, you need to add another jump over Y to Z. Otherwise you'd execute Y too.

Having lots of little jumps in your code can slow things down (well, maybe, depending on CPU, etc., but stipulate that jumps are bad). So at the end of X, you have to have a jump over the length of Y. However, if Y is very short, like 1 or 4 bytes, you don't actually need to use a jump instruction. Instead, pretend the Y instruction is a constant, and load it into a register (and ignore it). The result is the CPU runs X, loads some ignored data into a register, then runs Z. No jumps.

</comment></comment><comment><USER7> Thanks for the hug of death - I've turned on more aggressive CloudFlare caching.

<comment><USER6> It took forever to load the first time I tried it, but it's fast now.</comment></comment>


Why I believe the US has herd immunity in some states - <AUTHOR> https://realscience.community/2020/08/17/why-i-believe-the-us-has-herd-immunity-in-some-states-and-is-barreling-towards-it-as-a-country/ <comment><USER3> NYC had only 20% prevalence in mid-June[1], after they had contained the initial outbreak[2]. Therefore, the drop in new cases is very unlikely to be from herd immunity, which would need prevalence to be in the 80% range.

The author seems to ignore that most people are interacting with far fewer people because they are working from home, kids mostly aren't in school, and our other interactions with people outside our household have been limited and altered to decrease the chances of transmission.

It's nice to think that some people had memory T-cells that could deal with the virus, and it seems some people do, but based on the original R0 numbers, it would be foolish to think that is the case for enough of the population to conclude that we've reached herd immunity.

[1] [https://www.cdc.gov/coronavirus/2019-ncov/cases- updates/comm...](https://www.cdc.gov/coronavirus/2019-ncov/cases- updates/commercial-lab-surveys.html)

[2] [https://coronavirus.jhu.edu/data/new-cases-50-states/new- yor...](https://coronavirus.jhu.edu/data/new-cases-50-states/new-york)

<comment><USER4> The theory was that some large percentage of population is either immune or at least significantly more resistant to covid. Do once the initial 20% get it the other 50-% are resistant so you get your 70% number that way

<comment><USER3> Barring concrete evidence that is the case, it's a very dangerous assertion to make. It would also mean that the transmissibility of SARS-CoV-2 is much higher than we originally thought, amongst those without "natural immunity".

Even if it were the case that half the population was naturally immune, we would want to understand why. The leading explanation at the moment is T-cells and previous exposure to other coronaviruses. Problem is, there's a good chance that previous exposures would be less likely in certain populations, like children, which could be especially problematic as we're debating sending kids back to school.

At the very least, we need more data on T-cell prevalence/reactance to SARS- CoV-2 before we can jump to the conclusion that people are already immune.

But right now, it's far more likely that we've seen drops because of the drastic measures that have been taken and the changes in daily behavior across the population.

<comment><USER5> We already know that the virus is harmless to children. No need to grasp at straws to pretend that our collective hysteria was necessary.

<comment><USER6> While kids are less likely to get sick from it (less likely doesn't mean zero cases or even deaths btw), they can sure as hell spread it. There was some research suggesting that they're spreading the virus as much as (or not detectably less than) adults [1]. Yet at the same time, there are also some indications that kids might be less likely to become infected [2]. How that will affect school reopenings is anyone's guess.

[1]: [https://zoonosen.charite.de/fileadmin/user_upload/microsites...](https://zoonosen.charite.de/fileadmin/user_upload/microsites/m_cc05/virologie- ccm/dateien_upload/Weitere_Dateien/analysis-of-SARS-CoV-2-viral-load-by- patient-age.pdf) [2]: [https://www.nature.com/articles/s41591-020-0962-9](https://www.nature.com/articles/s41591-020-0962-9)

<comment><USER5> Less likely doesn't mean zero cases, but non-zero doesn't mean non-neglible either.

<comment><USER6> It's still a stretch to say that the virus is "harmless" to children.

But that's beside the point. The real point about children is that they can spread the virus just as well, even when they don't get sick - <USER2> since it's also really hard for at least smaller children to keep distance or wear masks.

<comment><USER5> And cruel, almost as cruel as withholding their education from them and forcing them to social distance.

<comment><USER6> You continue to miss the point but ok.

<comment><USER5> This "point" about children is not about children at all. It's about scared, egoistic adults willing to sacrifice children's welfare for their own.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Some up to date news regarding T-cells and their implications suggest this in fact could be a thing with some of the harder hit states. Apparently T-cells will "remember" an infection after a person is exposed to and recovers from covid-19[1]. This is a huge development as it suggests that neutralizing antibodies are not the only defense against a reinfection of covid-19(and these antibodies only last a few months) whereas T-cell memory of infections lasts years.

Also, there are some signs that other cornavirus family of viruses(common colds, not covid-19) could trigger a memory with these t cells, this is a possibility why some have extreme cases and others show no signs of sickness[2]. Couple these points with data showing 40% of people who contract the virus are asymptomatic[3] this leads to the idea that alot more people have had the virus than what is reported, which in this case is a good thing as its closer to herd immunity(if all the above is found to be true).

[1] - [https://www.businessinsider.com/long-term-coronavirus- immuni...](https://www.businessinsider.com/long-term-coronavirus-immunity-t- cells-2020-8)

[2] - [https://www.livescience.com/common-cold-coronaviruses-t- cell...](https://www.livescience.com/common-cold-coronaviruses-t-cells- covid-19-immunity.html)

[3] - [https://www.washingtonpost.com/health/2020/08/08/asymptomati...](https://www.washingtonpost.com/health/2020/08/08/asymptomatic- coronavirus-covid/)

<comment><AUTHOR> yes agree. And the CDC reports there are 10X the cases of COVID than has been reported based on antibody studies. And there are many more deaths than have been reported [https://realscience.community/2020/08/16/why-a-lot-more- peop...](https://realscience.community/2020/08/16/why-a-lot-more-people-have- died-from-covid-than-is-being-reported/). All reasons that we are closer to herd immunity than is the common perception.

<comment><USER8> Doesn't herd immunity for a country of 350 million need somewhere on the order of 220 million to have been exposed and recovered? I don't think we're anywhere near that yet.

<comment><USER9> How do you define that 220 is the right number?

<comment><USER10> It's an estimate based on the probability of a virus finding new hosts. the higher the proportion of potential hosts that are immune, the less likely the virus is to spread.

<comment><USER11> Herd immunity is the threshold where the replication rate falls below 1. It's not the point at which transmission stops. The disease will continue beyond that point.

<comment><USER12> Thats, uhm, very limited understanding. Currently behavioral changes (mask, etc) are much larger factors affecting R0 and none of them have any bearing on hwrd immunity.

Plus we are finding that traditional herd immunity (aka just let the disease rampage) may come at the cost of heart disease in a majority of cases.

<comment><USER11> Of course they have an effect on herd immunity. If behaviour changes then the replication rate changes and hence the herd immunity threshold changes.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> Should it be called herd immunity if it depends on current social practices of physical distancing and masking? Sure, you might have "effective herd immunity" in some regions, but those herd immunity percentage targets go up if people start interacting more.

<comment><USER14> I think the name still applies, and it's intuitive that this number is a function of the connectivity of your network.

<comment><USER15> I think using herd immunity to apply to temporary network states is going to be more confusing than helpful. There will be some fuzziness at the edges - some of the changes and adaptations we make during this pandemic will probably persist longer term.

</comment></comment></comment><comment><USER16> > This analysis and the conclusions that I have drawn are my own and do not > necessarily reflect the opinions of the wider scientific and medical > communities.

That's an important point because the wider scientific and medical communities don't agree with this analysis at all.

<comment><AUTHOR> Well some do- MIT's paper, MIT Tech seems to [https://www.technologyreview.com/2020/08/11/1006366/immunity...](https://www.technologyreview.com/2020/08/11/1006366/immunity- slowing-down-coronavirus-parts-us/)

<comment><USER17> They only seem to agree with the weaker claim that immunity _plays a role_ in the patterns we're seeing, not the stronger claim that general herd immunity has been achieved anywhere. And it's a _very_ brief superficial article, not exactly comparable to peer-reviewed studies that tend to reflect a nearly opposite conclusion.

<comment><AUTHOR> Data source for "peer-reviewed studies that tend to reflect a nearly opposite conclusion"?

<comment><USER17> You go first. You claimed there were others that agree with you, but that doesn't really seem to be true. Provide a _serious_ citation, and I'll reciprocate.

<comment><AUTHOR> The MIT tech is serious. MIT doesn't publish garbage science in their news paper.

<comment><USER18> I'm not sure many/any serious scientists take it seriously. It's interesting, but it's far from peer reviewed journal type material.

<comment><AUTHOR> The Tech quotes peer reviewed science like the lay press. But they generally do a better job of quoting quality science and conveying the research accurately (as opposed to politically). I think the issue here is speed. Most of the research informing this pandemic is scientist opinion, back of the envelope calculation, and pre-prints. The reason for this is that peer review lives in the world of years and we need information in the world of days to weeks to make good decisions for public health. If we wait for peer review, the pandemic will be over or the conclusions will be obsolete.

<comment><USER19> This person is discrediting MIT.

There's nothing you can say to make this person consider your viewpoint.

<comment><USER18> No one is discrediting MIT. MIT Technology Review simply isn't a science journal. Nothing is peer reviewed. It wasn't intended to be, no one thinks it is. It's an interesting technology magazine.

<comment><USER19> MIT journal is written by some of the top scientists in the world. Its not peer reviewed but it at least deserves consideration and respect.

But like a lot of intelligent ideas now days...if it doesn't fit someone's narrative it's immediately discredited and discarded.

Only the experts who agree with the narrative are to be taken seriously.

It's become a real problem to discredit ideas that disagree with ones narrative even if they're from expert sources.

<comment><USER18> Then maybe just quote the person who wrote the article. You are missing the point: If you want to appeal to an authority in science, it's a high bar. I read the MIT Technology Review. I like it. I respect it for what it is. But, it's simply not good enough in a science discussion to say "MIT Technology Review says X". The bar is higher. It's not a function of politics or existing narratives or anything of that nature.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> This is barely even an article. You state a trend and then say herd immunity must be happening because... you cannot think of any other reason.

<comment><AUTHOR> Can you think of another reason? The states with above ~30% infection rates are now trending down. They are not being more careful. Sometimes logic is that simple.

<comment><USER21> New Yorkers are only interacting outside, where there is airflow constant supply of fresh air.

Same with the beaches you photo'd.

People in NY/NJ are NOT hanging out together inside. They're not in schools, not in offices, etc.

So YES, they are being more careful.

<comment><AUTHOR> OK I was in Ocean City NJ at the beach a month ago. This is just not true. I was in the women's bathroom- no masks, 6 inches from other people, no airflow. I'd say about 1/10 wearing masks. People crowded together.

</comment></comment></comment></comment><comment><USER22> Isn't this hypothesis pretty easy to validate/falsify?

Just take a random sample of 1K NY residents and test them for antibody/t-cell presence. 1K is plenty to make a statistically significant sample size when you're suggesting the true infection rate is double digits.

Why do we NOT know what the population infection rate is? It seems relatively easy to do.

<comment><AUTHOR> But we also don't know what antibody/T-cell levels, which btw testing for Tcells is not widely available or commercial, would = herd immunity. So there is no result that would prove herd immunity.

<comment><USER22> > But we also don't know what antibody/T-cell levels... would = herd immunity.

OK, but wouldn't a random sampling at least provide an answer to what pct of the population was infected at some point? That seems like a great starting point.

<comment><AUTHOR> Yes, and for some reason, NYC and the CDC are not releasing results later than mid April. It is very suspicious imo. They were releasing antibody results and then abruptly stopped without explanation.

<comment><USER22> Can you point me to the latest released results? Thanks!

<comment><AUTHOR> This just came out [https://www1.nyc.gov/site/doh/covid/covid-19-data- testing.pa...](https://www1.nyc.gov/site/doh/covid/covid-19-data-testing.page)

<comment><USER22> The antibody test results for this data set don't seem representative of the population at large. Reason being, if you look at the antibody positivity rate, it consistently drops as time goes on (whereas everything I've read suggests it should increase with time as more ppl have been infected).

My guess is that at the beginning, hospitals were only testing COVID-sick patients, and as time went on testing became more widespread.

<comment><AUTHOR> Or the initial antibodies drop in people that have had COVID over time (which they probably do). The antibody tests test for the kind of antibodies that are present immediately- over time a previously infected person will have less of those antibodies and more of the back up Tcell kind. You can read a review on this here: [https://www.nature.com/articles/d41586-020-02400-7](https://www.nature.com/articles/d41586-020-02400-7).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> When it comes to CoVID-19 analysis, I prefer mine in the form of a peer- reviewed paper from a reputable journal.

<comment><AUTHOR> Good luck- you might be waiting a while. Peer review takes months to years. At that point it's too late for preventative strategies for a pandemic.

<comment><USER23> Years? No. And if you want to improve the peer review process, lobby for paying reviewers ([https://link.springer.com/article/10.1007/s11192-017-2310-5](https://link.springer.com/article/10.1007/s11192-017-2310-5)).

Regardless, I stand by my original point. I prefer peer-reviewed analysis. The alternative is a free-for-all where junk claims equal weight with legitimate science. Such a system is usually supported by folks whose work can't make it through the traditional system.

<comment><AUTHOR> Oof now we are saying that my work is not of publishable quality? The data are from two days ago so it would be hard to get it peer reviewed in that time. But I do plan on publishing. I am putting it out there so people can make more informed decisions (about schools etc) in real time.

<comment><USER24> You could put this up on biorxiv and invite other researchers to comment.

<comment><AUTHOR> That's a good idea- that too will take some time- writing a paper is not a small task but I will put it on the to do list.

</comment></comment></comment></comment></comment></comment><comment><USER25> I block new domains via NextDNS, so if anyone's interested this domain was only registered 2020-07-31.

<comment><AUTHOR> Yep it's a new site, just created it:)

</comment></comment><comment><USER26> Simple math below.

NY has 1,300 deaths per million, and NJ has 1,800 deaths per million currently. Let's take the average and say that they reached herd immunity with 1,500 deaths per million.

Great.

For the entire US (320 million), that implies 480,000 deaths before reaching herd immunity.

Does 480,000 deaths sound good to anyone?

<comment><AUTHOR> It's not good, no. But I am not suggesting that this was a good plan. I am just saying it is the plan that is happening. I think the US government took a really bad route in handling the pandemic. New Zealand had the best model imo- shut down hard and early and eradicated. Hardly any deaths. Were able to reopen in 6 weeks.

<comment><USER27> Does the US approach mean countries like New Zealand need to stay isolated until a vaccine is found? Or would herd immunity eventually eradicate the virus in US?

<comment><AUTHOR> They should definitely have anyone abroad strictly quarantine for at least 14 days upon entering the country. Herd immunity would slow it to a crawl but it seems like it could pop back up in odd pockets of previously unexposed people. We also still don't know how long immunity will last- scientists are hopeful that it will last until a vaccine is produced but that's not a guarantee.

<comment><USER27> Thanks

</comment></comment></comment></comment></comment><comment><USER28> That first paragraph, where the author seems to, even in jest, place blame on his college professor, all the wording and weird emphasis on that, it's just really really strange. I certainly would not want to be his college professor.

<comment><USER29> Not even sure what you're getting at.

It's a common type of tongue-in-cheek comment, one can find in tons of writings. "Blame X who inspired me to study Y, and led me down this path".

There's no actual blame, it's just praise for his professor (and that's immediately understood as such).

There's nothing "really really strange" about it, and there's no "weird emphasis" (it's a mere passing line in a big post). If anything, your pointing it out is weird.

<comment><USER28> Eh, I read it differently. It's not just one line, it's three sentences followed by a reference to the political climate. I think it's a bit much and it threw me off while I was reading it. I've seen those kinds of jesting comments in other blogs, but this one is more awkwardly phrased. When they write "Sorry Dr.Hume" I do actually feel sorry for his professor!

</comment></comment></comment><comment><AUTHOR> Ok I'm going to put this at the top since I believe it sheds further light on many of the points. This is a talk at UCSF's medical grand rounds (the weekly science talks given to all doctors at UCSF). At 38 minutes, one of the scientists cited by the MIT tech explains his findings in support of herd immunity. It's not peer reviewed yet because it's brand new- peer review takes a minimum of three months. He shows open table and google maps data in support of people not being much more careful in Florida or AZ. He also explains the interplay between mask wearing etc and RT. Hopefully you will find this to add extra rigor to what I have been saying. It is pretty dry- but that is the nature of this sort of talk. [https://www.youtube.com/watch?v=Ew2MEF4XX8w](https://www.youtube.com/watch?v=Ew2MEF4XX8w).

</comment><comment><USER30> Sorry for hijacking this thread, but it'd be great if some serious science/politics show hosts an extended debate from both POVs and have a serious scientific conversation about what's next in covid? herd immunity or not?

</comment><comment><USER31> > Why would Floridas numbers start to decrease if not for herd immunity? We > know they aren't being more careful. Disney land reopened and there is a > police sheriff who literally made a rule that police officers and people > going into the station were not allowed to wear masks.

This is idiotic. Rather than "herd immunity" one could, in fact, be seeing the impact of large numbers of people having been scared straight simply avoiding further contact.

The author's conjecture could be correct but they offer no proof.

</comment><comment><USER32> Does Sweden have herd immunity? They didn't lock down, but they did implement social distancing recommendations.

Does Belarus have herd immunity? No lockdown, no social distancing to speak of, basically nobody wears a mask, er, anywhere. I see people in the centre of Minsk having face-to-face conversations all day long. And now there are tens of thousands of people protesting/yelling/hugging each other without masks.

I very much hope the answer is yes and these countries do have something close to herd immunity. But that feels like wishful thinking.

<comment><AUTHOR> This is what the MIT Tech has to say about Sweden (and I agree): "Lessons from Sweden Outside the US, researchers are also closely tracking the role of population immunity in national responses. Sweden, for example, did not impose a strict lockdown, and saw a large number of deaths starting in April. Since then, however, the number of new infections has declined. The nation's leaders said last week that children would go back to school unmasked. "I would say in Sweden there is no doubt that immunity plays an important role, more than in other countries," says Britton. "Now this epidemic is slowly stopping." [https://www.technologyreview.com/2020/08/11/1006366/immunity...](https://www.technologyreview.com/2020/08/11/1006366/immunity- slowing-down-coronavirus-parts-us/)

<comment><USER18> I don't think you realize the quoting of MIT Technology Review isn't helping you. It's hurting.

<comment><AUTHOR> ? care to explain?

<comment><USER18> MIT Technology Review says X is an appeal to authority. They aren't one. Hence it doesn't work. It also makes you seem naive.

</comment></comment></comment></comment></comment><comment><USER33> Yall gotta know that life is almost totally normal in the Netherlands and has been for months. Almost no one is dying. It's likely because people get so many colds in the winter, so there is general immunity.

Or we are all about to die...?

<comment><USER34> I spent several pandemic months in the Netherlands. I have two ancedotes.

Often if I was running on the sidewalk and encountered another person they would cross to the other side of the road (or I would).

On my street there were 3-4 parties every week. I work late so loud music didn't effect my sleep much.

Generally I felt like people kept their distance although I think compliance is a big issue with lockdowns everywhere.

</comment></comment><comment><USER35> We _know_ that the numbers are being futz with to make things look less bad. They've artificially low, and have been since the data has been redirected through the White House, and the expressed political beliefs of the resident there. In particular, by playing with the number of tests being run.

Longer explanation here (not mine): [http://martinhillortiz.blogspot.com/2020/08/coronavirus- case...](http://martinhillortiz.blogspot.com/2020/08/coronavirus-cases-and- playing-games.html)

<comment><AUTHOR> Yeah I'm pretty worried about data corruption. I have been planning to compare all the databases. Thanks for the link- I'll check it out tomorrow.

</comment></comment><comment><USER36> There have been multiple studies now that suggest significant herd immunity kicks in around 20-30% infection rate. We should see in a couple of weeks but if every state and country continues to hit an infection wall around 30%, it bodes well that the end is near.

It also suggests that even 10-50M vaccines (in the US) can make an enormous impact and this thing may be over (as a severe widespread issue) in 2020.

I'm excited to see the next 4-6 weeks of data on this.

<comment><USER37> "Herd Immunity" is a spectrum, as some already commented. It depends highly on the introduced restrictions measures. So for some limited masking it will appear at the earlier moment, but once people stop wearing them, the threshold will go up.

</comment></comment><comment><USER26> I think the winning countries in this pandemic would be the ones who were able to collectively wait for a vaccine while maintaining low death rates.

Sadly US will not be one of those.

</comment><comment><USER38> Can someone explain to me why every Covid submission that makes it to the front page of HN seems to take the 'denialist' perspective? Is an agenda being pushed? There must be so much important science being done right now, surely we would rather hear about that.

<comment><USER22> How is this a 'denialist' perspective? The author is affirming that COVID is real and so widespread that some areas are reaching herd immunity...

<comment><USER38> The idea is that if we have reached herd immunity then we can all go back to work/school and forget about Covid. This is a very dangerous line of thinking, and indeed is self fulfilling - ignoring Covid will sure enough result in herd immunity (assuming we get lasting immunity - unlike the common cold coronavirus!), but at the cost of thousands of lives and serious long term health effects.

</comment></comment></comment><comment><USER22> Interesting that this is flagged. There are almost no strong claims made in the article. Are people not open to a discussion about herd immunity?

<comment><USER39> I don't think it's an unreasonable submission (which, just to pre-empt some objections, is an orthogonal question to agree vs. disagree), and it's a bonus that the author is here to comment. We'll turn off the flags for now.

<comment><AUTHOR> Thanks!

</comment></comment></comment><comment><USER40> When herd immunity is reached new cases don't hum along at a lower but steady rate, as they are in New York State. Herd immunity means that infected individuals can't find enough non-infected people to infect, R0 is well below 1, meaning that cases exponentially drop to zero. Check out the chart for New York's new cases, it isn't happening.

[https://www.worldometers.info/coronavirus/usa/new- york/](https://www.worldometers.info/coronavirus/usa/new-york/)

<comment><AUTHOR> Herd immunity is not in reality a single cutoff, it's a spectrum. So there is some point- looking like ~30% where R<1 and cases dip. But the > the %, the more immunity.

<comment><USER11> Technically it's the threshold where R drops below one. You might expect transmission to continue for some time.

[https://en.wikipedia.org/wiki/Herd_immunity#Overshoot](https://en.wikipedia.org/wiki/Herd_immunity#Overshoot)

<comment><AUTHOR> Sure. That is the technical definition. My point is that the rate at which cases will drop is proportional to the percent of the population that is immune. It's not a binary.</comment></comment></comment></comment>


Show HN: TravelGreen, offset your Uber rides - <AUTHOR> https://travelgreen.io

<comment><AUTHOR> This is my first web app so feedback is greatly appreciated.

<comment><USER2> I would make it clear up front that this is not for offsetting the monetary cost of Uber rides.

<comment><AUTHOR> So it isn't clear that you are donating towards carbon offsets ? Thanks for the feedback and will incorporate.</comment></comment></comment>


The New Science of Psychedelics: A Tool for Changing Our Minds - <AUTHOR> https://singularityhub.com/2019/03/31/the-new-science-of-psychedelics-a-tool-for-changing-our-minds/ <comment><USER2> I miss Terrence McKenna. Pollan is ok.</comment>


Material Design Exploration by feedly - <AUTHOR> https://medium.com/@abrodo/an-exploration-in-material-design-by-feedly-8c1a1cbdfdcd

<comment><USER2> This is such a beautiful way to show via the animations rather than tell. I love the exploration and comparison to print design showing the grids overlaying the images. Nicely done. Super excited to see how this will influence future iterations of the product.</comment>


Kore: a fast web server for writing web apps in C - <AUTHOR> https://kore.io <comment><USER2> Awesome! I've used [https://www.gnu.org/software/libmicrohttpd/](https://www.gnu.org/software/libmicrohttpd/) in the past (for fun stuff I was building to learn C), will try this out instead. But..

> Only HTTPS connections allowed

Seems a bit painful. HTTPS on the webserver itself is a fair bit more painful to setup and administer than HTTPS in your reverse proxy / loadbalancer (I prefer nginx). Web servers should support plain HTTP.

<comment><USER3> You can turn off TLS on Kore.

$ make BENCHMARK=1

It is not a run time option by design, but it is there.

I want Kore to have sane defaults for getting up and running. That means TLS (1.2 default by only), no RSA based key exchanges, AEAD ciphers preferred and the likes.

edit: spelling

<comment><USER4> RSA with DHE or ECDHE is a sane handshake. I would avoid DSA and ECDSA based key exchanges because they fail catastrophically with bad random number generators. For most APIs session caching is more important than a faster initial handshake.

The HTTPS only choice would annoy me a lot because I run most HTTPS services in behind a reverse proxy in a FreeBSD jail on the same host. HA proxy and nginx are still superior to most applications in regard to reliable TLS termination.

Using HTTPS by default a the right choice for a new project but offering no HTTP support (outside of a benchmark) patronizes the user.

All in all this looks like a nice way to export C APIs through HTTPS.

<comment><USER3> Thanks.

I agree the BENCHMARK build option is a bit confusing. I might end up renaming it altogether.

<comment><USER3> For sanity sake, this build option is now NOTLS.

</comment></comment></comment></comment></comment><comment><USER5> I'm curious- why C? Strings, scoped objects and C++11 move operators seems much safer and clearer from an API perspective.

The complaints about C++ seem to mostly be around the ability to abuse the language, not specific issues that C solves. Something like [https://github.com/facebook/proxygen](https://github.com/facebook/proxygen) seems like a better API.

And I don't quite buy portability- if it's not a modern compiler with decent security checks then I'm note sure it should be building web-facing code.

<comment><USER6> It seems that people are so intimidated by the infamous complexity of C++ that they don't even want to bother getting more familiar with it.

So, although technically the existence of C doesn't make sense, as it is superseded by C++ (except couple of things), C is winning in the branding department.

<comment><USER7> I don't know if this is the reason why people choose C over C++ for some projects, but if language complexity is the reason, it isn't that people are just "so intimidated by the infamous complexity of C++ that they don't even want to bother getting more familiar with it".

In the 90s, C++ was much more popular than it is now. It was used as the go-to general purpose language for all kinds of "serious" software (not addressed by VB or Delphi). Early on, almost everyone was very impressed with the power C++ brought, but after a few years, as codebases aged, it became immediately clear that maintaining C++ codebases is a nightmare. The software industry lost a lot of money, developers cried for a simpler, less clever language, and C++ (at least on the server side) was abandoned en-masse -- almost overnight -- in favor of Java, and on the desktop when MS started pushing .NET and C#. So while today C++ is servicing its smallish niche quite well, as a general- purpose programming language for the masses it actually proved to be an unmitigated disaster. It is most certainly not the case that C++'s infamous complexity is "intimidating"; C++'s complexity is infamous because of the heavy toll it took on the software industry. Which is why, to this day, a whole generation of developers tries to avoid another "C++ disaster", and you see debates on whether or not complex, clever languages like Scala are "the new C++" (meant as a pejorative) or not.

<comment><USER8> I also feel like a lot of people are biased because of Stallman and Torvald's stance on C++. I kind of have an irrational distaste towards the language, mostly due to their influence.

<comment><USER9> And Yosef Kreinin. Not arguing for or against the FQA, but its mere existence catalyzed (not fed) my journey of critical thinking towards C++.

</comment></comment></comment></comment></comment><comment><USER10> It speaks poorly of this community that you get second-guessed more for building an application in C than for building one in JavaScript + Node.js.

<comment> j-pb If you want to use C today you need a really good excuse. The tradeoff between security and performance is simply not there anymore.

Unless you write on an embedded system, a game, or a high performance number crunching application, C is premature optimisation.

And even in the above we see drastic changes today, embedded systems have become so powerful that they can run scripting languages ([http://www.eluaproject.net](http://www.eluaproject.net)), game engines are written in C and scripted with other things ([http://docs.unity3d.com/ScriptReference/](http://docs.unity3d.com/ScriptReference/)), and inmemory-bigdata systems like spark offer significant advantages over classical HPC frameworks like MPI ([http://www.dursi.ca/hpc-is-dying-and-mpi- is-killing-it/](http://www.dursi.ca/hpc-is-dying-and-mpi-is-killing-it/)).

While JS is horrid, it at least doesn't have manual memory management.

<comment><USER11> C is alot about portability, not necessarly performance.

<comment> j-pb If you only care for portability you can always use one of the billion safe languages whose interpreters are written in C. Lua for example.

<comment><USER12> You may not _only_ care about portability. And "safety" sometimes also means being able to meet realtime requirements, and also often means having the ability to carefully account for resource use in ways that many interpreters does poorly (and no, kernel enforced system limits are not always an option).

Many interpreters also make assumptions (e.g. expecting a POSIX'y system) about the host system that many embedded platforms doesn't necessarily meet.

I've more than once looked at interpreters for embedding and found most of the alternatives sorely lacking. Very few interpreters are well suited for embedding on constrained platforms at all (Lua, admittedly is probably one of the more solid exceptions). And once you start having to write lots of support code in C to port or sandbox your interpreter of choice, the reason for considering an interpreter quickly becomes less compelling.

</comment></comment></comment></comment></comment><comment><USER13> Writing a web application in C sounds like a good trigger for an utterance from the Jargon File: "You could do that, but that'd be like kicking dead whales down the beach."

We've advanced the state of the art quite a bit with dramatically more expressive languages than C that are sufficiently efficient in terms of memory and CPU. This is especially true when communications are occurring over HTTP and not direct socket-to-socket comms.

Why use C instead of D, Rust, Go, C#, Java, Perl, Python, Ruby, Scala, Clojure, Erlang, Elixir, Haskell, Swift, OCaml, Objective-C...?

I didn't miss C++, it just seems a worse alternative than C.

<comment><USER12> > Why use C instead of D, Rust, Go, C#, Java, Perl, Python, Ruby, Scala, > Clojure, Erlang, Elixir, Haskell, Swift, OCaml, Objective-C...?

Because C runs pretty much _anywhere_? There are plenty of platforms where C is available where I doubt you'd find any of the others above (e.g. C64; yes there are C compilers for them; yes, I'm mentioning it tongue in cheek)

Because you can generate small, compact static executables? E.g. I used to write network monitoring software and an accompanying SNMP server for a system with 4MB RAM and 4MB flash, the latter of which had to include the Linux kernel and a shell on top of the application in question. The system was so limited we did not run a normal init, and couldn't fit bash - instead we ended up running ash as the init...

There are plenty of use-cases where "web application" == "user interface for a tiny embedded platform".

<comment><USER14> > Because C runs pretty much anywhere?

I always hear this argument, but as time has progressed, for better or worse 'anywhere' has become a much smaller target. If your language runs on Intel and ARM then it's good enough. There are a lot of reasons I might choose C for a project, but 'run anywhere' is not one of them.

<comment><USER15> I'd say Intel, ARM, Power, and Sparc is good enough.

</comment></comment></comment></comment><comment><USER16> This looks pretty neat actually. A ton of effort clearly went into it and it looks like the code is really well written with pretty well thought out interfaces

"Its main goals are security.."

Is it actually?

I also don't really see an advantage of using something like this over something like the Go net/http package.

Web-type API stuff is usually high enough level that something like C doesn't make sense. Go has nice enough standard packages for system things that even if I was doing a lot of system-y stuff I would be alright. I don't really see the type of work I would be doing where I want to use this.

<comment><USER17> It does seem like if your goal was security than perhaps Rust would be a better choice.

<comment><USER18> If your goal is security literally any high level language is a better choice.

<comment><USER19> High level language like php ? Security and secure code is a mindset. You code without thinking that bad things will happen, you will get bitten.

Sure high level language can help with memory management... but plenty of CVE are because of sloppy coding, not because of low level language.

<comment><USER20> While you are correct in that picking a higher level language doesn't shield you from writing insecure code, insecure C/C++ failure modes are usually quite a bit worse than other languages used for that purpose. I don't trust myself to write code that handles memory 100% correctly and is also network-facing. If much better developers than I manage to screw that up, what chance do I have?

<comment><USER21> Mmm, it can be difficult to take advantage from C exploits (in the context of a webserver). On a well written C system, you might expect most bugs to lead to crashes.

PHP bugs tend to be more exploitable, because you're doing something supported by the language.

<comment><USER20> But what's stopping someone from writing an app-level vulnerability in C vs any other language? Most of them are because of horrible handling of strings, which is something C is also not that great at. I'm not seeing the security benefit here.

<comment><USER21> My gut feeling is that if you really want security in C, you have fewer constructs to misuse and so you get less unexpected behaviour. At the same time, you get more protection mechanisms; guard pages etc. I.e. harder to be secure, but if you really want to harden, you can get harder than in higher level languages.

I'm not putting any kind of weight behind that, though; I just feel that it's a bit odd for people (not specifically meaning you, just the whole thread) to criticise this purely on language choice and not put any substance behind their criticisms that actually relate to the software in question.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> The site and documentations looks well done, great job!

Architecture looks pretty interesting too. Wonder why was there a need for an accept lock? Ordinary accept() socket call already allows for simultaneous threads/process wait on a single socket.

<comment><USER23> I think the authors want to avoid thundering herd. You can find this basic pattern in the book _UNIX Network Programming_.

<comment><USER3> Correct.

The accepting socket is shared between multiple workers which each have its own fd for epoll or kqueue. Because of this a form of serialising the accepts between said workers is needed to avoid unnecessary wakeups.

<comment><USER22> Actually that is being changed:

[http://lwn.net/Articles/633422/](http://lwn.net/Articles/633422/)

See part about EPOLLEXCLUSIVE

<comment><USER3> That is great, thanks for sharing.

<comment><USER22> If you are the author, thanks for sharing the project. You did a great job and made the right choice of having per CPU worker processes each with their own epoll loop.

</comment></comment></comment></comment></comment></comment><comment><USER24> Great! This looks really nice, and interesting.

Some fantastically quick points from a very cursory glance at the code. Feel free to ignore this.

\- The code uses the convention to put the argument of return inside parentheses, making it look like a function call. This is very strange, to me.

\- It treats sizeof as a function too (i.e. always parentheses the argument).

\- It is not C99, which always seems so fantastically defensive these days.

\- It's not (in my opinion) sufficiently const-happy.

\- I saw at least one instance (in cli.c) of a long string not being written as a auto-concatenated literal but instead leading to multiple fprintf() calls. Very obviously _not_ in a performance-critical place, so perhaps it's not indicative of anything. It just made me take notice.

<comment><USER3> Author here.

I see you picked out the few things that I consistently hear on the coding style I adopted which is based on my time hacking on openbsd. I have no real points to argue against those as it is based on preference in my opinion.

I am curious why you arrived on it not being sufficiently constified however. I'll gladly make sensible changes.

As for the multiple fprintf() calls ... to me it just reads better and the place it occurs in is as you stated pretty obvious non performance critical.

<comment><USER24> Right. I could have guessed these were based on some coding style guide from somewhere.

I still don't see the point, or why any sane guide would prefer to treat return as a function. It just never seems helpful to me, and always wasteful/more complicated. I realize it's just two tokens, so it's probably not "important" in any real sense of the word, but it irks me. I like to point it out since it can help others cargo-culting this.

It's not sufficiently const if there are places where a variable could be const but still isn't. :) To be super-specific, the variable 'r' here: [https://github.com/jorisvink/kore/blob/master/src/cli.c#L542](https://github.com/jorisvink/kore/blob/master/src/cli.c#L542) is one such case. It should be declared inside the loop, i.e. as "const ssize_t r = write(...);" since once assigned the return value from write(), it's read-only.

Of course, many ancient-smelling style guides seem to outlaw declaring variables as close to their point of usage, too. Note that declaring variables inside scopes other than the "root" one in a function isn't even C99, but many people seem to think you can't do that.

<comment><USER3> That's fair. Parenthesising return is a matter of readability and flavour to me. It tickles my spidey sense if it is missing.

I strongly dislike declaring variables anywhere else but the function root, but I agree with you on the example you provided that those kind of variables could be constified to be sane.

</comment></comment></comment></comment><comment><USER25> Previously: [https://news.ycombinator.com/item?id=5995298](https://news.ycombinator.com/item?id=5995298).

</comment><comment><USER26> Was quite excited to try out a little websocket server with Kore till I saw it fork's per connection. I don't really want 20k processes for handling 20k connections, I was really hoping for an event loop.

<comment><USER27> Evented io is great for extremely high concurrency, but that isn't always the right thing to optimize for. A forking web server might be faster for users depending on the application.

Lastly, you can't just have an event loop without also creating an entirely async platform. For an event loop to work well, all operations from file reading to network requests need to be completely async.

<comment><USER28> Out of curiosity in what scenarios do you see a forking web server being faster than a evented server that balances requests across cores and can direct a request to the core with the best cache for the request?

I completely agree with need to async. The hard part is that many operations are async without an async interface. For example memory allocation, or even memory usage if the memory was not truly allocated by malloc.

<comment><USER29> Any non asynchronous application.

<comment><USER30> Why would you have a web server that doesn't process requests async?

<comment><USER31> There are a few reasons I can think of.

1) Client libraries you might need to use in your web service might not be available in asynchronous versions.

2) Writing blocking code is much easier to write than asynchronous code.

3) Your server code is CPU bound, so there's no benefit to an asynchronous model.

4) If your web app runs in an asynchronous server and your app crashes, it'll crash the whole server. On the other hand, in a forking model, only the client that the child is serving will be impacted; the other workers will be unaffected.

5) Memory leaks are easier to contain in a forking model, assuming the child can exit or be killed after N requests.

</comment></comment></comment></comment></comment></comment><comment><USER32> I've used [https://github.com/cesanta/mongoose](https://github.com/cesanta/mongoose) in the past maybe I could try this one.

</comment><comment><USER33> Writing high level C applications can be easy, if you use a library that frees you from using dynamic memory on typical data structures (e.g. strings, vectors, sorted binary trees, maps). I'm developing a C library for high-level C code, with hard real-time in mind, is already functional for static linking: [https://github.com/faragon/libsrt](https://github.com/faragon/libsrt)

</comment><comment><USER34> When an HTTP API is just an additional feature of a larger project, it may make sense to keep using C: a toolchain available everywhere and well known (including cross-compilation and full bootstrap), a small memory footprint, easy use of any library needed for the project.

I am doing a lot of that and will keep a look at Kore. Unfortunately, HTTPS only and non-evented core is a no-go for me.

I am currently relying on the web server embedded in libevent, as well as wslay for websockets and some additional code for SSE. To easily start a project, I am using a cookiecutter template: [https://github.com/vincentbernat/bootstrap.c-web](https://github.com/vincentbernat/bootstrap.c-web)

<comment><USER3> Perhaps you can check out the websocket and SSE examples.

[https://github.com/jorisvink/kore/tree/master/examples/sse](https://github.com/jorisvink/kore/tree/master/examples/sse) [https://github.com/jorisvink/kore/tree/master/examples/webso...](https://github.com/jorisvink/kore/tree/master/examples/websocket)

</comment></comment><comment><USER35> Probably it would be better to have also a lib or dll, not just a program that render c/c++ servlets. It seems that all (that the kore executes from the feeded code) is running in servlet threads or at least started from servlet thread. Or it would be cool to add some "application" framework, not only "C-servlet" framework

</comment><comment><USER36> Has anyone done any performance testing on kore? Yes I know I can do this myself, but why invent the wheel.

<comment><USER37> You'd invent the wheel to get you places. You wouldn't _reinvent_ the wheel when someone's already done a perfectly good job.

<comment><USER38> as in... [http://okws.org](http://okws.org)

<comment><USER36> Interesting. Any performance data on this beyond the vague it is faster?

<comment><USER38> Anything I've seen is 10-ish years old. It was relatively fast, but also complex and covered by the GPL (for better or worse).

<comment><USER36> I found this which seems interesting

[https://github.com/koanlogic/klone](https://github.com/koanlogic/klone)

<comment><USER38> The portability aspect is interesting.

I use uwsgi extensively (not just with python), and I think it sets the bar these days.

</comment></comment></comment></comment></comment></comment></comment><comment><USER39> If you think Kore is interesting, then also check out Tntnet <[http://www.tntnet.org>](http://www.tntnet.org>). I've checked it out a few years ago and it felt good - stable, complete, easy to use etc.

</comment><comment><USER40> Process per connection does not scale no matter how light weight, even with COW. kore's connection handling model is the reason apache2 mpm_prefork fell out of favor many iterations ago.

The only valid argument to avoid a single event based I/O is some sort of hard blocking I/O such as disk or non-queuing chardev.

However I'm still not biting, this is solved...and as usual the answer is somewhere in between. For example, in RIBS2 there are two models for connection handling, event loops for connections and "ribbons" for the non- queuing bits [1]. RIBS2 is also written in C for C.

[1] [https://github.com/Adaptv/ribs2/blob/master/README](https://github.com/Adaptv/ribs2/blob/master/README)

Edit - mention RIBS2 is also written in C

<comment><USER3> Kore does not fork per connection.

It uses per cpu worker processes which multiplex I/O over either epoll or kqueue.

<comment><USER40> A clone is a clone. The main inplementation difference between a thread and process in Linux is COW, for all intensive purposes a worker process and a fork are the same in this use case. Neither have led to scalable web servers.

<comment><USER3> Except you are basing yourself on the fact it creates a single worker process per connection. It does not.

Workers are spawned when the server is started. Each of them deals with tens of thousands of connections on its own via the listening socket they share.

This is a common technique and scales incredible well.

</comment></comment></comment></comment><comment><USER41> Good job & good luck! ;-)

</comment><comment><USER42> Kore mapped to JavaScript (NodeJS):

      var kore = require("kore");

      kore.on("request", http_request);

      function http_request(req, resp) {
        var statusCode = 200;
        resp.write("Hello world", statusCode);
      }

</comment><comment><USER43> Anyway I love this.

</comment><comment><USER44> hmm maybe put it in the kernel and use it for debugging? cant use userspace threading libraries though.

</comment><comment><USER45> this is AWESOME!

</comment><comment><USER46> You can also do that with uWSGI: [http://uwsgi.readthedocs.org/en/latest/Symcall.html](http://uwsgi.readthedocs.org/en/latest/Symcall.html)

</comment><comment><USER47> So, on one hand, it's one process per connection and ease of development of C, but on the other hand, it has execution speed of C.

Can anyone who works in web (I don't, but I'm curious) explain what kind of services is this good and bad for?

<comment><USER48> Control interfaces to embedded devices?

<comment><USER47> Thanks, that actually seems to be the perfect use-case (from my almost non- existent experience with web development).</comment></comment></comment>


Solving systems of linear equations with quantum mechanics - <AUTHOR> https://phys.org/news/2017-06-linear-equations-quantum-mechanics.html <comment><USER2> Wait, aren't linear equation systems solvable in N^3 where N is number of equations/variables? Why do they claim exponential improvement?

<comment><USER3> Exponentially better than a polynomial in N is a polynomial in log N. See the abstract of [1] for the precise complexity claim about the algorithm mentioned in the article. As good as N^3 sounds, it's still not great on enormous systems.

[1] [https://arxiv.org/abs/0811.3171](https://arxiv.org/abs/0811.3171)

<comment><USER4> It's funny you put it that way. O(N^3) sounds horrific to me. Only practical for small problems and for anything else I'd need to look for approximations instead. O(2^N) meanwhile translates in my mind to completely impracticable.

But I guess it all depends on what kind of Ns you are looking at.

<comment><USER5> I use perfect matching in go tournaments. I have tested it with 1000 players, it was less than 2 minutes -> perfectly acceptable.

<comment><USER4> One thousand cubed is one billion. Of course it depends on what the Big-O notion is hiding, but one billion 'steps' is generally okay. But if you had tested it with ten thousand players it would go from one billion to one trillion -- which we'd expect to take more than a day on the same machine. That scaling is pretty brutal. Whereas something like sorting a list with O(N log N) would only have gone from about ten thousand to about one hundred fifty thousand. In order to hit one trillion steps we'd need to be sorting a list of nearly thirty billion items.

I sometimes find myself working with ten thousand 'things', but very rarely with thirty billion.

</comment></comment></comment></comment></comment><comment><USER6> It takes 1 second to solve a 2x2 system? I don't see how any speed-up is going to make it faster than just using a regular computer.

<comment><USER7> This is more proof of concept then actual practical implementation. Its runtime would improve the current state of art. See [http://www.mit.edu/~aram/talks/10-invert-rutgers- print.pdf](http://www.mit.edu/~aram/talks/10-invert-rutgers-print.pdf)

</comment></comment><comment><USER8> forgive my ignorance but doesn't this have applications for cryptography? if so this is potentially a huge deal.

</comment><comment><USER9> Well this is cool. And it certainly increases the practical applicability of a quantum computer.</comment>