«

On Fri, 2 Jul 2004, Lennon Day-Reynolds wrote:

> Perhaps because we would like to see more people using Ruby? Or even just
> because the sort of people who use "fringe" languages like Ruby tend to
> enjoy discussion of obscure details of implementation and
> semantics?
>
> Lennon

yes. yes.

regards.

-a
--
================================================== =============================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it.
| --Dogen
================================================== =============================

Robert Klemme a écrit :
(snip)
> And, for real high performance requirements it's likely that Ruby -
> whether compiled to native or whatever - will not reach the mark that can
> be set languages like C and C++. The dynamic nature does cost some
> performance.
Just for the record, Common Lisp is (more or less) as dynamic as Ruby,
and some implementations produce really good and fast native code...
(ok, perhaps not as fast as C !-)
(snip)

bruno

OCaml is as dynamic as LISP and some implementations produce native
code that _is_ as fast as C. It's quite amazing.

On Fri, 2 Jul 2004 07:12:50 +0900, bruno modulix <> wrote:
>
> Robert Klemme a écrit :
> (snip)
> > And, for real high performance requirements it's likely that Ruby -
> > whether compiled to native or whatever - will not reach the mark that can
> > be set languages like C and C++. The dynamic nature does cost some
> > performance.
> Just for the record, Common Lisp is (more or less) as dynamic as Ruby,
> and some implementations produce really good and fast native code...
> (ok, perhaps not as fast as C !-)
> (snip)
>
> bruno
>
>

There are several reasons that Common Lisp can achieve much better
performance than Ruby. First and foremost is the fact that Lisp-like
languages in general have been around longer than C, and have been the
subject of extensive work in optimization and native code generation.
Second, CL, while being value-typed in a fashion similar to modern
scripting languages, also supports type annotations, which allow the
compiler to generate more efficient code for critical sections.

Performance has much less to do which language selection than it does
with abstraction and algorithm selection. Some languages (like C) are
excellent for manipulating data at the level of individual pointers
and registers, but require a great deal of infrastructure to approach
the productivity of higher-level languages. If you were to write C
code that emulated the Ruby object model, it would likely run in
approximately equivalent time.

Lennon

On Fri, 2 Jul 2004 07:12:50 +0900, bruno modulix <> wrote:
>
> Robert Klemme a écrit :
> (snip)
> > And, for real high performance requirements it's likely that Ruby -
> > whether compiled to native or whatever - will not reach the mark that can
> > be set languages like C and C++. The dynamic nature does cost some
> > performance.
> Just for the record, Common Lisp is (more or less) as dynamic as Ruby,
> and some implementations produce really good and fast native code...
> (ok, perhaps not as fast as C !-)
> (snip)
>
> bruno
>
>

Klaus Momberger wrote:

>TLOlczyk <> wrote in message news:<>. ..
>
>
>>[....]
>>
>>
>
>why would anyone care that you are not using Ruby ?
>
>

The Ruby community may not care if any one person decides not to use
Ruby (unless, say, that one person were Matz).

But it's in the interest of language development to hear when people
have problems using the Ruby.

Most of the time the reason is a bit more mundane: lack of a specific
library of particular interest; low recognition value among so-called IT
managers who only know what they read in E-Week; syntax that conflicts
with some previously divined notion of the One True Way. That sort of
thing.

In some cases the concerns are legit (that is, they address issues that
are likely of interest to more than a handful of users); sometimes
theses issues can be addressed. And sometimes it is worth the trouble
to address a correctable, legitimate issue.

My recollection is that most of the so-called complaints come from folks
with a C/Java/Python/Perl background and are unhappy when Ruby doesn't
always map to their internal world view. Most of these have been
discussed to death; a suggestion to search ruby-talk is usually the best
response.

I'm more interested when somebody from a functional or logic programming
background gives Ruby a whirl and finds fault. It may, again, be an
issue of cognitive dissonance, but there is still something to be
learned from it.

Unless someone is trolling (and it's not always easy to tell) I
appreciate the effort to tell this crowd about possible ways to improve
the language.

James

Hello Lennon,

LDR> However, there are issues with this approach. Unlike most Lisps and
LDR> Smalltalks, Ruby is not a self-hosting system; the core runtime is
LDR> implemented in C, and depends heavily on the system libraries and
LDR> memory model of the underlying operating system. By using native
LDR> structures like file handles, dynamic libraries, and virtual memory
LDR> management pervasively, Ruby has more or less bound itself to the
LDR> lifecycle and call conventions of a "native" application.

Sorry but here you miss the point, using file handles, DLL's and
native structure does not mean anything for implementing an image
based language (it's not a heap image by the way).

LDR> However, it should be entirely possible to experiment with a limited
LDR> form of the global-image class of persistence. There are two main
LDR> paths I could see working. The more obvious would be performing a
LDR> standard Marshal.dump on every object in the heap, saving the state of
LDR> any serializable objects to disk (and allowing them to perform any
LDR> cleanup necessary prior to shutdown).

At the moment you can't dump methods and classes. So this would
require a lot of work. We are not talking about data persistence here.

LDR> Less trivial, but potentially more interesting, would be to allocate
LDR> new objects within mmap'ed address space, (effectively bypassing the
LDR> native virtual memory system) which would allow a 'dump' operation to
LDR> simply be implemented as a 'sync' on that space. Updates could be
LDR> incremental, and have near the same performance as the native OS does
LDR> with VM paging.

The current problem is the serialization of the program stack because
there native C function calls and ruby calls are mixed. Okay we could
dump only if there is nothing on the stack (which is the case when the
program exits normally), and return to a special "main" function on
the next start, but this is normally not that what you want in an
image based language.

LDR> Anyone with more language implementation experience care to weigh in
LDR> on the feasibility of such a hack? I know that several "academic"
LDR> languages already implement such functionality, and that as a
LDR> garbage-collected language, Ruby should already have most of the
LDR> infrastructure necessary to build it again.

I think the technical implementation is not the difficult thing here,
its the current state of libraries.

Oh yes, i implemented an LISP system in about 50000 lines of Assembler
code many many years ago. The core system, the VM, is not difficult to
write, but we would need a complete rewrite of Ruby.


--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

OCaml is, as far as I understand, actually much closer to C++ than
CLOS/Ruby/Smalltalk in object model and dynamism. Its object model
supports polymorphism, inheritance, and even parameterization, but
does not really allow redefinition of methods and instance variables
at runtime. In my usual thinking, "dynamic" and "statically typed" do
not often go together.

There's always going to be a certain amount of overhead incurred by
using a "pure", message-based object model. You can either try to
avoid it by having a restricted sub-language that can be turned into
fast native code (Psyco, Objective C, etc.), or by doing runtime JIT
compilation, with its implied assumption that changes to "hotspot"
code will be infrequent enough to make code cache invalidation a minor
cost compared to the savings provided by compilation.

In effect, the current solution for Ruby closely mirrors Objective C,
in that "high performance" code can be written in C (either using
Inline, or as a standalone extension). Personally, now that I'm
familiar with the Ruby C API, I don't really consider it to be that
bad having to drop into another language for performance-critical
code.

Lennon

Hello bruno,

bm> Just for the record, Common Lisp is (more or less) as dynamic as Ruby,
bm> and some implementations produce really good and fast native code...
bm> (ok, perhaps not as fast as C !-)
bm> (snip)

No. You need to use things like (the 'Integer i) all the time, and if
i would call this lisp anymore i don't know.

And even if you go this way, your program will then be as save as a
program in FORTH - or a C program where everything is casted to (void*)

Lisp guys write some routines in this "typed Lisp", rubyist's write
them in "C", so it's not so different.



--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

--- TLOlczyk <> wrote:
> [...]
> The main thing I am looking for is a basic environment similar to
> functional languages. In particular a ( native-code ) compiler and
> an extensible REPL. By REPL I mean read-eval-print-loop, a fancy
> word for interpreter. To make clear what I want, and why I think
> it is a superior approach, I will now explain how it is used.
>
> Typically you open the file you are working on in emacs,vi or
> an IDE. ( Typically it would be emacs or vi. The IDEs available
> tend to be too primitive. Other editors might do but I am not
> aware of them. ) The you split the session into two windows
> and start your REPL in one. You edit your file and send one
> "line" at a time to the REPL to be evaluated. By line I mean
> command. maybe a function definition, a class definition, a method
> definition, an assignment to a global variable... basically one
> "thought". You have problems so you debug the code. Then
> you send it again. Over and over, till it works right. ( Ok sometimes
> you have to restart the REPL, because you muck up something
> in the envornment. ) Sometimes to figure out what went wrong,
> say there is a global list and you want to see what's inside because
> you think it's wrong. You switch to the window with the REPL
> and you type the command to print the list.
> [...]

My REPL looks like this:

irb(main):005:0> test
=> true
irb(main):006:0> load 'foo.rb'
=> true
irb(main):007:0> test
=> true
irb(main):008:0> load 'testcase.rb'
=> true
irb(main):009:0> test
=> true
irb(main):010:0> load 'foo.rb'
=> true
irb(main):011:0> test
=> true
irb(main):012:0> load 'foo.rb'
=> true
irb(main):013:0> test
=> true
irb(main):014:0> load 'testcase.rb'
=> true
irb(main):015:0> test

This is all intermixed with setting and examining particular
variables and data structures. irb history and tab completion
make the process faster than it appears here.





__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

Carl Youngblood <> writes:

> On Fri, 2 Jul 2004 07:12:50 +0900, bruno modulix <> wrote:
>>
>> Robert Klemme a écrit :
>> (snip)
>> > And, for real high performance requirements it's likely that Ruby -
>> > whether compiled to native or whatever - will not reach the mark that can
>> > be set languages like C and C++. The dynamic nature does cost some
>> > performance.
>> Just for the record, Common Lisp is (more or less) as dynamic as Ruby,
>> and some implementations produce really good and fast native code...
>> (ok, perhaps not as fast as C !-)
>> (snip)
>>
>> bruno
>>
> OCaml is as dynamic as LISP and some implementations produce native
> code that _is_ as fast as C. It's quite amazing.

It's definitely not as dynamic as Lisp. It's entirely statically
typed: types do not exist at runtime. It has very few facilities for
introspection. The performance of its generated code and garbage
collector crucially depends on its static type system.

Not to say OCaml is a bad language for it. Dynamicity is a very nice
property -- but so is fast code. For me, the trade-off tends to favor
dynamicity, but if it didn't, I would love to use OCaml.

Except the lack of overloading would probably drive me crazy.

mikael