[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Intel: timely article
All,
First of all, thanks to Marc for his article. As we have been reminding
ourselves recently, there is a real need for what we do, fast
approaching with the advent of multi-core processors. Some of us
believe that it is best approached from the low end (Electronic
Engineers and the like), while others believe that it is best
approached from the high-level end (GUI and network programming).
Either way, we all agree that our ideas are applicable. We can take
heart from this.
The problem seems to be getting our work out there. There do seem to be
trends of people inventing something like what we do to solve these
problems. (Unknowing) imitation is the sincerest form of flattery, but
we want them to use the real deal! We need rational advocacy of the
benefits of our approach in order to attract interest and, let's be
honest, investment.
You may notice my term "what we do" above. One of the problems of our
ideas is that there is no coherent name. If I say CSP, those in the
know reply "oh the formal method?". Not all of you will agree, but I
don't believe that the formal method aspect relates very well to actual
tools like C++CSP/JCSP that we hope to get programmers using. The C++
language prevents formality from the outset; the draw is more the
process-oriented approach. Hence my preference for the term
process-oriented programming, but is fighting with communicating
process architectures and concurrency-oriented programming. A
consistent nomenclature would help more than it should (in an ideal
world).
The other issue is reaching the right people. I admit that this may be
an argument from ignorance, but I'm not convinced that ACM/IEEE is
necessarily the best avenue. A lot of things go in the world of
computing without really being much to do with the ACM. Perl, Python,
Java, .NET and almost every other language did not spring out of the
ACM community as far as I'm aware. Admittedly the latter two had
big-company backing but the former two have taken off without it.
If we really want our tools in the mainstream, (in my opinion) we need
to get it out to the big companies, not the big conferences. Marc's
suggestion of Intel is perfect. Sony and IBM back the Cell processor,
and Microsoft is another good example. Word on the street is the way
to go - get IBM devworks articles, slashdot submissions, whatever. I
realise this makes us sound more like marketers than researchers, but
what use is research that no-one is using!
That's my two-penneth anyway. I hope you will at least find it
interesting, even if you don't agree ;-)
Cheers,
Neil.
P.S. I'm not too sure which list this was sent to originally so I'm
sending it to both. I second Mario's suggestion of combining the two
lists, although I seemed to gather that java-threads may have a
different (wider?) readership than occam-com. At the very least, a
clear division of each list's purpose would be useful.
> -------- Original Message --------
> Subject: RE: Intel: timely article
> From: "Tony Gore" <Tony@xxxxxxxxxxxx>
> Date: Tue, June 27, 2006 3:36 pm
> To: "Chalmers, Kevin" <K.Chalmers@xxxxxxxxxxxx>,
> <java-threads@xxxxxxxxxx>
>
> 
> If my memory serves me correctly, some work was done in the old OMI/HORN project with Ptolemy by ACRI (now defunct) but some may also have been done by CTI. OMI/HORN, for those who are not aware of it, was a project I managed for some time at ST before I left and contributed a lot of architectural work to the Chameleon program.
>
> If you look back over history, there are many ideas that didn't make it first time around - they were not ready at the time. I think the time has come for CSP to be reborn as a programming methodology for secure and reliable programming of 21st Century networked systems - the "ubiquitous computing". Forget the OO being flawed and how wonderful CSP is. Let us reinvent it as a means of solving the current and next generation problems.
>
> AMD are readying 8 core CPUs. These CPUs tend to share memory, which the transputer didn't, but a technique used in the past with transputers was to physically share memory, but use message passing via channels to control access to the memory. This was a pragmatic means of dealing with the limited bandwidths of the time.
>
> If we get it right, the market and recognition will follow.
>
> Why not reinvent it as SNPMA - Secure Network Programming Methodologies and Architectures or reduce it to SNP if a TLA is preferred (TLA Three Lettor Acronym).
>
>
>
> Tony Gore
>
> email tony@xxxxxxxxxxxx (alternative if problems tonygore@xxxxxxxxxxxxxx)
> tel +44-1278-761001 FAX +44-1278-760006 GSM +44-7768-598570
> URL: www.aspen.uk.com
> Aspen Enterprises Limited
> Registered in England and Wales no. 3055963 Reg.Office Aspen House, Burton Row, Brent Knoll, Somerset TA9 4BW. UK
>
> From: owner-java-threads@xxxxxxxxxx [mailto:owner-java-threads@xxxxxxxxxx] On Behalf Of Chalmers, Kevin
> Sent: 27 June 2006 12:11
> To: java-threads@xxxxxxxxxx
> Subject: RE: Intel: timely article
>
>
>
> Just to add another article to the argument, anyone with access to IEEE Computer should take a look at â??The Problem with Threadsâ?? in the May 2006 issue (pages 33-42). Here is someone outside the community (as far as I can tell) developing a framework that uses â??CSP-like concurrencyâ??. They even mention the occam word, but have no references to anything done at CPA! I would say that we are doing what the industry wants; just no one knows weâ??re doing it. Getting under an IEEE or ACM umbrella may not be appealing to all, but getting into the major search databases is. The name of the framework designed is Ptolemy II and can be found at http://ptolemy.berkeley.edu/ptolemyII/ Kevin Chalmers Research Student Napier University Edinburgh
>
> From: owner-java-threads@xxxxxxxxxx [mailto:owner-java-threads@xxxxxxxxxx] On Behalf Of Tony Gore
> Sent: 27 June 2006 09:01
> To: Marc L. Smith; java-threads@xxxxxxxxxx
> Subject: RE: Intel: timely article Intel ought to be interested - AMD have possibly stolen a march on them with various recent tie-ups with companies for processor acceleration, some of whom may have some transputer heritage. I would consider taking a totally different approach to how to push CSP, and the most recent exchanges give the reason. The next big EC R&D program will concentrate a lot of money into the area of trust, security, reliability, dependability. Things such as grid computing will evolve to computing as a service. CSP offers a means to develop software that is side effect free - just what you need for software that is going to be reliable and secure. Most of the exploits we see daily exploit side effects e.g. buffer overflows. FYI - I spent several weeks writing up some of the background workshops on this area for the EC, and I believe that there is plenty of fudning in there for the CSP community to put forward the methodology and do lots of development. Over 4 years, there will be around â?¬4billion for this area I may be putting together a project proposal for this area, so if anyone is interested, please let me know.
>
> Tony Gore
>
> email tony@xxxxxxxxxxxx (alternative if problems tonygore@xxxxxxxxxxxxxx)
> tel +44-1278-761001 FAX +44-1278-760006 GSM +44-7768-598570
> URL: www.aspen.uk.com
> Aspen Enterprises Limited
> Registered in England and Wales no. 3055963 Reg.Office Aspen House, Burton Row, Brent Knoll, Somerset TA9 4BW. UK
> From: owner-java-threads@xxxxxxxxxx [mailto:owner-java-threads@xxxxxxxxxx] On Behalf Of Marc L. Smith
> Sent: 26 June 2006 22:41
> To: java-threads@xxxxxxxxxx
> Subject: Intel: timely article Hi everyone,
>
> Here is a link to an eWeek article that just came out last week:
> http://www.eweek.com/print_article2/0,1217,a=181026,00.asp
>
> The title is: Tera-scale Computing: Intel's Attack of the Cores
>
> I encourage everyone to read the article, but to get to the point:
>
> Here is one excerpt: Nor will it be successful without getting software developers, many of whom are just now starting to tackle the move from single-thread applications to multi-threaded applications, on board, Intel executives said. "Every time you increase the number of threads, you're putting greater burden on the programmers to write the applications â?¦ to actually harness all that available parallelism," Rattner said.
> Question:
> Have we ever attempted to attract the attention of Intel? They *must* be aware of CSP! If Intel has spurned WoTUG's advances in the past, perhaps it's time to court them, again? We should invite an Intel exec/engineer to give a keynote at CPA, just before or just after another keynote extolling the benefits and virtues of process-oriented software design on multicore architectures. :-)
>
> It appears Intel, for its part, is reaching looking for partners to reach out to. Here's another excerpt: But programming for Tera-scale chips will require a completely different approach that uses lots of different threads simultaneously. That's a concept only a few programmers are currently familiar with, Pawlowski said.
> It is clear Intel is acutely aware of the problem, and need to educate the programming masses. Okay, last excerpt: So Intel is getting to work. In some cases, the company is working directly with large software makers. Elsewhere, its Software Products Group is offering tools to assist programmers with multithreading, said James Reinders, director of marketing and business development for the group's Developer Products Division, also in Hillsboro. The tools, including compilers, performance libraries, tuners and thread checkers, aim to address such challenges as scalabilityâ??how to make an application run faster on more than one coreâ??correctness, or eliminating bugs, as well as ease of development.
> We should focus our efforts to make contact with Intel's Software Products Group, and invite Intel to work with Academia as well as software companies. This is a crucial time, if it's not already too late, to get the endorsement of one of the world's most influential semiconductor manufacturers. Isn't this a golden opportunity for FDR, for example?
>
> I'm at a loss for where to begin, but I'd like to invite some open discussion regarding what I believe is a time-limited opportunity. Please share your thoughts.
>
> Sincerely,
> Marc
> This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender.
> It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss
> or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the
> University's system is subject to routine monitoring and filtering by the University.