Larrabee delayed: anyone know what's happening?
|
Prev: PEEEEEEP
Next: Texture units as a general function
From: kenney on 28 Dec 2009 05:30 In article <hh5eh2$4f7$1(a)smaug.linux.pwf.cam.ac.uk>, nmm1(a)cam.ac.uk () wrote: > To get there, we need radical changes in the > language architectures, so that they don't rely on separate bytes > being independent. The basic data type in Forth is the cell. In ANSI Forth the size is implementation dependent so programmers are not encouraged to make any assumption about cell size. Size is usually 16 or 32 bit by the way. Forth would need the char definition changed though but modern implementations are changing to unicode anyway. Ken Young
From: nmm1 on 28 Dec 2009 06:32 In article <F6adneaxoY8qFaXWnZ2dnUVZ8tmdnZ2d(a)giganews.com>, <kenney(a)cix.compulink.co.uk> wrote: > >> To get there, we need radical changes in the >> language architectures, so that they don't rely on separate bytes >> being independent. > > The basic data type in Forth is the cell. In ANSI Forth the size is >implementation dependent so programmers are not encouraged to make any >assumption about cell size. Size is usually 16 or 32 bit by the way. >Forth would need the char definition changed though but modern >implementations are changing to unicode anyway. Fortran was there first :-) That doesn't help significantly. For the real benefit, you need to be able to ensure that objects that are accessed in separate threads can be separated by the implementation to any degree that it needs. That's a problem. Regards, Nick Maclaren.
From: nmm1 on 28 Dec 2009 06:51 In article <7urk07-f7n.ln1(a)ntp.tmsw.no>, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: >Carlie Coats wrote: >> As one of those Fortran programmers, I think my biggest problem >> is trying to deal with external data formats designed by idiots. >> For an extreme example, have a look at the official World Meteorology >> Association standard for data interchange, GRIB. A readable starting >> point would be <http://dss.ucar.edu/docs/formats/grib/gribdoc/>. >> It has the most evil misalignment I've seen. > >The 'most evil'? > >For a really evil data format take a look at the CABAC part of h264. >> >> I have no influence here (USA) to get this changed. It is such a >> sacred cow that it is hard even to get it recognized as evil by the >> general meteorogy community here. Maybe you have more influence >> in the UK, Nick? > >Is this ever performance-critical? It can be. But I have never seen it affect (parallel) scalability. It wasn't the issue I was referring to, anyway, though it does affect that a little by obstructing language improvements. What I was referring to primarily was the way in which arbitrary subsets of a single composite object become composite objects in their own right, and the code that accesses them can't tell that. This can be array subsections, substrings, pointers to elements or whatever. That means that the compiled code HAS to handle the case when two separate objects updated in two threads are in the same memory unit (whether that be a word, cache line or page). Fortran could solve that by restricting parallel procedures to ones with explicit interfaces, INTENT(IN) or INTENT(OUT) arguments, no TARGET or VOLATILE ones, read-only modules, etc. As I say, I doubt that Fortran programmers would accept that. But it WOULD allow an architecture where coherence was a cache-line or page property and not a byte, word or whatever one. In this context at least, C, C++ and Java are beyond hope. Functional languages have no problem, and ones like Python wouldn't need many restrictions for parallel use. Regards, Nick Maclaren.
From: nmm1 on 28 Dec 2009 07:19 >Fortran could solve that by restricting parallel procedures to ones >with explicit interfaces, INTENT(IN) or INTENT(OUT) arguments, no My mistake. Any explicit INTENT (including INOUT) would do. Regards, Nick Maclaren.
From: Carlie Coats on 28 Dec 2009 08:12
nmm1(a)cam.ac.uk wrote:[snip...] > What I was referring to primarily was the way in which arbitrary > subsets of a single composite object become composite objects in > their own right, and the code that accesses them can't tell that... > > Fortran could solve that by restricting parallel procedures to ones > with explicit interfaces, INTENT(IN) or INTENT(OUT) arguments, no > TARGET or VOLATILE ones, read-only modules, etc. Given your next-message inclusion of INTENT(INOUT), I can live with that. The style of Fortran that seems to be taught in meteorology departments probably could not. -- Carlie |