http://www.mapleprimes.com/posts/36217-Fran-Allen-Lecture en-us 2026 Maplesoft, A Division of Waterloo Maple Inc. Maplesoft Document System Wed, 10 Jun 2026 17:38:43 GMT Wed, 10 Jun 2026 17:38:43 GMT The latest comments added to the Post, Fran Allen Lecture http://www.mapleprimes.com/images/mapleprimeswhite.jpg http://www.mapleprimes.com/posts/36217-Fran-Allen-Lecture http://www.mapleprimes.com/posts/36217-Fran-Allen-Lecture?ref=Feed:MaplePrimes:Fran Allen Lecture:Comments#comment61239 Thanks for the interesting post. I have a few random thoughts: On lack of caches, this is basically a GPU. Makes a lot of sense for intensive branch free computations, e.g. linear algebra, simulations, plotting, signal processing. Basically dense computations requiring high throughput. It uses die area for arithmetic units instead of cache. For general purpose computing however, caches are never going away. Branches = caches. What you can expect to see is more of the following: <a href="http://arstechnica.com/hardware/news/2009/11/amd-bobcat-bulldozer.ars">shared resources</a> across multiple execution cores. We're going to get *a lot* of cores. Thousands. But the caches will be shared, so high performance design will become even more important. The decode and L1 instruction caches on Bulldozer are shared. That means you want to run the same program on each core if at all possible. As for smart compilers, I think this is basically wrong. Smart compilers have never really worked. They were supposed to make RISC more efficient. They were also supposed to make functional languages faster than C. I think people underestimate compilers' ability to choose good instructions, and massively overestimate their ability to make a good program. You can not automate design. I think the future does not belong to any one solution. I think you'll see old low level techniques dusted off and used for fine grained parallelization of operations. Programmer tools, like the task model, will be used to parallelize non-uniform algorithms. And high level languages like Maple will wield this power automatically, driven by everything underneath. Nobody wants to write parallel software. The future is automatic. The latest comments added to the Post, Fran Allen Lecture 61239 Sat, 05 Dec 2009 00:53:57 Z roman_pearce roman_pearce http://www.mapleprimes.com/posts/36217-Fran-Allen-Lecture?ref=Feed:MaplePrimes:Fran Allen Lecture:Comments#comment61240 <p>If I get to vote, my preference would be for Maple to fix the problems with the multi-threaded code and to get good support for compiled CUDA (or whatever) programs for those of us with GPU's.&nbsp; Since a lot of what I do is linear algebra (double precision numerics) being to offload matrix multiplies and the construction of big matrices to the GPU would be a **big** win.&nbsp; Obviously, being compiler and linker averse (not incapable -- just averse) being able to compile Maple code to CUDA code (even if I have to be careful about writing the code as I do now with Compiler:-Compile() ) and then run it from Maple (using define_external) would be heaven.&nbsp;</p> <p>I know having a wonderful general solution for adding high-level language support would be great; however, getting this basic level of support into the next beta would solve a lot of my problems right away.</p> The latest comments added to the Post, Fran Allen Lecture 61240 Mon, 07 Dec 2009 05:53:45 Z marvin marvin http://www.mapleprimes.com/posts/36217-Fran-Allen-Lecture?ref=Feed:MaplePrimes:Fran Allen Lecture:Comments#comment61241 <p>I completely agree with Allen on the future of DSLs, and how the higher-level they are, the easier it is to optimize them tons.&nbsp; [Disagreeing with a Turing award winner is usually foolhardy and requires a lot of proof, else it's hardly credible].</p> <p>Anyways, I've actually been working on this quite intensively for the past few years, and I'm totally convinced it works.&nbsp; The main problem is that few programmers have any real clue what 'high level' really means!&nbsp; In the Maple world, there is an easy example: a MapleSim diagram is sufficiently high-level.&nbsp; Anything lower-level than that contains too many 'operational' details.&nbsp; I guess another example would be the rubber-band model of placement for Maplets.&nbsp; Properly written LaTeX would also qualify as reasonably high-level, but few people ever write 'proper' LaTeX, mostly because few people really understand Model-View-Controller well enough to understand how to separate model and view.&nbsp; At least the web people eventually got it right (a proper web page uses CSS for the view aspects and XML for the model).&nbsp; While the syntax of CSS is not great, it is conceptually a really good DSL for what it does.</p> <p>The point about being able to do program analysis is also quite non-trivial: to be able to do that requires really and clear solid semantics for the language.&nbsp; Unfortunately, for Maple (see my ex-student Stephen Forrest's work on the topic), it's just too bloody hard.&nbsp; Maple's programming language has a very messy operational semantics, which means that it's extremely hard to analyze with any degree of precision. </p> The latest comments added to the Post, Fran Allen Lecture 61241 Tue, 08 Dec 2009 05:52:40 Z JacquesC JacquesC