Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

1024cores

1024cores.net

Post reply on HN
Print view View original

11–19 of 19 posts

Re: 1024cores

#11

Post by dkersten »

tedunangst wrote: post #9
dkersten wrote: post #6

Earlier quoted context omitted.

I'm not quite sure what you mean, but synchronization without atomic operations is possible. An example of mutual exclusion, without any atomic operations, taken from the book " The art of multiprocessor programming "[1] is (paraphrased) as follows: Two threads, A and B, want to access some memory. Each thread has a flag. When thread A wants to access the shared memory: Set flag A Wait for flag B to become unset Acce…

That only works with coherent in order memory operations. Once you add the appropriate memory barriers, it looks a lot more "atomic".

I chose that example because its easy to understand, obviously in modern processors with out of order execution and whatnot, you would need something a lot more elaborate.

Once you add the appropriate memory barriers, it looks a lot more "atomic"

Well, they force in order memory access. That doesn't look terribly "atomic" to me, but I understand your point.

Re: 1024cores

#12

Post by JabavuAdams »

zerothehero wrote: post #10
chrisaycock wrote: post #4

The "many core" problem is this decade's C10K. I look forward to more expert discussion on scaling across massively multi-core architectures.

Is it really? Scaling today means running on more than one machine (google, facebook, twitter, etc.) That means no shared memory. He helpfully makes this distinction on his front page ("I'm mostly interested in shared-memory system, so if you are looking for information about clusters, web-farms, distributed databases and the like, it's the wrong place") According to Google's Jeff Dean, "to Google, multi-core compute…

Games, movies, multimedia, etc.

Re: 1024cores

#13

Post by hmottestad »

sgt wrote: post #5

Interesting, but seriously, take those ads off. Are you expecting to make money off of this? Even if you did, it would be pocket change at most.

I have ads on my own site, never made much off of them, not even enough to partially cover my hosting costs.

However I leave them there just as a reminder that someone is footing the bill.

If someone doesn't like ads, then they can use an ad blocker :)

Re: 1024cores

#14

Post by dvyukov »

zerothehero wrote: post #10
chrisaycock wrote: post #4

The "many core" problem is this decade's C10K. I look forward to more expert discussion on scaling across massively multi-core architectures.

Is it really? Scaling today means running on more than one machine (google, facebook, twitter, etc.) That means no shared memory. He helpfully makes this distinction on his front page ("I'm mostly interested in shared-memory system, so if you are looking for information about clusters, web-farms, distributed databases and the like, it's the wrong place") According to Google's Jeff Dean, "to Google, multi-core compute…

> Scaling today means running on more than one machine

Of course it's not. Hundreds of millions of people use just a single computer for a lot of tasks.

>you might as well drastically simplify your code by writing it "single-threaded" and running #cores copies on each machine.

It's not the worst approach. However there may be significant penalties in terms of performance and latency in some contexts. You are definitely don't want to use your approach for games and browsers. As for server software it depends on performance/latency requirements. For example, if you will use it in High-Frequency Trading marker, count you loose all your money.

Re: 1024cores

#15

Post by dvyukov »

viraptor wrote: post #2

> ..., atomic-free synchronization algorithms Actually I'm not sure if it was supposed to be funny or serious. I see the funny "everything-free" list, as well as can imagine that there is some action you can do not atomically (relative to other actions) that gives you synchronisation. Anyone?

The intention was actually something like "atomic-RMW-free", that is "costly-operation-free". It should also include expensive memory fences, and excessive sharing. I have an explanation of "atomic-free" in the Russian article, but I did not transfer it to the English page on xxx-free. Sorry for any confusion. I think I better just remove it from the main page for now.

Re: 1024cores

#16

Post by dvyukov »

hmottestad wrote: post #13
sgt wrote: post #5

Interesting, but seriously, take those ads off. Are you expecting to make money off of this? Even if you did, it would be pocket change at most.

I have ads on my own site, never made much off of them, not even enough to partially cover my hosting costs. However I leave them there just as a reminder that someone is footing the bill. If someone doesn't like ads, then they can use an ad blocker :)

I am very close to covering a first year of hosting :) As for consulting and, perhaps, paid libraries, well, first I need a good site, right?

Re: 1024cores

#17

Post by dvyukov »

codex wrote: post #7

So far, nobody has mentioned the author's C++ based race detection tool. Conceptually it is similar to Corensic's commercial product, Jinx ( http://www.corensic.com ) but practically Jinx supports more languages, doesn't require recompilation, and is most likely much faster.

It's "similar" to a lot of software out there: Intel Thread Checker, Chord, Zing, Spin, RacerX, CheckFence, Sober, Coverity Thread Analyzer, CHESS, KISS, PreFast, Prefix, FxCop. However, what you are missing is that most of these tools (and Jinx as far as I see, can't find clear description on the site, mostly vague marketing stuff) are of help to you if you are an application developer who writes in term of mutexes. While RRD is of help to you if you are implementing mutexes itself. Can you verify involved mutex algorithm down to possible memory access reorderings? I doubt.

> and is most likely much faster. Or an order of magnitude slower.

Re: 1024cores

#18

Post by Kaya »

dvyukov wrote: post #17
codex wrote: post #7

So far, nobody has mentioned the author's C++ based race detection tool. Conceptually it is similar to Corensic's commercial product, Jinx ( http://www.corensic.com ) but practically Jinx supports more languages, doesn't require recompilation, and is most likely much faster.

It's "similar" to a lot of software out there: Intel Thread Checker, Chord, Zing, Spin, RacerX, CheckFence, Sober, Coverity Thread Analyzer, CHESS, KISS, PreFast, Prefix, FxCop. However, what you are missing is that most of these tools (and Jinx as far as I see, can't find clear description on the site, mostly vague marketing stuff) are of help to you if you are an application developer who writes in term of mutexes.…

Jinx can help verify mutex implementations themselves, although the example code that ships with the product is a little more advanced (lock-free stack). Some of the underlying technology is described here: http://s3.amazonaws.com/corensic/whitepapers/DeterministicSh... and here: http://www.corensic.com/WhyYouNeedJinx/CorensicHasaUniqueTec.... Because it's a hypervisor, it can aid in verifying synchronization primitives that are a mix of userspace and kernel code.

Re: 1024cores

#19

Post by dvyukov »

Kaya wrote: post #18
dvyukov wrote: post #17

Earlier quoted context omitted.

It's "similar" to a lot of software out there: Intel Thread Checker, Chord, Zing, Spin, RacerX, CheckFence, Sober, Coverity Thread Analyzer, CHESS, KISS, PreFast, Prefix, FxCop. However, what you are missing is that most of these tools (and Jinx as far as I see, can't find clear description on the site, mostly vague marketing stuff) are of help to you if you are an application developer who writes in term of mutexes.…

Jinx can help verify mutex implementations themselves, although the example code that ships with the product is a little more advanced (lock-free stack). Some of the underlying technology is described here: http://s3.amazonaws.com/corensic/whitepapers/DeterministicSh... and here: http://www.corensic.com/WhyYouNeedJinx/CorensicHasaUniqueTec... . Because it's a hypervisor, it can aid in verifying synchronization primit…

I do not see anything about memory fences. If Jinx does not support them, then it's pretty much useless for verification of synchronization algorithms. I've implemented dozens of advanced synchronization algorithms, and I may say that it's crucial. Also, if it works on binary level (does not require re-compilation), then it also renders it useless, because on that level you lose information about order of memory accesses, memory fences, atomicity. For example, if you see plain x86 MOV instruction, what is it? non-atomic store? atomic relaxed store? atomic release store?
Post reply on HN