skysight-inc/HackerNews huggingface dataset:
Thoughts:
- Diminishing returns in performance per core because some tasks are truly serial, not parallel.
- It costs money - putting stuff on silicon costs money. The only justification for spending more money is that you will make it in revenue.
- The PC market imploded. Lenovo has killed the laptop and PC market, and soon will be entering the server market. Expect the end of the server market in the next 5 years or so. There is a lot less money to go around.
- Moores 1st law (there are several) is hitting a wall, that is what drove the multi-core approach. They couldn't double the clock speed, so they effectively added to the clock-count.
- There is on-die architecture including routers and memory busses. They have capacity limits and tend to be the performance limiters for max temperature. They might be the limiting technology.
- Low power is important, as is low heat. More cores (aka more ALU's means more heat and higher power use.
- The more components, the easier for something to go wrong.
- Gartner says the next big money is in IoT, not massively parallel on the PC. (It seems google beat Intel to a machine-learning ASIC, and deep learning seems to be a decent market right now - but because Gartner didn't say it the Intel leadership can't hear about it).
Writing Less Code
Caches.

Xeons and the like dedicate much of their transistor budgets towards larger caches.

If you take that budget for caches and put it towards more execution units, you get the equivalent of Xeon Phi which is a lot of Pentiums built on today's fabrication processes.
Duplicated multiple times:

https://news.ycombinator.com/item?id=12300210 (12 comments)

https://news.ycombinator.com/item?id=12301815 (15 comments)
Especially true if we exclude stuff that's "not what math really is" when we lament how bad the teaching of mathematics is, like applying known formulas, gaining utility from knowing one's times tables, doing mental math with fractions or percentages, and so on.
I am the proud owner of a Xeon 12/24 3.0Ghz. It's the best one!

Some people like hot-rod cars.

I don't use a GPU like normal people do. Graphics are great for parallel execution. (Obviously)

If everybody owns a Xeon 12/24 then you can make real-time software that requires it. There's not a chance any software will be written until most people have it.
Wow, that's a really interesting case. I guess the same thing would happen whenever an offset was adjusted after you store a value in UTC intended for another timezone. I don't think this is even supported by Django - all times are converted to UTC on entry to the database.
What are the advantages over PCPartPicker?
why on earth should I log to view this content. Screw this website.
have the direct link here http://www.oreilly.com/programming/free/files/2016-european-...
Has replacing a despot in a middle eastern country ever worked out?
Clickbait titles like that don't make me want to do business with circleci , it feels like a business full of immature kids yelling at each others. Not even going to click on the link.
Using Feature Queries in CSS
It is necessarily constrained by asymptotic computational complexity. With or without the memory bottleneck implied by the Von Neumann architecture. That it is a turing machine is not merely a pedantic fact. It has both implications and relevance here. At best a different architecture would exploit more concurrency. I don't think it does though; Language processing is extremely recursive. Noam Chomsky suspects our brains have an adaptation specifically for it. Nim Chimpsky implies he's right. I suspect this adaptation has all sorts of parallels with digital turing machines.
Honestly one of the worst ShowHN submissions I've ever seen.
Yeah, we do micro services, the "real" kind. Not the "SOA with a new name kind", but the "some services are literally a few douzan lines of code and we have 100x the amount of services as we do devs" kind.

The thing is, you need a massive investment in infrastructure to make it happen. But once you do, its great. You can create and deploy a new service in a few seconds. You can rewrite any individual service to be latest and greatest in an afternoon. Different teams don't have to agree on coding standards (so you don't argue about it).

But, the infrastructure cost is really high, a big chunk of what you save in development you pay in devops, and its harder to be "eventually consistant" (eg: an upgrade of your stack across the board can take 10x longer, because there's no big push that HAS to happen for a tiny piece to get the benefits).

Monolithic apps have their advantages too, and many forget it: less devops cost, easier to refactor (especially in statically typed languages: a right click -> rename will propagate through the entire app) and while its harder to upgrade the stack, once its done, your entire stack is up to date, not just parts of it being all over. Code reuse is significantly easier, too.
What the FinTech landscape in Nigeria looks like right now
Well, how do you write that in Python?

I'm curious because these simple things that are delightfully easy in bash often turn out to be surprisingly tedious in other languages.

Of course, some things are tedious in bash too. But a basic principle of shell scripting is that you call other programs to do the stuff you don't want to do in shell.
I recall that during the interview process, they dropped off the face of the earth once I asked them about hourly rates and if they'd be able to meet my minimum.

I refused to do any coding exercises if they couldn't openly state that my requested hourly rate was within reason.

From everything I have read online, the rates are low for US based freelancers.

You're better off finding your own clients and skipping the middleman.
That's my point. Specification of the model is not (usually a problem). The other tasks are the problem.
Depends on how you choose to read it. I love microservices and all the new tools we have to scale gracefully, but I read this as satire. It's more hyperbole on how some people always seem to be over-engineering and pretending that's the conservative way to write software without considering the time-sink required to be able to dynamically scale with all of those tools.
I work with a guy like this. His knowledge base is vast (we're electrical engineers and he's a master of both hardware and software). He's also a shambling zombie from a lifetime of hacking through the night. I'm not exaggerating. He mostly just shuffles through his days, trying to get anything done, but he's just too fried. He rarely sleeps. I've never seen him eat. He won't take vacation days. He seems to have decided a long time ago to just drive himself insane. Honestly, I think if he weren't one of the guys the company can't afford to lose because he knows things about our products no one else in the building does, they'd probably let him go.
bar(foo)

When you're not writing shell, just use the tools the language gives you.

For the matter, I think a shell script is cleaner than a python script for devops; but I don't think the composability of unix tools is that much of an advantage compared to the amount of python libraries out there.
Real-time marketing
Idempotency, event sourcing and sagas with compensations are ways to solve your problem.

A shared database is an anti-pattern in distributed systems.

Similarly, distributed transactions (ala. DTC) is an anti-pattern.

Distributed systems aren't hard. They're just different.
Personally, I hate that [1]. Among many trends on the Internet the excessive use of unnecessary Unicode characters in a log that is supposed to give you an idea of the progress of a project is certainly... Well, as I said, unnecessary. I don't know who came up with this idea (was it GitHub's Atom project?) but every time I find a project on GitHub [2] I immediately start to judge the author(s) decisions and the seriousness of the project.

I understand that everyone is free to manage their project as they please, and the following statement will probably affect my career in the future, but I sincerely hope to never come across a job where my co-workers praise this... I don't even know how to call it... standard?

Very interesting project nonetheless.

[1] https://i.imgur.com/Xek7ZVV.png

[2] Haven't seen this anywhere else.
Agree, that multi-threading probably the best choice for CPU-intensive applications. But for databases or http-servers multi-process + coroutines/fibers can be a better solution. For example, Redis is few-thread application. It creates additional threads only for disk I/O, because unfortunately file descriptors in Linux/UNIX do not work in async mode.

Btw, Redis reminds me, one really awesome usage of fork. To make a snapshot of itself Redis forks the main process. After that the child simply goes through tuples and write them to a files with out any worries that somebody will modify a records. Copy-on-write mechanism simply prevents it.

Redis save snapshot code: https://github.com/antirez/redis/blob/unstable/src/rdb.c#L99...
Lots of hype but sadly very little science going on here. They have a few superficial models of hippocampal circuitry but almost nothing about how that circuit fits into the larger systems of learning and memory.

There so many major technical issues that make this little more than vapor wear.

The hippocampal neural code is largely un-understood. Without the code they'll be flipping random bits and hoping for the best (akin to flipping bits in ram without understanding how the OS is representing data in RAM).

We still don't have reliable hardware for reading the activity of the brain. Most implants go bad after a few weeks with very few lasting up to a few years. Surgery every few years is unreasonable as each implant will leave behind permanent damage.

Next writing information to the brain is still in its infancy. We can disrupt processing with electrical stimulation but too much current will trigger a seizure (especially in the hippocampus). There's a lot of hope around Opto-genetics but we still need to figure out how to get targeted expression in an already developed human brain. It can take years to get expression right in developing mice.
Math is one of those things that you'll see everywhere if you're looking for it. So its not that the mathematicians are lying, just that they have a biased perspective.
They are, but in the GPU.

GPUs handle the tasks that can be easily parallelized better than CPUs. Many supercomputers are now made from GPUs.

I have a theory that we will gradually favour business and societal forms that can be easily parallelized, i.e. on GPU.

BTW intel's growth focus is on ASICs (application-specific integrated circuits) - effectively, code pushed down to silicon. https://news.ycombinator.com/item?id=11287511 And will integrate them in future Xeons http://www.pcworld.com/article/2921832/intel-looking-to-boos...
I looked up the author's profile as a graduate student of history at Princeton.

https://history.princeton.edu/people/michael-j-barany

I'm troubled that a Princeton history student can write about a worldwide phenomenon with so little reference to non-Western cultures. (This is a pet issue of mine, as I am an American who lived in east Asia for years after studying Chinese and sinology.) I don't think he has looked at development economics and the history of popular attitudes toward economics enough to understand how important basic understanding of mathematics is. In other words, I disagree with the conclusion of his article, summed up in the last paragraph.

"Imagining math to be everywhere makes it all too easy to ignore the very real politics of who gets to be part of the mathematical elite that really count—for technology, security, and economics, for the last war and the next one. Instead, if we see that this kind of mathematics has historically been built by and for the very few, we are called to ask who gets to be part of that few and what are the responsibilities that come with their expertise. We have to recognize that elite mathematics today, while much more inclusive than it was one or five or fifty centuries ago, remains a discipline that vests special authority in those who, by virtue of gender, race, and class, are often already among our society’s most powerful. If math were really everywhere, it would already belong to everyone equally. But when it comes to accessing and supporting math, there is much work to be done. Math isn’t everywhere."
Just to see if I'm still batting a perfect game here, do you describe yourself as "Libertarian"?
They work great in some situations, like playing back an MP3. If you're working with some problem where the memory accesses are either local or predictable enough that the prefetcher can guess right than a VLIW should be able to extract just as much parallelism as an OoO core and with less power. It's when you start suffering regular cache misses and the careful choreography of your VLIW instruction stream is thrown off that they start to lose. Which is most GUI programs, classical AI, web browsers and basically most things people do on desktops and servers so it's no surprise they lost there. But there are still lots of places in embedded computing where they're ubiquitous for good reason and your phone might very well have one in it too to offload some tasks to.
They actually are doing more cores... For now, they integrated the Phi chip into a real cpu. Give it another 2-3 years then this tech will come to consumers (very likely I think).

http://www.anandtech.com/show/10553/asrock-rack-launches-2u4...

And I completely disagree with that consumers don't need many cores... That would be paramount to saying that consumers don't need GPUs. One of Intel's core arguments for bringing Phi to the masses is realtime raytracing (something for which normal GPUs suck bad). Also NVidia is working on a Phi-kind-of-thing as their next generation GPU. So we are getting there, but it was a long journey from 2006.
To be fair, most businesses in history eventually regress to market-matching through zero-sum tactics like this.
The package size for mobile chips is also shrinking (and presumably die size as well). For example the Skylake Core M package is half the size of the Broadwell Core M according to Wikipedia (die size is listed as TBD).

Aside from the size benefits for board layout, a smaller die would let them get more CPUs from a wafer while a lack of competition in the mobile x86 space lets them charge the same amount for each one.
I don't like correcting with "well, actually", however, I have to say that the author of the book "Building Microservices" in his first few chapters (in particular: Chapter 3: Premature Decomposition) warns against using microservices with new apps, especially if you are new to the domain. He claims that they are actually easier to use when you have to refactor a large monolith, and that normally you shouldn't start with microservices unless you know what you are doing - therefore my criticism towards the article which starts with a pre optimization (split one service in 12), which seems to be a common, yet arguable practice.
Which one of the four major improvements do you attribute the success to though? Could you have done the work on making it more resilient, persistence, sensible, redesign the docs without breaking into micro-services and still have seen the positive results?
you'll be waiting a very long time. The tech is decades if not centuries off
It's really not that simple.

If there are external groups trying to influence this election, they are not limited to the Russian government. They aren't even limited to governments.

Russia is just the bogeyman du jour of American news media. Many other more capable enemies are completely unreported.

The bogeyman figure is conveniently utilized to spin many stories. E.g. The DNC hack. In this case it's being used to smear Trump's campaign.

The fact is there no substantial evidence Trump is a Russian sympathizer. There is also no evidence that Russia is a Trump sympathizer.

The US has not changed its foreign policy agenda since WW2. There is beautiful continuity from Truman, to Eisenhower, to Kennedy, to Johnson, to Nixon, to Ford, to Carter, to Reagan, to HW Bush, to Clinton, to Bush, to Obama. It's highly unlikely that the next presidential election will have a noticeable effect on our policy towards Russia.
It’s a figure of speech. Math is everywhere, but not everyone have access to it. So math isn’t actually everywhere.
Jet being acquired is a win-win-win
I think when Peter Thiel talks about "secrets" in Zero to One, he's referring to truths you hold that aren't (yet) generally accepted.

> What important truth do very few people agree with you on?

> Recall the business version of our contrarian question: what valuable company is nobody building? Every correct answer is necessarily a secret: something important and unknown, something hard to do but doable. If there are many secrets left in the world, there are probably many world‐changing companies yet to be started.

The text of that chapter is on Genius: http://genius.com/Peter-thiel-zero-to-one-chapter-8-secrets-...
AMD tried and failed. Multiple cores is what the FX is all about. What's the one type of application that drives processor sales on the desktop? Right, games. What's one of many types of applications that do profit more from fewer stronger cores than from more slower ones? Right again, games.

That said, over the last 5 years processors did get beefier. They just did not got more cores. The i5-2500K (from 2011) is slower than the i5-6600K, both have 4 cores though. But if we go back 10 years, we are looking at the Core 2 Duo, those had only two cores.

And games are also changing. Not too long ago you could still play games (like Fallout 3) with a single core. New games (like Fallout 4) rely on the processor having multiple cores, some don't even start with a dual core (Hyperthreading is needed then and saves the i3). And games supporting DX12 (and probably Vulcan) work better on the FX processors than those using DX11. More cores become more useful now, and processors will have to add more of them also in the consumer desktop area soon.
They have a special instruction now to predicate the next N instructions or not. In out of order implementations you want each instruction to have as few inputs as possible and my understanding was that the implicit input in the form of the branch information was causing problems. I've heard conflicting things about whether ARM processors split predicated instructions into two ops during decode.
Honest advice: Stop working for/with stupid companies/people and start working for smart ones.
Ugh. I didn't need to be reminded of "Harrison Bergeron" before breakfast. Very poor satire, if that were the intention.
Git Workflow Basics
Fractals 101
I'm most concerned with the ethics of testing the device, which I suppose leads us to the ethics of augmenting healthy brain function. The best candidates for testing this device might not be in the best position to give informed consent. Even if they signed forms when of sound mind, there's simply no way of knowing if they would change their mind later. This means we might need to test on healthy individuals, at least until we know the risks of the device that do not relate to the disorder.

We should be thinking about ethics in our new, exciting world, but for the most part, we tend to make decisions about ethics via popular consensus. Even if some of us might be vocal about this being a bad idea (ethically, or otherwise), if the majority are seeking it out, it's still likely to happen.
Uh, that's what happens...? In Windows 2012, the new feature is actually that you can explicitly stop the OS doing that, by forcing specific processes to specific cores only.

The issue people have, usually, is about which process should have priority when (inevitably) more than one are competing for the same processor -- a question that has different answers depending on your particular type of workload.
Bathwater doesn't have morale. I worked at a semiconductor company while in school and for a bit after graduating. It's a volatile industry and layoffs are frequent. Every time anything happened, people were just concerned about layoffs. On every project, people's concern was usually protecting themselves so they wouldn't get laid off. None of them were really happy in their jobs, but they all had golden handcuffs (I'm in a small state with little high-paying tech work). I can assure you that the effects of roughly annual layoffs (similar to the throttling you describe) is one where people can never get comfortable again, and what should be a rare, isolated event, becomes the status quo. A bad status quo.
completely agree. great post!
Yeah, add in things like MORE THAN ONE PRODUCTION ENVIRONMENT and LETTING YOUR CUSTOMER HOST AN INSTANCE OF YOUR MICROSERVICES and you have guaranteed your own suffering.
Hilarious that this was downvoted, with a cowardly lack of discourse as usual.

Please, continue to assume Putin is a stereotypical cartoon villain. One would think users of a site like HN would have at least passing knowledge of Occam's Razor...
basically this is how the howto handles the hardest part:

>Basically you will run docker swarm init on the first
node and then docker swarm join on all the other nodes.
There are a few other arguments that you’ll need to add
to those commands but if you follow the docs you’ll have
no problems at all.

worse part of the setup is how to build the cluster nodes store in a way which is redundant and reliable, since provisioning it for HA is largely undocumented and left to an exercise for the reader
Except that graphics rendering is the last step of the game engine.

Computing world changes, updating model locations, handling network traffic, sampling user input, saving game state for autosaves, preloading resources from the disk for transitions, all need cpu time.
This is Cisco admitting defeat to commodity manufacturers. I wonder if there is a massive skilled worker crunch on the other side of the world from which the commodity manufacturers operate (despite the huge population).
You know nothing in the comment you're replying to indicates I wouldn't, right?
Crack the coding interview (FREE until Friday)
Yes. A lot of success. And with only one person on the backend full time.

That said, in places where it doesn't make sense we didn't try to force it. Our main game API is somewhat monolithic, but behind it we have almost 10 other services. Here's a quick breakdown:

- Turn based API service (largest, "monolithic")
- Real-time API service (about 50% the size of turn-based)
- config service (serves configuration settings to clients for game balancing)
- ad waterfall service (dynamic waterfall, no actual ads)
- push notification service
- analytics collection service (mostly a fast collector that dumps into Big Query)
- Open graph service (for rich sharing)
- push maintenance service (executes token management based on GCM/APNS feedback)
- help desk form service (simple front-end to help desk)
- service update service (monitors CI for new binaries, updates services on the fly - made easy by Go binary deployment from CI to S3)
- service ping service (monitors all service health, responds to ELB pings)
- Facebook web front-end service (just serves WebGL version of our game binary for play on Facebook)
- NATS.io for all IPC between services

...and a few more in the works. Some of these might push the line of "micro" in that they almost all do more than a single function's worth of work, but that level of granularity isn't practical.

But don't get too caught up on the "micro" part. Split services where domain lines naturally form, and don't constrain service size by arbitrary definitions. You know, right tool for the job and whatnot.
Unit Testing a NativeScript Angular 2 Android and iOS Mobile Application