I totally agree that maximum speed is required for AGI. I agree with Ben that flexabilty is also needed (he might have said liked, not needed) like seen in Ruby. My language IDE has a small simple editor built-in that automatically reformats the code and compiles as it saves making compiling totally invisible. Edit/compile/run turnaround is as fast as one click of the mouse. My system, although unintentionally somewhat like Ruby (my system was totally designed without any knowledge of Ruby) has almost all of it's flexability while retaining almost the speed of C++. My worst case internal looping is 15x slower than C++ but most functions and overall program execution are much closer to C++ speed. The looping overhead on my machine is about 10M/sec for a store operation. My looping speed is 2-3 times faster than Visual FoxPro which is very fast for a compiler/byte code interpreter. I haven't tested Ruby on my machine but I would suggest it's looping overhead to be at least 100-200 times slower than C++. My indexing times are similiar to Visual FoxPro or better. I have never seen a faster indexing/data access system than Visual FoxPro (any bench mark between MySQL and Visual FoxPro would be no contest at all). I can import 100,000 names/addresses in 1.5 seconds and search every record in this file by first name, last name and prov in 1/10 second (data searched is 17.8M and all records are stored on the disk). I have tested full text search on 16K emails representing 100M of data in 1 second where the data is stored on the disk (it would be faster if only in memory). I have had 2.5K programs running at the same time and created tables of over 2M records. I have created arrays up to 10M elements. (size is limited to memory space)
-- David Clark ----- Original Message ----- From: "Chuck Esterbrook" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, March 20, 2007 7:43 PM Subject: Re: [agi] My proposal for an AGI agenda > Sometimes the slowness of a program is not contained in a small > portion of a program. Especially, after a few rounds of profiling and > improving performance render the profile graph fairly flat. > > I experienced this on a financial program that I ported from Python to > C# for an 18 X speed up (and I had already improved the Python program > itself 2 - 4 X (memory getting fuzzy...) before running out of > reasonable ways to make it faster). So then instead of having to wait > 20 minutes per run to study the results and continue development, I > only needed to wait a little over a minute. That made a *huge* > improvement in speed of development. > > Unfortunately, C# is not a rapid coding language like Python and Ruby > and consequently some of the speed up (but not all) was lost in > development. > > There are some applications that don't suffer much from this either > because they are overwhelmed by external factors (such as network > latency), or they are a small part of the system (providing glue), or > they have a specific piece of code that overwhelms performance which > can be pushed out to C or C++ (tight inner loop). > > But there's plenty of programs that are down right fascinating *and* > compute intensive including AGI, GP/GA/EC, NNs, simulation, finances, > compression, search and more. Many of these require speed in order to > work with non-trivial data sets while still enabling a fast "run, > study, edit" loop. And, of course, you want quick, high level coding > to keep the "run, study, edit" loop tight as well. > > I think we can have both with the right language design. I'll finish > this off in a response to Ben in this same thread... > > -Chuck > > ----- > This list is sponsored by AGIRI: http://www.agiri.org/email > To unsubscribe or change your options, please go to: > http://v2.listbox.com/member/?list_id=303 ----- This list is sponsored by AGIRI: http://www.agiri.org/email To unsubscribe or change your options, please go to: http://v2.listbox.com/member/?list_id=303
