Re: [agi] Why C++ ?
On Mar 30, 2007, at 3:57 PM, Philip Goetz wrote: On 3/23/07, Ben Goertzel [EMAIL PROTECTED] wrote: Additionally, we need real-time, very fast coordinated usage of multiple processors in an SMP environment. Java, for one example, is really slow at context switching between different threads. Java's threads are fairly heavy. You can use Cybele to implement Java agents that run on lighter threads; switching between them is much faster. I wrote the first version of NASA's ACES simulator using Cybele; it had about 50,000 threads active at a time, running on a single processor. Or did you mean that you want to use multiple physical processors, and a small amount of heavy threads? That sounds like what you said, but I assumed that isn't what you meant, because you wouldn't need to switch between threads if you're really talking about CPUs. I believe you can write your own routines for serialization in Java. I think what Ben meant was that Java threads are a bit like typing in mittens. For some purposes the granularity is pretty coarse and that can cost serious performance. However, many applications don't have any such issues; it is a relatively narrow use case. For a single core it is not much of an issue (at least not for me), but for some purposes it can be really hard to use multiple processing units effectively at the level of control available through Java. There are resource management possibilities in C that simply are not exposed in Java. As Ben mentioned above, extremely fast multi-processor coordination is far from ideal in Java compared to what is possible in C. This is a good thing. Java is supposed to be portable and hide these kinds of bare metal characteristics. The only bad thing is that it is hard to get to the bare metal through Java if you need to. Cheers, J. Andrew Rogers - 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
Re: [agi] Why C++ ?
On 3/23/07, Ben Goertzel [EMAIL PROTECTED] wrote: Additionally, we need real-time, very fast coordinated usage of multiple processors in an SMP environment. Java, for one example, is really slow at context switching between different threads. Java's threads are fairly heavy. You can use Cybele to implement Java agents that run on lighter threads; switching between them is much faster. I wrote the first version of NASA's ACES simulator using Cybele; it had about 50,000 threads active at a time, running on a single processor. Or did you mean that you want to use multiple physical processors, and a small amount of heavy threads? That sounds like what you said, but I assumed that isn't what you meant, because you wouldn't need to switch between threads if you're really talking about CPUs. I believe you can write your own routines for serialization in Java. Finally, we need rapid distributed processing, meaning that we need to rapidly get data out of complex data structures in memory and into serialized bit streams (and then back into complex data structures at the other end). This means we can't use languages in which object serialization is a slow process with limited customizability-for-efficiently. You can customize object serialization in Java, I'm pretty sure. C++ with heavy use of STL and Boost is a different language than the C++ we old-timers got used to back in the 90's. It's still a large and cumbersome language but it's quite possible to use it elegantly and intelligently. I am not such a whiz myself, but fortunately some of our team members are. It is a nice language, but I want it dead, because it's killing open-source. Most open-source projects are in C or C++, and they can't be ported to other systems. I mean that. Dedicated programmers who apparently have way more time than I do can port an open-source application from one platform to another, but I rarely can unless I spend several days at it. It's common for the config files and makefiles to an open-source program to be tens of thousands of lines, often longer than the source code itself. It would be easier for me to rewrite the application than to rewrite the makefile! Java programs, on the other hand, port instantly. I have only twice had problems porting Java code - both times with graphics. I became a Java convert when I burned the code for my large airspace simulator, which I and some other people had spent 2 years writing, onto a CD, took the CD out of my Windows machine and popped it into a Sun workstation, and... it ran. For comparison, a simpler airspace simulator written in C took us over a week to port from Windows NT 4 to Windows 2000. I think this may be an effect of the lack of standardization of C++ libraries, and the control that Sun maintains over Java, rather than any inherent properties of C++. But still. Death to C++. I've spent too many days scratching my head over cryptic linker errors. - 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
Re: [agi] Why C++ ?
You can customize object serialization in Java, but not in a way that makes it really fast... ben On 3/30/07, Philip Goetz [EMAIL PROTECTED] wrote: On 3/23/07, Ben Goertzel [EMAIL PROTECTED] wrote: Additionally, we need real-time, very fast coordinated usage of multiple processors in an SMP environment. Java, for one example, is really slow at context switching between different threads. Java's threads are fairly heavy. You can use Cybele to implement Java agents that run on lighter threads; switching between them is much faster. I wrote the first version of NASA's ACES simulator using Cybele; it had about 50,000 threads active at a time, running on a single processor. Or did you mean that you want to use multiple physical processors, and a small amount of heavy threads? That sounds like what you said, but I assumed that isn't what you meant, because you wouldn't need to switch between threads if you're really talking about CPUs. I believe you can write your own routines for serialization in Java. Finally, we need rapid distributed processing, meaning that we need to rapidly get data out of complex data structures in memory and into serialized bit streams (and then back into complex data structures at the other end). This means we can't use languages in which object serialization is a slow process with limited customizability-for-efficiently. You can customize object serialization in Java, I'm pretty sure. C++ with heavy use of STL and Boost is a different language than the C++ we old-timers got used to back in the 90's. It's still a large and cumbersome language but it's quite possible to use it elegantly and intelligently. I am not such a whiz myself, but fortunately some of our team members are. It is a nice language, but I want it dead, because it's killing open-source. Most open-source projects are in C or C++, and they can't be ported to other systems. I mean that. Dedicated programmers who apparently have way more time than I do can port an open-source application from one platform to another, but I rarely can unless I spend several days at it. It's common for the config files and makefiles to an open-source program to be tens of thousands of lines, often longer than the source code itself. It would be easier for me to rewrite the application than to rewrite the makefile! Java programs, on the other hand, port instantly. I have only twice had problems porting Java code - both times with graphics. I became a Java convert when I burned the code for my large airspace simulator, which I and some other people had spent 2 years writing, onto a CD, took the CD out of my Windows machine and popped it into a Sun workstation, and... it ran. For comparison, a simpler airspace simulator written in C took us over a week to port from Windows NT 4 to Windows 2000. I think this may be an effect of the lack of standardization of C++ libraries, and the control that Sun maintains over Java, rather than any inherent properties of C++. But still. Death to C++. I've spent too many days scratching my head over cryptic linker errors. - 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
Re: [agi] Why C++ ?
some extra points in support of C++:
- Developer quality; It seems to take about 5 years to get good at
C++. There's plenty of carbon-copy Java/PHP/.NET programmers being
churned out but they'll need some time to mature into decent
developers, with a good portion choosing attrition into BAs etc after
they realise they're not first-option coders. If you choose C++, then
you've already got candidate programmers who've been tried and tested.
The 5-year ramp-up is often one of the criticisms of C++ but for AGI
work I think it's probably a worthwhile prerequisite.
- Breadth of library support. Lisp has an even greater learning hurdle
than C++, so wins out on the point above; but then it loses out
big-time on library support and breadth of heavyweight APIs. Take
Boost STLport, add a cross platform support library like ACE and
above all top-notch compilers, debuggers/profilers and IDE's (e.g.
gcc, gdb Purify, (gulp) Visual Studio). On top of that you can write
to every BSP for any given architecture natively (as you can talk C in
the same source if you choose) and you also get OS bindings (POSIX
etc) and the ability to call native assembly directly to optimise for
specific heavy/repeated use segments (_asm{...}).
- Stability. Java wins on the point above, but fails here. Every major
app of note for the last 20 years has been C++. If the code is written
well and memory is allocated and deallocated cleanly then the app will
run continuously without failures while still being able to do
intensive ongoing processing. The latest space vehicles, medical
equipment, public safety and enterprise applications (remember: the
Java VM is C++) all run C++ and they all do it in a stable, error-free
manner. If the Java VM still leaks memory don't even begin to ask
about Python/Ruby etc. There are plenty of languages than can develop
good, clean code but their runtime performance for 24/7/365 is, in
general, pretty atrocious. I guess it's fair to say that it isn't OK
to have an AGI reboot itself at 5 before midnight like most modern web
apps do.
bias disclaimer: I'm a current C++ programmer, but I started off in
Perl C, then moved onto Java and then took it upon myself to learn
the meister of all current languages: C++. I personally love Java (and
am infatuated with Perl, especially Perl6/Parrot) and think some of
the things it offers kick C++ in the arse (Ant, JUnit, RMI, Servlets)
but I think the things C++ sucks least at are the things that matter
most for apps of this kind of importance; blame Steve Yegge if you
must :-)
-
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
[agi] Why C++ ?
Kevin Osborne wrote: some extra points in support of C++: - Developer quality [...] - Breadth of library support. [...] - Stability. [...] All fine and good several years from now, when mission-critical, robust AGI programs will be running the world in Joint Stewardship of Earth with us frail human beings. In the current 2007 infancy of AGI _any_ programming language at all will suffice for implementing a prooof-of-concept AI like http://mind.sourceforge.net/Mind.html -- AI in MSIE JavaScript. Personally, I will try my utmost to make Chuck Moore's Forth the AI-language-in-vogue (as it was for robotics 20 years ago) over the next several years, as the Forth community has been kind and receptive to me in my AI efforts for twelve years. Arthur -- http://mind.sourceforge.net/mind4th.html (Mind.Forth AI) http://aimind-i.com (a Mind.Forth offshoot by FJ Russo) - 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
Re: [agi] Why C++ ?
-very hard to write code that writes code compared to LISP, Ruby etc
-very hard to safely run code i think. in java you have security things
to execute code in safe sandboxes, in C++ any array can just run outside
its bounds
-in LISP any ruby and the likes, you can just execute 1 line of code
(interactively),
in C++ you have to go through a big compile cycle
The only thing C++ is good for, is writing efficient code
if you really need it
--- kevin.osborne [EMAIL PROTECTED] wrote:
some extra points in support of C++:
- Developer quality; It seems to take about 5 years to get good at
C++. There's plenty of carbon-copy Java/PHP/.NET programmers being
churned out but they'll need some time to mature into decent
developers, with a good portion choosing attrition into BAs etc after
they realise they're not first-option coders. If you choose C++, then
you've already got candidate programmers who've been tried and tested.
The 5-year ramp-up is often one of the criticisms of C++ but for AGI
work I think it's probably a worthwhile prerequisite.
- Breadth of library support. Lisp has an even greater learning hurdle
than C++, so wins out on the point above; but then it loses out
big-time on library support and breadth of heavyweight APIs. Take
Boost STLport, add a cross platform support library like ACE and
above all top-notch compilers, debuggers/profilers and IDE's (e.g.
gcc, gdb Purify, (gulp) Visual Studio). On top of that you can write
to every BSP for any given architecture natively (as you can talk C in
the same source if you choose) and you also get OS bindings (POSIX
etc) and the ability to call native assembly directly to optimise for
specific heavy/repeated use segments (_asm{...}).
- Stability. Java wins on the point above, but fails here. Every major
app of note for the last 20 years has been C++. If the code is written
well and memory is allocated and deallocated cleanly then the app will
run continuously without failures while still being able to do
intensive ongoing processing. The latest space vehicles, medical
equipment, public safety and enterprise applications (remember: the
Java VM is C++) all run C++ and they all do it in a stable, error-free
manner. If the Java VM still leaks memory don't even begin to ask
about Python/Ruby etc. There are plenty of languages than can develop
good, clean code but their runtime performance for 24/7/365 is, in
general, pretty atrocious. I guess it's fair to say that it isn't OK
to have an AGI reboot itself at 5 before midnight like most modern web
apps do.
bias disclaimer: I'm a current C++ programmer, but I started off in
Perl C, then moved onto Java and then took it upon myself to learn
the meister of all current languages: C++. I personally love Java (and
am infatuated with Perl, especially Perl6/Parrot) and think some of
the things it offers kick C++ in the arse (Ant, JUnit, RMI, Servlets)
but I think the things C++ sucks least at are the things that matter
most for apps of this kind of importance; blame Steve Yegge if you
must :-)
-
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
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/
-
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
Re: [agi] Why C++ ?
On 3/26/07, rooftop8000 [EMAIL PROTECTED] wrote: -very hard to write code that writes code compared to LISP, Ruby etc -very hard to safely run code i think. in java you have security things to execute code in safe sandboxes, in C++ any array can just run outside its bounds But for AGI _content_, the reflection and security features of existing languages like Lisp, Ruby and Java aren't what's needed so you have to roll your own language anyway. And for the _framework_, reflection and security aren't needed. Now for an AGI framework, I'd be inclined to use something like Java over C++ because it comes with a lot of work in terms of portability, garbage collection, ease of debugging etc done for you, but C++ isn't an entirely unreasonable choice. - 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
[agi] Why C++ ?
Samantha Atknis wrote: Ben Goertzel wrote: Regarding languages, I personally am a big fan of both Ruby and Haskell. But, for Novamente we use C++ for reasons of scalability. I am curious as to how C++ helps scalability. What sorts of scalability? Along what dimensions? There are ways that C++ does not scale so well like across large project sizes or in terms of maintainability. It also doesn't scale that well in terms of space requirements if the class hierarchy gets too deep or uses much multiple inheritance of non-mixin classes. It also doesn't scale well in large team development. So I am curious what you mean. I mean that Novamente needs to manage large amounts of data in heap memory, which needs to be very frequently garbage collected according to complex patterns. We are doing probabilistic logical inference IN REAL TIME, for real time embodied agent control. This is pretty intense. A generic GC like exists in LISP or Java won't do. Aside from C++, another option might have been to use LISP and write our own custom garbage collector for LISP. Or, to go with C# and then use unsafe code blocks for the stuff requiring intensive memory management. Additionally, we need real-time, very fast coordinated usage of multiple processors in an SMP environment. Java, for one example, is really slow at context switching between different threads. Finally, we need rapid distributed processing, meaning that we need to rapidly get data out of complex data structures in memory and into serialized bit streams (and then back into complex data structures at the other end). This means we can't use languages in which object serialization is a slow process with limited customizability-for-efficiently. When you start trying to do complex learning in real time in a distributed multiprocessor context, you quickly realize that C-derivative languages are the only viable option. Being mostly a Linux shop we didn't really consider C# (plus back when we started, .Net was a lot less far along, and Mono totally sucked). C++ with heavy use of STL and Boost is a different language than the C++ we old-timers got used to back in the 90's. It's still a large and cumbersome language but it's quite possible to use it elegantly and intelligently. I am not such a whiz myself, but fortunately some of our team members are. -- Ben G - 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
Re: [agi] Why C++ ?
On Fri, 2007-03-23 at 22:48 -0400, Ben Goertzel wrote: Samantha Atknis wrote: Ben Goertzel wrote: Regarding languages, I personally am a big fan of both Ruby and Haskell. But, for Novamente we use C++ for reasons of scalability. I am curious as to how C++ helps scalability. What sorts of scalability? Along what dimensions? There are ways that C++ does not scale so well like across large project sizes or in terms of maintainability. It also doesn't scale that well in terms of space requirements if the class hierarchy gets too deep or uses much multiple inheritance of non-mixin classes. It also doesn't scale well in large team development. So I am curious what you mean. I mean that Novamente needs to manage large amounts of data in heap memory, which needs to be very frequently garbage collected according to complex patterns. So all collection is being done by hand since C/C++ have no facilities. But complex heap management could be done in most any language where you can get at the bits. Heap management could logically be handled separately from the what is using the structures to be managed as long as their is good enough binding between the languages. But I see here that having a language relatively close to the metal was useful. We are doing probabilistic logical inference IN REAL TIME, for real time embodied agent control. This is pretty intense. A generic GC like exists in LISP or Java won't do. Lisp can though handle allocating large arrays in memory that are then subdivided. Exactly what you need can be modeled in Lisp and then tweak the code generation to make it as efficient as needed. It would be a bit unusual but doable. Aside from C++, another option might have been to use LISP and write our own custom garbage collector for LISP. Or, to go with C# and then use unsafe code blocks for the stuff requiring intensive memory management. Yes. Similar path. It could almost be done in Java at the byte code level but that would arguably be more unfriendly than C++. Additionally, we need real-time, very fast coordinated usage of multiple processors in an SMP environment. Java, for one example, is really slow at context switching between different threads. Depending on the threading model I can see that. Clever hacking can get around some needs for context switching but then you start stepping beyond the things Java is good for. Did you have much opportunity to form a judgment about Erlang? Finally, we need rapid distributed processing, meaning that we need to rapidly get data out of complex data structures in memory and into serialized bit streams (and then back into complex data structures at the other end). This means we can't use languages in which object serialization is a slow process with limited customizability-for-efficiently. Lisp could excel at streaming data. Java data streaming isn't that bad either as it can be customized to stream only what you wished streamed for your specific needs with custom readers and writers per object. It is relatively easy to do this custom approach in Java. You aren't stuck with the defaults. When you start trying to do complex learning in real time in a distributed multiprocessor context, you quickly realize that C-derivative languages are the only viable option. Being mostly a Linux shop we didn't really consider C# (plus back when we started, .Net was a lot less far along, and Mono totally sucked). C++ with heavy use of STL and Boost is a different language than the C++ we old-timers got used to back in the 90's. It's still a large and cumbersome language but it's quite possible to use it elegantly and intelligently. I am not such a whiz myself, but fortunately some of our team members are. Hehehe. That was the late 80's for me with another C++ stint from 96-99. STL and Boost give it some of the power of Lisp but in a much more difficult to understand and extend manner. :-) I can see the choice for tight management of memory for sure. I have some thought so using C# at least for optimizing a general cache I devised myself. I know less about the story of C, C++ utilization of newer multi-core processors. It is my understanding that most of the compilers still suck at taking advantage of such things. Lisp or Java should do fine with some tweaking at interprocess streaming of arbitrarily complex data. Thanks for the interesting and informative answer. - 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
