... And then you *learn* and don't puke up the next time. Allowing users to lock modes would mean that a lot of people would never find out what's interesting and new about the system. You might end up with a horrible mess once, but then you can look at what you did wrong.
This is why we have terms like 'space opera' - for stories that aren't *about* the science. You could just as easily set the base frame for stories like Star Wars and Babylon 5 anywhere, but they just happen to be in a setting where space travel and building in space is manageable tech. These stories are much more about people and what they do than about the consequences of technological advance or societal change over time.
Anybody who tries to change this, should be shown the door.
Will, but possibly not should.
<quote>You "C" beanies will need C/OPENMPI/OPENMP/TAU to just even try to match Fortran2008's power. Intel knows this, this is why all their parallel libraries, codes and tools are geared for Fortran and NOT C. Live with it...</quote>
Last time I looked, MKL and the Intel compiler were much more focused towards C. Maybe you're thinking of IBM?
As far as I'm aware, those larger systems are ccNUMA -- cache-coherent non-uniform memory access, in which processors have local memory, but can also access other processors' memory via a network layer. It doesn't quite support the same kind of scaling as proper, uniform access shared memory.
My experience agrees with yours -- scientific parallel computing seems to be a lot like a battle between the scientists, who want to write quick, sloppy, easy code that just runs, and the parallel computing people who want them to write better code that will run with greater efficiency and in less time.
When the project was put to IBM, Cray and Sun to design these new languages (Sun's Fortress didn't make the cut), one of the specifications was that they should have parallelism not as a quite hard to use bolt-on, like MPI, but that the parallelism should be intrinsic, built-in, and transparent where possible. (As far as I recall.)
I really like the UPC and Coarray Fortran models, which give parallel features that -look- intrinsic: UPC looks like C but with shared type variables (eg. shared int shared_array[4]). The PGAS model works well for this sort of thing, and doesn't scale too badly if you know enough to work out roughly how it works. Fortunately, IBM have picked up UPC and look to be interested in implementing a native compiler for it (alphaWorks has a shared memory parallel version) as well as the Berkeley UPC source-to-source compiler, and a couple of people are implementing Coarray Fortran modules for Fortran compilers.
There are some good people working on these new parallel methods -- and working on bringing them at least part-way to the programmers, rather than making the programmers come to them.
Er, what do you mean by that? Most good apps now keep a thread just for the interface, and new GUIs ship the compositing out to the graphics card, which contains vector processors to perform data parallel operations.
That's at least three levels of parallelism, as I see it.
The Intel compiler can actually use similar code to the SSE vectorisation module to automatically parallise some constructs for OpenMP shared memory parallelism. Similarly, the newer FORTRAN standards contain constructs which are designed such that they can be automatically parallised.
If you can write either your compiler or your language in such a way that parallel regions can be inferred rather than explicitly specified, you get more performance for very little end-programmer effort.
It is very hard for me to discount all religion and mysticism throughout history just because a modern-day scientist lacks the tools to measure it.
It's very easy for me to discount the theories of the four/five classical elements, or phlogiston, but that's because I haven't been educated stupid.
Show some evidence even for an effect in the brain which can't possibly be accounted for by everything we currently understand about it, and people might be more willing to believe your ludicrous claims.
Algorithms for compressing audio and/or encoding it for transmission? You have to test them for quality before you can even think about using them for broadcast...
Because you get what you pay for hardware-wise?
Next-day and on-site service are very well, but I'd rather actually have a machine that doesn't need replacing every day.
Why stop there? Have an animated version of him running at you wielding the chair over his head and flinging it towards the screen, followed by a smashed glass and shaking effect.
That'll probably come built into the Contacts app or whatever - the basic apps that come with the phone. It's only third party app developers who are affected by this.
Reactionary much?
You could remove over 9/10s of the human population and still have a wealth of genetic diversity, orders of magnitude more than required to maintain a stable breeding pool. There are an awful lot of humans.
... And then you *learn* and don't puke up the next time. Allowing users to lock modes would mean that a lot of people would never find out what's interesting and new about the system. You might end up with a horrible mess once, but then you can look at what you did wrong.
This is why we have terms like 'space opera' - for stories that aren't *about* the science. You could just as easily set the base frame for stories like Star Wars and Babylon 5 anywhere, but they just happen to be in a setting where space travel and building in space is manageable tech. These stories are much more about people and what they do than about the consequences of technological advance or societal change over time.
And perhaps more importantly, is the entire effect countered by wearing tinted glasses?
Sometimes working here feels like banging rocks together. I'm a knapper.
Any derivative does also have to be GPL-ed, though, doesn't it?
But other threads can do processing on the CPU while that's taking place.
Anybody who tries to change this, should be shown the door.
Will, but possibly not should.
<quote>You "C" beanies will need C/OPENMPI/OPENMP/TAU to just even try to match Fortran2008's power. Intel knows this, this is why all their parallel libraries, codes and tools are geared for Fortran and NOT C. Live with it...</quote>
Last time I looked, MKL and the Intel compiler were much more focused towards C. Maybe you're thinking of IBM?
As far as I'm aware, those larger systems are ccNUMA -- cache-coherent non-uniform memory access, in which processors have local memory, but can also access other processors' memory via a network layer. It doesn't quite support the same kind of scaling as proper, uniform access shared memory.
And you have to love a language where you can in all seriousness say "And now we must initiate... The Ravenscar Profile."
Not to sound like a fanboy, but <3 OpenMP.
(Though it's not exactly using pthreads directly, even though the majority of implementations are built on pthreads.)
My experience agrees with yours -- scientific parallel computing seems to be a lot like a battle between the scientists, who want to write quick, sloppy, easy code that just runs, and the parallel computing people who want them to write better code that will run with greater efficiency and in less time.
When the project was put to IBM, Cray and Sun to design these new languages (Sun's Fortress didn't make the cut), one of the specifications was that they should have parallelism not as a quite hard to use bolt-on, like MPI, but that the parallelism should be intrinsic, built-in, and transparent where possible. (As far as I recall.)
I really like the UPC and Coarray Fortran models, which give parallel features that -look- intrinsic: UPC looks like C but with shared type variables (eg. shared int shared_array[4]). The PGAS model works well for this sort of thing, and doesn't scale too badly if you know enough to work out roughly how it works. Fortunately, IBM have picked up UPC and look to be interested in implementing a native compiler for it (alphaWorks has a shared memory parallel version) as well as the Berkeley UPC source-to-source compiler, and a couple of people are implementing Coarray Fortran modules for Fortran compilers.
There are some good people working on these new parallel methods -- and working on bringing them at least part-way to the programmers, rather than making the programmers come to them.
Er, what do you mean by that? Most good apps now keep a thread just for the interface, and new GUIs ship the compositing out to the graphics card, which contains vector processors to perform data parallel operations.
That's at least three levels of parallelism, as I see it.
The Intel compiler can actually use similar code to the SSE vectorisation module to automatically parallise some constructs for OpenMP shared memory parallelism. Similarly, the newer FORTRAN standards contain constructs which are designed such that they can be automatically parallised.
If you can write either your compiler or your language in such a way that parallel regions can be inferred rather than explicitly specified, you get more performance for very little end-programmer effort.
Call me when it writes to the editors of the journal, accusing its creators of plagiarising its work.
It's very easy for me to discount the theories of the four/five classical elements, or phlogiston, but that's because I haven't been educated stupid.
Show some evidence even for an effect in the brain which can't possibly be accounted for by everything we currently understand about it, and people might be more willing to believe your ludicrous claims.
Algorithms for compressing audio and/or encoding it for transmission? You have to test them for quality before you can even think about using them for broadcast...
Because you get what you pay for hardware-wise? Next-day and on-site service are very well, but I'd rather actually have a machine that doesn't need replacing every day.
I believe drilling is the more common approach.
Do you have a source for that?
Why stop there? Have an animated version of him running at you wielding the chair over his head and flinging it towards the screen, followed by a smashed glass and shaking effect.
That'll probably come built into the Contacts app or whatever - the basic apps that come with the phone. It's only third party app developers who are affected by this.
As soon as you have the capacity, people will fill the capacity. There's always more data to collect.
Reactionary much? You could remove over 9/10s of the human population and still have a wealth of genetic diversity, orders of magnitude more than required to maintain a stable breeding pool. There are an awful lot of humans.
AFAIK, this is standard practise in UK schools and universities.
Of course, this is exactly what you'd say if you were a member of the NSA, and the NSA had broken AES...