Mark Roulo (nothanks.delete@this.xxx.com) on July 13, 2015 5:00 pm wrote:
> dmcq (dmcq.delete@this.fano.co.uk) on July 13, 2015 3:24 pm wrote:
> > sylt (no.delete@this.thanks.com) on July 13, 2015 2:19 pm wrote:
> > > In any case, my experience with building low end, and very simple processors supports Linus point of
> > > view that as the complexity and sophistication of the system increases the drive for stricter and simpler
> > > to reason about rules also increases. I have not worked directly on memory ordering issues but for
> > > similar issues where it was deemed easiest for the HW to punt the problem to software for simple designs
> > > it soon became clear that defining simple intuitive rules and obeying them in HW gave the best over
> > > all trade off of performance, complexity and ease of design as the system evolved.
> >
> > I fully agree with simpler and stricter - at the correct
> > level. Assembler and machine code is not that level.
> >
> > > Sure, sometimes it feels rotten when some "unnecessary niceties" pops up in the critical paths but
> > > after a few generations you are doing much more complicated things anyway for pure performance reasons
> > > and the "unnecessary niceties" are a side show. After seeing this play out a few times I find it hard
> > > to not go with strict and easy. This is especially true for us since we deliver inhouse and want to
> > > optimize the productivity of HW, compiler and firmware teams combined. It's no good shipping some
> > > blazing fast HW if you have no firmware because nobody can figure out how to program it.
> >
> > Strict and easy is very good for high level languages.
>
> Can you provide some examples of the sort of high level languages you have in mind?

Well I'm sure you're quite well aware of a number of languages to deal with concurrency that have been devised in the past, but I think we'll need to have the additions in C11 and C++11 implemented well to get widespread acceptance of the idea of properly telling the language what is intended. They tend to be more procedural rather than declarative so it isn't ideal, hopefully extra annotations will be added to make them able to do something more like SQL does than the old network databases. Anyway here's a nice set of slides which I think shows the current state of the art as far as C and concurrency is concerned - and also why we need a bit of compiler support in writing such programs rather than knowing all about the hardware:

http://llvm.org/devmtg/2015-04/slides/CConcurrency_EuroLLVM2015.pdf