Next Generation of Language
in [Lisp]
|
Prev: a potential lisp convert, and interpreting the shootout
Next: ANN: ABLE 0.1, A Basic Lisp Editor
From: Kirk Sluder on 9 Jan 2007 09:10 In article <1168334857.190727.297040(a)i15g2000cwa.googlegroups.com>, "Tim Bradshaw" <tfb+google(a)tfeb.org> wrote: > I don't doubt that multicore processors will make it into desktops in a > big way. But they will make it into desktops for reasons which are not > what you might think, and in particular are substantially not due to > the computational demands of desktop applications. Well, just speaking as an Mac user, the benefits of multi-core CPUs for desktop applications beyond simulating ecosystems has been noted by consumers. In addition to consumer/professional applications that are designed for multiple processors (such as photoshop) doing just about anything in a modern operating system involves multiple threads competing for CPU time. If anything is true about computing it's that users find ways to (occasionally) soak up any available power in their price range. One of the areas where I'm seeing consumer growth/interest is multimedia development. So "desktop application" is expanding to include video authoring and DVD mastering. Five years ago these were applications where I used to put a sign on a computer saying, "compressing--don't touch" overnight. I will agree that price and heat considerations are nice bonuses. But most consumers are not that interested in heat provided that they don't get burns from their laptop. They do pay attention to benchmarks such as MSWord scrolling, photoshop filter application or zip file creation.
From: Kirk Sluder on 9 Jan 2007 09:13 In article <1168345148.098241.181670(a)i15g2000cwa.googlegroups.com>, "Tim Bradshaw" <tfb+google(a)tfeb.org> wrote: > - it's what the CPU vendors will have to sell: they won't want to spend > huge amounts of money developing entirely different desktop and server > processors (I'm not sure if this argument holds water). The high-performance processors are already moving to quad core. None of the chip makers appear to have much interest in simplifying the market in that way.
From: Marc Battyani on 9 Jan 2007 09:42 "Ben" <benbelly(a)gmail.com> wrote > > BTW: Has anyone done any hard real time work using Lisp? How'd it go? Real time robot driving + Data acquisition + 3D display (OpenGL) in Lisp. http://www.fractalconcept.com/asp/lhw3sdataQuxi9oMj8B== The very hard real time (ns scale) is done in VHDL in a FPGA and everything else in Lisp. (Lispworks) Marc
From: Kjetil Svalastog Matheussen on 9 Jan 2007 09:46 On Mon, 8 Jan 2007, Ben wrote: > > BTW: Has anyone done any hard real time work using Lisp? How'd it go? > Well, sort of: http://www.notam02.no/arkiv/doc/snd-rt/ And by "Well, sort of", I mean that its definitely hard real time, but perhaps not lisp, because its not consing. However, consing is definitely possible, and even garbage collecting is possible (if it had been implemented). I am however not sure how useful hard-core consing would be for this kind of work.
From: Marc Battyani on 9 Jan 2007 09:47
"Tim Bradshaw" <tfb+google(a)tfeb.org> wrote > > I suspect it will top out long before that. It's amazing (really, it > is a deeply spectacular feat of engineering) what can be got over a > phone line, but there are limits. More to the point latency is not > something you can make vanish. [...] > Sorry, they will. The memory wall is emphatically not going away. It's even going worse as the bandwidth increases. Just look at the DDR3 and FBDIMM. The memory access latency is already the limiting factor in most cases. (excepted for LINPACK and this kind of benchmarks) For HPC applications, let's switch to FPGA+QDRII+DSL written in Lisp! (DSL= Domain Specific Languages, not ADSL ;-) Marc |