RE: On the road to replacing C++
I've not tried sbcl in that capacity but it seems like it'd be considerably faster than clisp though the performance tradeoffs for scripts tend to be different. The main bottlenecks I ran into w/ clisp involved slowdowns due to lots of consuming,even when the working set was small, and relatively long load times when the image was complex (imagemagick w/ support libs). Dumping a compiled image would probably mitigate both, OTOH clisp is a big win when the requirement is to run on different architectures.
Gerry Weaver <gerryw@compvia.com> wrote:
Hi Greg,
It is interesting and timely that you should mention this. I have setup sbcl for the same purpose using its --script option. I am trying to submerge myself
in Lisp for a while and have resolved to write anything that I would normally write a shell script for in Lisp. I typically write at least one, and often two, shell scripts per week for admin purposes.
Thanks,
Gerry
From: owner-lisp-hug@lispworks.com [mailto:owner-lisp-hug@lispworks.com]
On Behalf Of Greg Menke
Sent: Sunday, February 17, 2013 6:56 PM
To: lisp-hug@lispworks.com
Subject: Re: On the road to replacing C++
It's somewhat at the other end of the spectrum, but I frequently use CL for small tasks too- replacing shell scripts etc. In that space it competes favorably with Python/Perl, modulo suitable libraries. Clisp is a great cross-platform (and small) implementation
and its easy to dump a specialized image to get the load-time down. I recently used Clisp w/ ImageMagick to do some data visualization, replacing a horrible array of bash scripts. Interestingly, the simplicity of shell scripting carries over well without incurring
complexity from the vastly more capable language. Got a considerable performance increase over shell scripting, but that's not a huge surprise.
Greg
Pascal Costanza <pc@p-cos.net> wrote:
Hi Gerry,
In my experience, with Common Lisp, and specifically with LispWorks, you can easily get in the range of a factor of 1.5 or so of the speed of good C++ code. So in principle, nothing speaks against using Common Lisp as a replacement for
C++ for systems programming.
However, Common Lisp is a language designed with productivity as a primary goal, and only then with performance as a secondary goal. This means that you can only achieve performance if you are willing to put in extra work to get all the
type declarations and optimization declarations right. I don't believe that the majority of existing Common Lisp libraries is written with such attention to low-level performance details in mind. So I would expect that you have to put in more work into tuning
libraries yourself, or simply be more careful during library selection.
C++ libraries can also suffer from this problem, because as you said yourself, C++ also has a number of features that can lead to excess overheads if used without care. So I'm not sure that C++ is strictly better in this regard. You can
probably also easily choose the wrong library, and only later discover that there are unexpected, unnecessary performance overheads. (If someone uses BOOST, I'm immediately also wary of potential problems… ;)
Pascal
On 17 Feb 2013, at 11:02, Gerry Weaver <gerryw@compvia.com> wrote:
Hi Paul,
I think perhaps my post was unclear. I don’t have a performance issue at all with C++. I have been looking for a C++ replacement for a number of reasons, but
performance was not one of them. For example, I don’t like the direction C++ is headed at all. The performance issues I’m having are with the various Lisp libraries I have tried. I’m trying to figure out what it will take to make Lisp a viable C++ alternative
for the work I do.
Thanks,
Gerry
From: Paul
Billington [mailto:paulfwb@mac.com]
Sent: Sunday, February 17, 2013 3:40 AM
To: Gerry Weaver
Cc: lisp-hug@lispworks.com
Subject: Re: On the road to replacing C++
Having read your post, I am unclear why you wish to replace C++. From my experience as a programmer of performant systems C++ (a superset of C) can be very performant if
care is taken, e.g. Avoiding inappropriate run-time bindings and over zealous use of object creation and destruction etc.
What aspect of C++ are you thinking of when referring to poor performance?
Best regards,
Paul
Paul F. Billington
+41 79439 2281
"The past is a foreign country: they do things differently there." (L. P. Hartley)
On 16 Feb 2013, at 23:54, Gerry Weaver <gerryw@compvia.com> wrote:
Hello All,
Before I get into the questions I would like to ask, I want to mention something about my area of interest. I am primarily a system programmer. What I mean by “system programmer” in this case is that I develop things that run on a server (bulk processing, routing, monitoring, etc). I do this work primarily for financial institutions. I also do a fair amount of work in networking and system monitoring, management and virtualization. I have been doing a lot of looking around/reading/testing and this doesn’t appear to be an area that very many Lispers are working in. One of the main issues I have come up against is performance. I know that performance is an area that many developers are unnecessarily preoccupied with, but that is not the case here. I am trying to use Lisp as a higher level (hopefully) lower maintenance replacement for several things that are currently written in C++. My personal intention for the use of Lisp is to provide the higher level glue logic for these programs. I envision a layer of C code providing OS access and things like image processing etc. and using Lisp to provide the higher level logic that glues it all together. My questions will inevitably be in this vain, so if this list is not the appropriate place for such questions please let me know.
Why lisp-hug? Well.. my reasoning is that I’m a licensed LispWorks customer and I very much want the opinion of folks who are using Lisp (LispWorks) in a commercial/professional setting. If I am wrong about this, please let me know.
I am finding that a lot of the Lisp libraries/packages available on the web are not exactly written with the system programmer mindset. Some of them are beautiful and very educational, but they lack a focus on performance, scalability, and maintainability. I am not one to reinvent the wheel unless there is no other option, but it’s beginning to look like I’m going to have to start pretty close to the OS on a lot of the things I need. I’m wondering if y’all would agree with my findings or if you could possibly point me to some Lisp packages that are more in the vain I described.
I am currently working on some benchmarks that will hopefully help me figure out the depth and scope of the C layer that will be necessary to accomplish the goal of replacing C++. I’m wondering if y’all could share some of your experiences with me that involve using the existing Lisp i/o facilities available (ie; disk, network) and the smp/threading capabilities of LispWorks and other. I do plan to do benchmarks, but I think it would be great to hear from y’all, due to my being so new to Lisp. Would it be considered acceptable to post code fragments to this list to get a second opinion on code that I think should run faster, but doesn’t?
Interfacing Lisp with C is something that I’m going to be working on a lot. I’m curious about the overhead involved in calling C functions from Lisp and vice-versa. How does the Lispworks FLI compare to CFFI and others? Which one would y’all use and why? The particulars of Lisp/C and C/Lisp behavior in multi-threaded applications is also an area that I going to need to understand pretty well. The LispWorks docs provide some good information on this, but I trying to distill it down to some simple rules for access between Lisp/C and C/Lisp where threads are involved. Are there any docs/papers around that address this in good detail?
Thanks,
Gerry
--
Pascal Costanza
The views expressed in this email are my own, and not those of my employer.