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

Discipline Doesn’t Scale

sicpers.info

Post reply on HN
Print view View original

161–170 of 173 posts

Re: Discipline Doesn’t Scale

#161

Post by rusk »

orf wrote: post #160
rusk wrote: post #143

Earlier quoted context omitted.

> not performance This is NOT true. There is almost always an expectation that your application have a reasonable performance profile. It's often not a captured requirement, but I guarantee you once things slow to a crawl you WILL get an escalation. Do you know what happens when escalations become too frequent? Progress grinds to a halt as developers have to churn out of what they're doing to address non-functional i…

The problem with your statement is that it was unbounded. What you are saying is “when your performance is bad, features should take a back seat”. That i agree with. But “reasonable performance” is relative and context dependent

No, I was presenting my experience that when given a choice of features over “quality” (however you choose to quantify it) we almost always see a push for the former. Unless of course you have a robust communications arrangement with your techies.

Re: Discipline Doesn’t Scale

#162

Post by Animats »

scott_s wrote: post #140
Animats wrote: post #34

Earlier quoted context omitted.

"What locks it" can include "owned by different threads". That's a lock at a higher level, really. "Lock free" data structures are tied very closely to the data being locked, and depend heavily on certain CPU operations being atomic. This is more of an issue with ARM than with x86, because ARM needs more fence instructions. Really, "lock free" programming is just locking critical sections with lower level hardware pr…

> Really, "lock free" programming is just locking critical sections with lower level hardware primitives. I have to disagree, as the more interesting lock free algorithms use atomic operations that can fail . Yes, a compare-and-swap is like having a critical section on modifying that particular address. But a compare-and-swap can fail if what is currently there is unexpected. The result of that failure generally mean…

compare-and-swap

Compare and swap is interesting. It's a tiny transaction. It can even operate across networks - FireWire had hardware compare and swap support. Compare and swap with retry may have to wait and retry, which is effectively waiting for someone else to stop using a resource you want. So it's a form of a critical section lock.

Re: Discipline Doesn’t Scale

#163

Post by arthev »

AnimalMuppet wrote: post #154
arthev wrote: post #128

Earlier quoted context omitted.

"The encouraging thing today is that we're kind of converging on good practices in language design." - doubtful that we'll arrive at good practices in language design through incremental steps from a flawed base. All the mentioned languages are low-level.

Therefore... what? Just give up? Or start over from a non-flawed base? Which is what? Still to be created, or does it exist? And in your view, are the bases flawed because they are low level?

"Therefore... what? Just give up? Or start over from a non-flawed base?" - those would both be ways to avoid the presumed local optima, yes.

"Which is what? Still to be created, or does it exist?" - several different 'initial stakes'/bases in the space of programming languages exist/were made/can be created than the family of languages mentioned in OP. Exploration from those might yield better optima. The widespread adoption of the current industry 'standard' languages seems an accident of history, not guided by quality of language.

"Are the bases flawed because they are low level?" - yes. A significant part of the computing field is about abstractions. Improving the level of the technology is one of the arguments the article here makes too. Besides, it's the implicit admission of everyone who doesn't advocate/write assembly.

Re: Discipline Doesn’t Scale

#164

Post by yencabulator »

scott_s wrote: post #140
Animats wrote: post #34

Earlier quoted context omitted.

"What locks it" can include "owned by different threads". That's a lock at a higher level, really. "Lock free" data structures are tied very closely to the data being locked, and depend heavily on certain CPU operations being atomic. This is more of an issue with ARM than with x86, because ARM needs more fence instructions. Really, "lock free" programming is just locking critical sections with lower level hardware pr…

> Really, "lock free" programming is just locking critical sections with lower level hardware primitives. I have to disagree, as the more interesting lock free algorithms use atomic operations that can fail . Yes, a compare-and-swap is like having a critical section on modifying that particular address. But a compare-and-swap can fail if what is currently there is unexpected. The result of that failure generally mean…

Optimistic locking is still locking. The low level compare-and-swap operation still uses CPU cacheline-level locking. https://en.wikipedia.org/wiki/MESI_protocol

Re: Discipline Doesn’t Scale

#165

Post by einpoklum »

oblio wrote: post #110
trumpeta wrote: post #108

Earlier quoted context omitted.

I’d argue it doesn’t make sense to fix c++. A language is not about what you can do with it, its about what it doesn't let you do. C++ will continue letting you do everything in the name of backward compatibility.

At some point, that's going to stop being sustainable. I think C++ could really use what Rust calls generations. Figure out the obviously bad ideas and deprecated them over 10 year cycles. That would allow the language to shrink again, I don't think it ever did.

Actually, that point has already come: There is insistence on maintaining ABI compatibility with increasing versions (as opposed to source-level compatibility), which prevents various potential improvements.

Regardless - C++ will effectively has some deprecation, at least of the standard library, with the introduction of modules instead of included headers in C++20.

Re: Discipline Doesn’t Scale

#166

Post by einpoklum »

dvdkhlng wrote: post #151
einpoklum wrote: post #77

Earlier quoted context omitted.

Everybody and their uncle have an idea about how they would "fix C++" - but these ideas mostly contradict each other and would make for rather different languages :-)

Uh, you're too optimistic: Everybody and their uncle had a lot of ideas about how they would fix "C++". Eventually all those contradicting ideas got merged into the C++ standard. :)

No no, almost nothing gets merged into the standard if it breaks anything, and to "fix" the language you definitely have to break it...

Re: Discipline Doesn’t Scale

#167

Post by heavenlyblue »

bartvk wrote: post #117
Chris_Newton wrote: post #111

Earlier quoted context omitted.

The compiler needs that information for checking, and the programmer, and the maintenance programmers who follow behind, need that information so they know how to call the thing. On the other hand, you can usually infer the result types of expressions by a simple forward process. Possibly unpopular opinion: I am wary of relying on type inference for return types, other than for a function defined locally where you ca…

In practice, type inference for return types works fine for the work I do (iOS development). Initializers are blindingly obvious anyway, and other functions are often members of an object or a struct. There are barely any bare functions.

Can’t members return other objects?

Re: Discipline Doesn’t Scale

#168

Post by heavenlyblue »

fjfaase wrote: post #52

One of the most important reasons why we write programs, is because computers are slow and have limited memory. Computers only appear fast due to a host of tricks. The most important trick is the memory pyramid: with at the top a small number of very fast accessible memory (think CPU registers) and at the bottom a very fast but many orders of slower accessible memory (think the whole of the internet). And a lot of bu…

What makes a double-linked list better?

Re: Discipline Doesn’t Scale

#169

Post by scott_s »

yencabulator wrote: post #164
scott_s wrote: post #140

Earlier quoted context omitted.

> Really, "lock free" programming is just locking critical sections with lower level hardware primitives. I have to disagree, as the more interesting lock free algorithms use atomic operations that can fail . Yes, a compare-and-swap is like having a critical section on modifying that particular address. But a compare-and-swap can fail if what is currently there is unexpected. The result of that failure generally mean…

Optimistic locking is still locking. The low level compare-and-swap operation still uses CPU cacheline-level locking. https://en.wikipedia.org/wiki/MESI_protocol

What's important is that you no longer have a critical section, where mutual exclusion is enforced. The only piece of code that has mutual exclusion is an attempt to commit the transaction. The kind of thinking required to implement such algorithms is quite different than when you can rely on mutual exclusion.

(Also, not all architecture use hardware mechanisms to enforce actual mutual exclusion. For example, Power does not, as it uses load-linked, stored-conditional: https://en.wikipedia.org/wiki/Load-link/store-conditional. On Power, even things like atomic increments are implemented with LL/SC. Architectures basically have to decide: will they implement atomics through some kind of a lock mechanism, or some kind of LL/SC mechanism.)

Re: Discipline Doesn’t Scale

#170

Post by yencabulator »

scott_s wrote: post #169
yencabulator wrote: post #164

Earlier quoted context omitted.

Optimistic locking is still locking. The low level compare-and-swap operation still uses CPU cacheline-level locking. https://en.wikipedia.org/wiki/MESI_protocol

What's important is that you no longer have a critical section , where mutual exclusion is enforced. The only piece of code that has mutual exclusion is an attempt to commit the transaction. The kind of thinking required to implement such algorithms is quite different than when you can rely on mutual exclusion. (Also, not all architecture use hardware mechanisms to enforce actual mutual exclusion. For example, Power…

You still have a critical section; the cacheline is in an exclusive mode during the change. LL/SC operates on top the cache sharing protocols, just like everything else. Your wikipedia link even refers to that: "Typically, CPUs track the load-linked address at a cache-line or other granularity [...]". MESI and friends are that mechanism.

What lock-free means in this case is that an OS level thread freezing doesn't prevent global progress. That's true on the abstraction level of typical programming, but grandparent is very much correct:

> Really, "lock free" programming is just locking critical sections with lower level hardware primitives.

Post reply on HN