Re: Problem to compile g-wrap
On 03/10/11 23:58, Germán Arias wrote: I found the problem. the configuration say: checking size of size_t... 4 checking size of ssize_t... 4 checking for guile... /usr/local/bin/guile checking for guile-config... /usr/local/bin/guile-config checking for guile-tools... /usr/local/bin/guile-tools checking libguile compile flags... -pthread -I/usr/local/include/guile/2.0 -I/usr/local/include checking libguile link flags... -L/usr/local/lib -lguile-2.0 -lgc checking for guile-2.0... no Why? the Guile libraries are just there. Any advice? Thanks. This (the final report line) is not checking the guile libraries, it is checking that the guile you are using can be executed with or without a version extension (GUILE_VERSIONED). I don't think that that is related to the problem. It seems to me that you are compiling g-wrap too rigorously. Try turning off -Wall, -Werror and/or -Werror-implicit-function-declaration i.e. in g-wrap/Makefile CFLAGS = -g -O2 -Wall -Wmissing-prototypes -Werror -std=gnu99 -> CFLAGS = -g -O2 Paul.
Why is guile still so slow?
I don't understand while Guile is so slow. According to these benchmarks http://www.cs.utah.edu/~mflatt/benchmarks-20100126/log3/Benchmarks.html GNU Guile is running about a order of magnitude slower than Bigloo, Chicken, Gambit, Ikarus, Larceny, MIT, and Racket(PLT) with most task. I am asking why? Are the benchmarks wrong? Is it to keep it portable and embeddable? No matter the reason, unless the benchmarks aren't accurate and Guile is faster than it seems, the sluggishness of Guile is going to make it impossible to use to for application development no matter how Ubiquitous Guile currently is.
Re: Why is guile still so slow?
-[ Wed, Oct 12, 2011 at 10:54:11AM -0400, John Lewis ] > I don't understand while Guile is so slow. According to these > benchmarks > http://www.cs.utah.edu/~mflatt/benchmarks-20100126/log3/Benchmarks.html > GNU Guile is running about a order of magnitude slower than Bigloo, > Chicken, Gambit, Ikarus, Larceny, MIT, and Racket(PLT) with most task. Bigloo, Chicken and Gambit compiles to native code (through C). I can't tell for the others. This simple fact certainly accounts for most of the difference. Also, some (Bigloo for sure, maybe others) have type annotations while guile currently have not (although this was discussed recently). Also, as guile now relies on bdwgc for the GC it might suffer from conservative GC (while other scheme might use a dedicated GC, which can additionally perform some life span analysis to reduce useless collection - IIRC Gambit does this... or is it Stalin?). bdwgc is certainly a big win with regard to code complexity, though. > the sluggishness of Guile > is going to make it impossible to use to for application development > no matter how Ubiquitous Guile currently is. If so, then there is no application written in Python, Ruby, Javascript... :-) Joking aside, maybe guile is too slow for writing whole apps in it, but it's primary goal is to be an extension language, a companion for another C/C++ program, or at best an orchestrator of business oriented code. So performance is not the primary objective. For instance, I'm using guile as an extension language for a low-level commercial product for which speed matters, and it's perfect for what it does (configuring the software, mostly). Using another scheme app would have been less convenient since they are less easy to link with C code.
Re: Why is guile still so slow?
Hi John, Some notes. 1. Speed is always relative. Guile is faster than CPython or MRI. It is slower than V8. Implementations can't be slow or fast; they can only be slower than X or faster than Y. 2. Widespread Ruby usage proves that speed is not the most important thing. V8 proves that "slow languages" can be made fast. Things change; focus on expressiveness and what you want to do. 3. The benchmarks you mention are old. Guile has improved since then. 5. Benchmark speed is but one kind of speed. There are others: startup time, development time, etc. 4. Guile is slower than Ikarus because Guile compiles to bytecode, and Ikarus to native code. Native code will come at some point, but don't hold your breath. Finally, on the meta-level, you appear to be suffering from market-induced anxiety. If you prefer another implementation or language, by all means, go and use it. But if you prefer Guile, don't worry about the others. Problems get fixed over time with hacking. Regards, Andy -- http://wingolog.org/
Re: Why is guile still so slow?
Thank you for the responses everybody.
Procedure breakpoints
Hello, Is there any way to attach traps to another executing thread from the REPL? A use case would be to be able to trap procedures running in the main thread when I connect to a Guile started with the --listen option. -Tobias
Re: Why is guile still so slow?
On Wed, Oct 12 2011, ri...@happyleptic.org wrote:
[...]
> Joking aside, maybe guile is too slow for writing whole apps in it,
> but it's primary goal is to be an extension language, a companion for
> another C/C++ program, or at best an orchestrator of business oriented
> code.
I really hope that that's not Guile's primary goal these days (and my
understanding is that it is not): i wouldn't be much interested if those
were its goals ("orchestrator of business oriented code" sounds
particularly dreadful :-)).
Goals aside, Guile 2.x looks to me as a perfectly fine platform to
implement a wide range of applications, and, IMHO, it should be promoted
and developed as such.
But IANAGD :-D
Cheers,
jao
--
Substitute damn every time you're inclined to write very; your editor will
delete it and the writing will be just as it should be.
-Mark Twain, author and humorist (1835-1910)
Re: Why is guile still so slow?
> > but it's primary goal is to be an extension language, a companion for
> > another C/C++ program, or at best an orchestrator of business oriented
> > code.
>
> I really hope that that's not Guile's primary goal these days (and my
> understanding is that it is not): i wouldn't be much interested if those
> were its goals ("orchestrator of business oriented code" sounds
> particularly dreadful :-)).
By "business oriented code" I meant "business logic", ie. the actual
low level and specialized part of the program. For instance I do system
programming and cannot do it in scheme (whatever the implementation),
although scheme is perfect to control the higher levels of abstraction or
interaction with the user.
"business oriented code" sounds indeed dreadful. I need some vacation
(in an English speaking country for instance). :)
Re: Why is guile still so slow?
On Thu, Oct 13 2011, ri...@happyleptic.org wrote:
[...]
>> I really hope that that's not Guile's primary goal these days (and my
>> understanding is that it is not): i wouldn't be much interested if those
>> were its goals ("orchestrator of business oriented code" sounds
>> particularly dreadful :-)).
>
> By "business oriented code" I meant "business logic", ie. the actual
> low level and specialized part of the program. For instance I do system
> programming and cannot do it in scheme (whatever the implementation),
> although scheme is perfect to control the higher levels of abstraction or
> interaction with the user.
Couldn't you use the FFI? I haven't used Guile's yet, but hooking to
inotify in Racket was a breeze... Of course, if C-level performance is
a requirement, you'd need to switch to a CL compiler ;-)
> "business oriented code" sounds indeed dreadful. I need some vacation
> (in an English speaking country for instance). :)
Barcelona is sunny most of the year, and Wingo speaks quite idiomatic
American and Scheme :)
Cheers,
jao
--
To kill time is not murder, it's suicide. -William James (1842-1910)
Re: Why is guile still so slow?
-[ Thu, Oct 13, 2011 at 01:56:32AM +0200, Jose A. Ortega Ruiz ] > Couldn't you use the FFI? While FFI makes indeed things simplier, it's only one part of the story. Scheme/C integration involves also: - main() func can be C or Scheme (in order to slowly goes from C to Scheme) - Scheme runtime must support posix threads so that the important C threads are not interrupted by evaluation/compilation/GC > I haven't used Guile's yet, but hooking to > inotify in Racket was a breeze... Nor do I have used FFI from guile myself, but I've seen it used in Andy's guile-sqlite3 bindings and it's nice. See it here for instance: https://gitorious.org/guile-sqlite3/guile-sqlite3/blobs/master/sqlite3.scm > Of course, if C-level performance is > a requirement, you'd need to switch to a CL compiler ;-) Many CL compilers are wonderful but there is no reason why a Scheme compiler can't be made faster. Anyway, you'd have to get rid of the dynamic type checks and the GC to match C speed, so we won't see this happen soon.
