Lua! Lua! Cthulhu ftagn!
Gio
- Gio
dominik...@gmail.com
The question is not why, but whether you should do it.
Mingos
Martin Read
>Why should I include Lua scripting?
You shouldn't, unless there is something you want to do which will be
sufficiently easier with Lua scripting included to justify the work of
including Lua scripting.
--
\_\/_/ turbulence is certainty turbulence is friction between you and me
\ / every time we try to impose order we create chaos
\/ -- Killing Joke, "Mathematics of Chaos"
pau...@mbnet.fi
> Why should I include Lua scripting?
I think scripting was invented solely because of slow
compile times on large projects, but now computers are
fast enough to compile even large scale roguelikes in
decent time.
Scripting is like using templates in C++. You should
avoid using templates unless you really have to, but
often people make everything templates, because it's
something they think cool programmers do.
Jotaf
never lead to a finished game! ;)
What if you coded your entire game in lua? With today's computers,
performance shouldn't be a consideration for a typical RL! So why not
do it? Better yet, replace lua with python and use lib-tcod's python
port; after some experimentation I must say it's got the best of both
worlds (python and lib-tcod).
Jotaf
Gio
> sufficiently easier with Lua scripting included to justify the work
> of including Lua scripting.
That's precisely the problem! I'm trying to think of what I could do
with Lua that would make life easier on me as a programmer, or make the
game more interesting to play, and I'm coming up pretty stumped. :/
My only experience with Lua is making addons for the Warhammer UI, but
I'm sure it can do more than that. Monster AI? Dungeon generation? I
really have no idea. What would be the advantage of using Lua for those
as opposed to C++?
- Gio
idontexist
Try the roguelike game ToME. It uses Lua quite nicely for quests and
stuff.
David Ploog
> Why should I include Lua scripting?
Crawl uses Lua for various purposes: sourcing out interface stuff (like
colouring of menus and items) and code for portal vaults (like the
ziggurat).
The advantages: Playing around with the luas does not need compilation
(ie. no source). It allows for rather easy user customisation. Crawl's
interface got highly improved when we used player-made lua code. Likewise,
portal vaults can be made without compilation. In other words, lua
provides a lighter approach to adding stuff.
In general, sourcing out content to text files and lua code seems to be
preferable to actual C++ code.
I am only speaking for Crawl here, of course.
David
Xecutor
> On 7 helmi, 11:54, Gio <gioman...@sbcglobal.net> wrote:
>
> > Why should I include Lua scripting?
>
> I think scripting was invented solely because of slow
> compile times on large projects, but now computers are
> fast enough to compile even large scale roguelikes in
> decent time.
provide features not available in statically typed languages
like C and C++. And usually development on scripting
languages is much faster due to rich capabilities.
2) Scripting languages are often used as plugins
system for non-open-source projects.
3) In context of RL/Game development special scripting
language can be designed to simplify AI programming.
C/C++ is largely inconvenient for things like backtracking
and pattern matching.
> Scripting is like using templates in C++. You should
> avoid using templates unless you really have to, but
> often people make everything templates, because it's
> something they think cool programmers do.
Since all modern programming languages are full by Turing,
you never 'really have to' use most of the features of those
languages.
It's just the question of comfort, code readability, compactness and
safety.
Templates are powerfull feature of C++ and in my opinion
should be prefered to virtuality whenever it's possible.
I can agree that templates meta programming isn't something
that should be used other than for fun and out of curiosity.
coppro
> Scripting is like using templates in C++. You should
> avoid using templates unless you really have to, but
> often people make everything templates, because it's
> something they think cool programmers do.
As a C++ programmer, I completely disagree with this statement.
Templates aren't things that should be used at every available
opportunity, but using them liberally is a very good idea - for
instance, the use of traits classes and basic_ templates provide
massive amounts of flexibility simply not present in non-generic
programming. The only real cost adding more templates has is compiling
time, which makes them extremely useful. They also provide strong type
safety without needing macros or other types of boilerplate code.
Templating is, in general, something that should be considered in a
lot more cases then it is actually used.
coppro
Jotaf
programming so much, why restrict their use to a couple modules? Why
not use them for the whole thing? Give me one good reason.
Jotaf
Jotaf
to death :P
Jotaf
msa...@gmail.com
What a lot of people are saying, at least, is that it makes it simpler
for *users* (and not developers) to add content. If you allow parts of
the game to be determined using LUA, then the community can customize
it without needing to have a compiler, libraries, a build environment,
etc. They just need your binary and a description of what the inputs
and expected outputs are. If you have an active community and
incorporate their work, this can lead to a lot of creativity and
variety initiated by non-developers.
David used Crawl vaults as an example--when active community members
were able to easily create this content, the variety that the game
provided increased considerably. I've also seen it done very
successfully for AI in games like TurboRisk. I just happened to pick
that game up near the beginning of its development, and saw the number
of competent and unique play styles rise from 2-3 to 10+ in the first
year. I'd download all the new player AIs every few months and the
game would get hard again.
I don't think there is a whole lot to gain from using LUA in the
development of your own RL, except *maybe* to make it easier to
prototype new ideas. Its more to allow other people to add content.
Think of what Quake did with QuakeC to allow users to create
comprehensive mods, or how MMOs use LUA allow you to create very
sophisticated interface panels.
Jotaf
If the *entire* game was built in a "moddable" (ie, easy to pick up
and modify, unlike C) language, would it be better or worse?
There's one thing that's good when you put a scripting language in
your game: it's that you're forced to define a clear interface
separating high-level and low-level code. That helps clean up your
code; you tend to try to "make it easier" for the high-level layer to
do its thing. When the whole thing is coded in just one language,
there's a clear tendency to mix high-level and low-level code.
Jotaf
Ray Dillinger
> Fair, I was kinda playing devil's advocate there :)
>
> If the *entire* game was built in a "moddable" (ie, easy to pick up
> and modify, unlike C) language, would it be better or worse?
Firstly, most "useful" languages (including C) can be used to
build highly moddable code with general interfaces and well-
defined ways of adding new behavior. However, they can also
be used to build code that ... isn't. Many "simpler" languages
are simpler by virtue of what you *can't* do, which is a
double-edged gift at best.
Second, and accepting the idea that some languages are more
easily moddable than others, I don't know, really. I think
that at *some* level, the reason most people can't/don't
program is that most people can't/don't want to handle the
level of inherent complexity involved in governing and specifying
complex interactions and behavior. In other words, there's a
level of *irreducible* complexity that, to those who haven't spent
the time and effort to acquire the skills or to those who don't
have any aptitude for such skills, is a barrier. Problems which
exceed that level of complexity require a programmer-type brain
to solve. Programming is a very specific skill, really; it is
the use of abstraction and modeling to manage complexity.
Language choices can't alter that. I've been a developer for
several companies that made systems with scripting languages
"for end users" and what I saw over and over again was that
while these domain-specific languages helped some users do some
simple things they couldn't have done otherwise, the languages
didn't make as much difference as people expected or hoped when
things exceeded some level of complexity that required a
"programmer's brain" to manage.
The people who used our scripting languages to develop anything
complex, whether programmers or not, were "programmer types"
distinguished from average people by the ability to hold
complex state or interaction models in their heads and to reduce
or manage complexity through modeling and abstraction. They were
able to figure out what information they had to save and when,
in order to support the model of state that they were using, or
what condition they needed to branch on and where, in order to
make the interaction model work. They were also able to identify
common operations and use them to create abstractions that they
could reuse in multiple ways or places. People able to do that
could probably have used full-on programming languages to
accomplish the same thing just as easily, and often features
we added to "guard" scripting-language users against difficult
concepts (like say, recursion and dynamic memory management)
got in their way.
Our success stories were limited, but real; People who had
simple ideas and found a simple way to express them in our
languages were successful, where in a full-on development
programming language like C or C++ their ideas could not
find simple expression. Supporting them is largely a matter
of making a language that supports/expresses the paradigm
in which they think of the problem they're trying to solve.
It takes an unusual mind to think of ways to express the
paradigm of a map, for example, in a procedural language.
The paradigm is simple, and the problem/solution expressed
in that paradigm is also simple, but the complexities of
implementing the paradigm in which the problem/solution is
simple, are too complex for most. So when you've got a
problem and you know the solution is going to be some kind
of map, you can make simple solutions accessible to people
who have simple ideas using a scripting language that
uses/supports maps directly. This is why the "vaults"
scripting language in Crawl was a success. People have
simple ideas that are useful, given the simple paradigm
of a map. But they need a map-based language to express
them, and a typical programming language doesn't have any
simple, straightforward (visual) way to express maps. At
least no way that doesn't involve the definition and use
of abstractions, which most end-users cannot do.
I would not bother to embed a procedural scripting language
inside a game implemented in a procedural development language.
I would instead support user contributions with a large,
easily-extended, and well-documented library, with lots of
code examples, supporting the problem domain that I wanted
user-developed content contributed to.
But I *would* embed a scripting language if a problem domain
I wanted user-developed content for involved a paradigm with
no "obvious and visual" expression in my development language,
like constraint solving, maps, use of a unification algorithm,
visually represented state graphs or transition tables, etc.
As programmers we tend not to "see" these things because we've
internalized methods (abstractions) for expressing/representing
them in other paradigms. But that's a big barrier for people
who haven't developed the skill of using abstractions.
> There's one thing that's good when you put a scripting language in
> your game: it's that you're forced to define a clear interface
> separating high-level and low-level code. That helps clean up your
> code; you tend to try to "make it easier" for the high-level layer to
> do its thing. When the whole thing is coded in just one language,
> there's a clear tendency to mix high-level and low-level code.
Remember what I said about programmers? They are people who have
developed the ability/skill to be able to use modeling and
abstractions to manage complexity. You're talking here about an
abstraction (ie, definition and reuse of a common pattern to
accomplish a class of "similar" tasks), in this case an abstraction
of interface. That's something a programmer learns to do anyway,
and the sooner the better.
Bear
msa...@gmail.com
>
> "for end users" and what I saw over and over again was that
> while these domain-specific languages helped some users do some
> simple things they couldn't have done otherwise, the languages
> didn't make as much difference as people expected or hoped when
> things exceeded some level of complexity that required a
> "programmer's brain" to manage.
Bear, I agree with virtually everything you said, but I think there
was one thing it glossed over--the complexity of modifying interpreted
scripts vs. source code. I think what you say in the quoted section is
only true if the user already has an up-to-date (or appropriately out-
of-date) compiler, a build environment with all necessary libraries,
and a debugger that works for the system they are on *and* they know
how to use it.
Interpreted scripts that are protected from the application's memory
space do have two(+?) of 'ease of modification' advantages for the
casual programmer. First, there is the build environment issue--you
only have to have a binary compiled by someone for the system you are
on. Also, a well designed application can be protected from user
errors and report more friendly feedback (something other than a core
dump, and ideally an actually error message).
I'm still not saying I think LUA is something everyone should use. I
think its application is limited. But I do think if you want to let
other people mod your game, its a good way to go.
Radomir Dopieralski
> On Feb 9, 1:10 pm, Ray Dillinger <b...@sonic.net> wrote:
> I think what you say in the quoted section is
> only true if the user already has an up-to-date (or appropriately out-
> of-date) compiler, a build environment with all necessary libraries,
> and a debugger that works for the system they are on *and* they know
> how to use it.
The version of compiler doesn't really matter, unless it is C++ ;)
And you distribute the build scripts with the sources, obviously.
If you also happen to be using free/open tools for additional tasks,
like converting images to desired formats, for example, you can also
attach their sources to your project, and include building them in
the build scripts.
I agree that packaging the project properly requires some knowledge
and experience, but you are supposed to learn it sooner or later anyways.
Badly prepared distribution package is not unlike badly written code --
it's a defect, a bug to be fixed, not an inconvenience.
I hate it when the students bring me their projects that only work on
their own computers, and only when started from the IDE...
--
Radomir Dopieralski, http://sheep.art.pl
msa...@gmail.com
> I agree that packaging the project properly requires some knowledge
> and experience, but you are supposed to learn it sooner or later anyways.
> Badly prepared distribution package is not unlike badly written code --
> it's a defect, a bug to be fixed, not an inconvenience.
Again, I'm only talking about reducing the overhead to allow your user
community to contribute content to your game. Even if you make a very
clean and portable build environment (which is a non-trivial project
ever for a serious programmer), the fact that you expect them to
*have* a compiler is a hurdle. If you want to allow serious players
with little programming experience to create content, this will deter
a great many of them.
> I hate it when the students bring me their projects that only work on
> their own computers, and only when started from the IDE...
Just tell them they failed the project, and then offer them the option
to get partial credit if they can get it working within a day. They
won't do it again. Its what I do.
Xecutor
General purpose scripting languages like Perl, Python and Ruby
have one significant flaw.
You need to install corresponding runtime to run the game.
Or include it with game.
Which makes otherwise rather small game to grow up to several tenths
of megabytes.
Another problem is bindings to low level APIs.
I wish for an easy to embedd scripting language with minimalictic
runtime, yet powerfull enough to write most of the game on it.
Btw, one more point against scripting language for entire game:
easy to read code in scripting language is one big spoiler :)
Christophe
> On Feb 9, 12:15 am, Jotaf <jota...@hotmail.com> wrote:
>> Since you're all saying that scripting languages can simplify
>> programming so much, why restrict their use to a couple modules? Why
>> not use them for the whole thing? Give me one good reason.
>>
>> Jotaf
>
> General purpose scripting languages like Perl, Python and Ruby
> have one significant flaw.
> You need to install corresponding runtime to run the game.
> Or include it with game.
> Which makes otherwise rather small game to grow up to several tenths
> of megabytes.
I think your sense of scale is of. People got a Python interpreter
running on a Nintendo DS so it shouldn't be that big :) Don't confuse
the size of the standard install with the size of the core interpreter
itself. You sure don't need all the fancy GUI, DB connection tools and
more stuff when you embed an interpreter in a game. You only need the
language itself and the very low level stuff like the math libs or the
flow control tools. For that, you should be able to easily make a
lightweight Python version that fits in less than 3MB uncompressed I'd say.
Mario Lassnig
An alternative might be Ecmascript. The complete V8 package (implementing
Ecma-262) is about 1.6M as a shared library and include file.
Ido Yehieli
>
> I think your sense of scale is of. People got a Python interpreter
> running on a Nintendo DS so it shouldn't be that big :) Don't confuse
> the size of the standard install with the size of the core interpreter
> itself. You sure don't need all the fancy GUI, DB connection tools and
> more stuff when you embed an interpreter in a game. You only need the
> language itself and the very low level stuff like the math libs or the
> flow control tools. For that, you should be able to easily make a
> lightweight Python version that fits in less than 3MB uncompressed I'd say.
I think that on windows you only need to add a ~900kb dll and you
could use py2exe (which iirc does not generate a very big
executable). So even 3mb is a vast overestimation :)
-Ido.
Radomir Dopieralski
> On Feb 9, 12:15 am, Jotaf <jota...@hotmail.com> wrote:
> I wish for an easy to embedd scripting language with minimalictic
> runtime, yet powerfull enough to write most of the game on it.
Funny how that language is actually mentioned in the topic ;)
msa...@gmail.com
> > I wish for an easy to embedd scripting language with minimalictic
> > runtime, yet powerfull enough to write most of the game on it.
>
> Funny how that language is actually mentioned in the topic ;)
In the subject line even!
Xecutor
> At Tue, 10 Feb 2009 03:29:05 -0800 (PST), Xecutor wrote:
>
> > On Feb 9, 12:15 am, Jotaf <jota...@hotmail.com> wrote:
> > I wish for an easy to embedd scripting language with minimalictic
> > runtime, yet powerfull enough to write most of the game on it.
>
> Funny how that language is actually mentioned in the topic ;)
The Aging Minotaur
> General purpose scripting languages like Perl, Python and Ruby
> have one significant flaw.
> You need to install corresponding runtime to run the game.
> Or include it with game.
I know that Python can spit out exe-files (search for py2exe). I never
tried it, or even considered using it, so I couldn't tell you if it's
any good. Most Linux distros ship with python as a default, anyway,
and mac users ... well, who cares, really :P
Minotaur
Radomir Dopieralski
Macs ship with python isntalled by default too now.
Ido Yehieli
>
> Lua doesn't pass my subjective "powerfull enough" criterion :(
Which 'powers' does it lack?
-Ido.
Tom Hudson
Given that Lua seems to be beating out Python (or at least threatening
to do so) for scripting languages embedded in professional games, you
have interesting criteria. Can you elaborate?
Tom
Matthew Allen
I'm baffled too. What can't LUA do? I've embedded it in C to do map
generation and run NPC AIs. It trivially handles monster and item
generation. Even if that's all it can do, you've written almost the
entirety of the game in LUA. I'm pretty sure you could even use it for
combat rules and defining spell effects and special abilities,
although I'm not entirely sure about that.
Again, I don't advocate using LUA for much. But the fact that its 'not
powerful enough' isn't one of my concerns.
jice
When it comes to put more of the game in the scripted part, the main
concern is the scripting engine performance.
I think this :
http://www.timestretch.com/FractalBenchmark.html
explains why LUA is the #1 scripting language for games. It has
nothing to do with the elegance or the features of the language.
--
jice
Xecutor
> > > Lua doesn't pass my subjective "powerfull enough" criterion :(
> What can't LUA do?
The problem is not in "can't".
The problem is in "can".
What LUA can do what I can't do in C++?
Switching from C++ to LUA for entire game will be kind of downgrade.
Yeah yeah, I know that LUA can compile code at runtime.
But this is required for really small part of game, if required at
all.
So, probably LUA is good for plugin/addon-like system,
but not for entire game development.
Probably 'powerful' is not correct term...
There is nothing in LUA to simplify game development.
Typeless variables and tables are not considered as simplification.
In long term perspective it's just source of errors.
Christophe
There is py2app which is like py2exe, but for Mac.
Ido Yehieli
>
> There is nothing in LUA to simplify game development.
> Typeless variables and tables are not considered as simplification.
> In long term perspective it's just source of errors.
I find it odd that you present your frankly quite controversial
opinion as known fact.
Let's not have another scripting/compiled languages war?
-Ido.
Xecutor
<spam.minotaur.s...@googlemail.com> wrote:
> On Feb 10, 12:29 pm, Xecutor <konstantin.stup...@gmail.com> wrote:
>
> > General purpose scripting languages like Perl, Python and Ruby
> > have one significant flaw.
> > You need to install corresponding runtime to run the game.
> > Or include it with game.
>
> I know that Python can spit out exe-files (search for py2exe). I never
scripts.
I tried to use perlcc and pl2exe (or something like this).
While script of 'hello world' class were ok,
I failed to make independant executable from bigger project.
> tried it, or even considered using it, so I couldn't tell you if it's
> any good. Most Linux distros ship with python as a default, anyway,
> and mac users ... well, who cares, really :P
I'm using mac at work :)
Perl, python and ruby are shipped with OSX nowadays.
But at home I have WinXP and only perl is installed.
And I'm not rly sure that I want to install python just for a
roguelike,
unless it's reported as something awesome.
Christophe
> On Feb 11, 12:39 am, The Aging Minotaur
> <spam.minotaur.s...@googlemail.com> wrote:
>> On Feb 10, 12:29 pm, Xecutor <konstantin.stup...@gmail.com> wrote:
>>
>>> General purpose scripting languages like Perl, Python and Ruby
>>> have one significant flaw.
>>> You need to install corresponding runtime to run the game.
>>> Or include it with game.
>> I know that Python can spit out exe-files (search for py2exe). I never
> In my experience such things are only useful for relatively simple
> scripts.
> I tried to use perlcc and pl2exe (or something like this).
> While script of 'hello world' class were ok,
> I failed to make independant executable from bigger project.
So, basicaly you say that "since perlcc or pl2exe (don't remember which
one) is buggy and doesn't work correctly, no other tool similar to them
for any scripting language can work" ? :)
Xecutor
1) Both didn't work.
2) Both python and perl are dynamic languages and allow dynamic
modules importing.
It's impossible to track all modules that are used by program.
It's impossible (in general case) to make single independent .exe
unless all python modules are packed into it.
You need to imply some limitations while developing program,
and carefully select modules that are used in order to make
it compatible with this tool.
I've seen several games written in Python.
Can't say that it was good experience.
Matthew Allen
> The problem is not in "can't".
> The problem is in "can".
> What LUA can do what I can't do in C++?
> Switching from C++ to LUA for entire game will be kind of downgrade.
> Yeah yeah, I know that LUA can compile code at runtime.
> But this is required for really small part of game, if required at
> all.
> So, probably LUA is good for plugin/addon-like system,
> but not for entire game development.
> Probably 'powerful' is not correct term...
> There is nothing in LUA to simplify game development.
> Typeless variables and tables are not considered as simplification.
> In long term perspective it's just source of errors.
Ah, this makes a lot more sense. I agree 100%.
David Ploog
> On Feb 11, 4:02 am, Xecutor <konstantin.stup...@gmail.com> wrote:
>> The problem is not in "can't".
>> The problem is in "can".
>> What LUA can do what I can't do in C++?
>> Switching from C++ to LUA for entire game will be kind of downgrade.
I am starting to assume your are deliberately trolling around. If you
looked at the replies (which I doubt by now), you would have seen that no
one recommended going all lua. You would also have seen that lua has been
used to good effect. I mention again that this is the case of DCSS.
>> Yeah yeah, I know that LUA can compile code at runtime.
>> But this is required for really small part of game, if required at
>> all.
>> So, probably LUA is good for plugin/addon-like system,
>> but not for entire game development.
>> Probably 'powerful' is not correct term...
>> There is nothing in LUA to simplify game development.
>> Typeless variables and tables are not considered as simplification.
>> In long term perspective it's just source of errors.
While each of the sentences above has some justification, the total
picture they give seems far off. I didn't want to reply to Xecutor's
rant...
> Ah, this makes a lot more sense. I agree 100%.
...but this seems to indicate he is successful in spreading half-truths. I
don't think lua should be used as a replacement for a programming
language. It may be true that using it (in addition to C++, say) is only a
real benefit to larger projects, I cannot say. But lua definitely has
proved its worth in a great number of projects, including games of all
types, including roguelikes.
David
Matthew Allen
> > Ah, this makes a lot more sense. I agree 100%.
>
> ...but this seems to indicate he is successful in spreading half-truths. I
> don't think lua should be used as a replacement for a programming
> language. It may be true that using it (in addition to C++, say) is only a
> real benefit to larger projects, I cannot say. But lua definitely has
> proved its worth in a great number of projects, including games of all
> types, including roguelikes.
Well, I think his criticisms there were right. I agree its a bit of a
rant and he doesn't seem to have read much of the rest of the thread.
But its true that the LUA language doesn't provide anything meaningful
over another language. Its also not going to help you write your own
code, and its only going to make your project more difficult (you have
to program an interface that you didn't need before). Its probably
also going to be slower than compiled code.
I think I've been clear on what I think LUA is good for, though. You
can put in the extra work to include it, and the advantage is other
people can add to your project. If that's not your goal, I'm not sure
it has much use.
Jotaf
slower?!
And I was hoping to re-design my RL in Python, because I'm all burned
out on C++ and my master thesis is going to be coded in C++ already,
so I'd better pick another (easier?) language in order for RL
development to be fun again instead of feeling like... work =|
How about Psyco? It's a kind of a JIT compiler for Python. Import it
and it's optimizing already. Typical speed-up of 4x with no
modification to code (so 200x slower than C becomes 50x slower on
average... acceptable I guess). Algorithmic code (with few library
calls) becomes almost as performant as pure C.
http://psyco.sourceforge.net/introduction.html
They say that it leads to a nasty memory overhead, but until I test it
myself I cannot say if it's significant enough to outweight the
(AWESOME) advantages.
Jotaf
b0rsuk
> That benchmark... Python is 200x slower than C++? And Lua is only 30x
> slower?!
That benchmark measures performance in only 1 scenario: fractals.
Here's what I think is a more balanced benchmark:
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all&box=1
Selected results (less is better. 10 means 10 times slower than the
fastest language etc. SOrry for tabs if there are any, copy/paste):
score language
1.0 C++ Intel
1.1 C GNU gcc
1.1 C Intel
1.2 C++ GNU g++
1.4 Pascal Free Pascal
1.4 Java 6 -Xms64m
1.5 Java 6 -server
1.7 Fortran Intel
1.8 Ada 2005 GNAT
1.9 Haskell GHC
2.2 OCaml
2.3 Java 6 -client
2.5 Lisp SBCL
2.7 BASIC FreeBASIC
3.0 C# Mono
4.7 Fortran G95
6.7 Lua LuaJIT
6.9 Python Psyco
8.4 Scheme Ikarus
8.6 Erlang HiPE
10 Scheme PLT
12 Smalltalk VisualWorks
20 Scheme Chicken
22 Lua
23 Python
24 Java 6 -Xint
26 Perl
27 Ruby 1.9
30 PHP
37 Python IronPython
41 Smalltalk GNU
54 Ruby JRuby
58 Smalltalk Squeak
60 JavaScript SpiderMonkey
Feel free to point out flaws in above ranking.
> And I was hoping to re-design my RL in Python, because I'm all burned
> out on C++ and my master thesis is going to be coded in C++ already,
> so I'd better pick another (easier?) language in order for RL
> development to be fun again instead of feeling like... work =|
It's not nearly as bad as 200x.
> How about Psyco? It's a kind of a JIT compiler for Python. Import it
See above. Around 7x slower than C rather than 23x slower for regular
Python. By the way, I'm a bit uncomfortable that Psyco is not likely
to make it to Python3 because the developer prefers to play around
with PyPy instead (Python implementation in Python). On the other hand
the project is likely to bring up some speed benefits, too.
Anyway, I can live with Python2.6 if need be. from __future__ import
division, print_function ...
b0rsuk
b0rsuk
(snip)
oops, wrong link. This is the link to the benchmark I used (if I
remember correctly)
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&lang2=cint&box=1
b0rsuk
Enne
> What LUA can do what I can't do in C++?
Higher-order functions. (Closures without template chicanery.) Native
coroutines. Dynamic classes.
> Switching from C++ to LUA for entire game will be kind of downgrade.
I think few folks are advocating that perspective, but I honestly
don't think that many roguelikes are doing heavy enough work that it
would be a serious performance downgrade. Maybe for some vision
systems or Dwarf Fortress, but not in the general case.
-Enne
Radomir Dopieralski
> Typeless variables and tables are not considered as simplification.
That's not true, it speeds up development considerably, letting you
to get from "doesn't work" to "works and ca be tested" fast. Also
skipping the "doesn't compile" step helps here.
Garbage collection is another great help.
Radomir Dopieralski
> That benchmark... Python is 200x slower than C++? And Lua is only 30x
> slower?!
>
> And I was hoping to re-design my RL in Python, because I'm all burned
> out on C++ and my master thesis is going to be coded in C++ already,
> so I'd better pick another (easier?) language in order for RL
> development to be fun again instead of feeling like... work =|
Sure, it's slower if you count the computations only. But you are not
writing a heavy-duty arithmetics package, you are writing a turn-based
game that is going to be I/O bound. Even a fully-animated, real-time
game is going to be limited by the speed of the graphics card and disk,
rather than CPU. Choosing a harder to maintain language just because of
speed doesn't look like a good decision here.
Another thing to point out is that C++ is indeed faster when the program
is written optimally, but you are not likely to do that -- you will just
write whatever works fast enough and move on. This means sloppy
implementations of low-level algorithms and data structures, versus well
tested and optimized implementations in a "batteries included" language
like Python. In the end it pretty much evens out, except for the
maintenance costs.
Radomir Dopieralski
> 2) Both python and perl are dynamic languages and allow dynamic
> modules importing.
> It's impossible to track all modules that are used by program.
> It's impossible (in general case) to make single independent .exe
> unless all python modules are packed into it.
> You need to imply some limitations while developing program,
> and carefully select modules that are used in order to make
> it compatible with this tool.
Sure, there are some modules that require manual inclusion. All well
documented on the py2exe site. Unless of course you don't know what
your own program uses, but then I'd look for defects elsewhere.
I can assure you that py2exe works just fine and is widely used by
lots of small and large projects. Ever used BitTorrent? It's "compiled"
with py2exe.
I'm using it myself. It works, and your comments can't really change it.
> I've seen several games written in Python.
> Can't say that it was good experience.
I've also seen some amateur games written in C++, and can't say
anything good about them either. Remember that 90% of everything
sucks.
Isaac Gouy
> On Feb 11, 6:14 pm, Jotaf <jota...@hotmail.com> wrote:
>
> > That benchmark... Python is 200x slower than C++? And Lua is only 30x
> > slower?!
>
> Here's what I think is a more balanced benchmark:
-snip-
> Feel free to point out flaws in above ranking.
1) From your later post it seems you intended to show a ranking of 6
month old measurements from an Intel Pentium 4 machine - so one flaw
would be it's based on old hardware.
2) That ranking is based on a single number, the geometric mean - so
another flaw would be comparing a single number instead of comparing a
range of measurements.
3) Newer hardware is multi-core - so another flaw would be not
considering how easy or difficult it might be to exploit multi-core in
different programming languages, and what effect that might have.
Here are boxplots for those benchmarks measured on a quad-core
machine (just g++, LuaJIT, Lua and Python) - note that some of the
Python programs do seem to have taken >300x
Here is a direct comparison between g++ and Python for those
benchmarks on a quad-core machine - note that 4 of the Python programs
do seem to have taken > 100x
http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=gpp&lang2=python&box=1
When your using the benchmarks game to compare just 2 programming
languages - use a direct comparison between them on all the
measurements - don't use an average.
When your using the benchmarks game to compare several programming
languages - use the boxplots - they summarize the measurements much
better than an average.
And remember, the benchmarks game now shows both one core measurements
and quad-core measurements.
Jeff Lait
> On Feb 11, 10:44 am, b0rsuk <jaze...@gmail.com> wrote:
>
> 3) Newer hardware is multi-core - so another flaw would be not
> considering how easy or difficult it might be to exploit multi-core in
> different programming languages, and what effect that might have.
Well, Python with its GIL means it is right out of that contest!
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Xecutor
> On Wed, 11 Feb 2009, Matthew Allen wrote:
> > On Feb 11, 4:02 am, Xecutor <konstantin.stup...@gmail.com> wrote:
> >> The problem is not in "can't".
> >> The problem is in "can".
> >> What LUA can do what I can't do in C++?
> >> Switching from C++ to LUA for entire game will be kind of downgrade.
>
> I am starting to assume your are deliberately trolling around. If you
> looked at the replies (which I doubt by now), you would have seen that no
> one recommended going all lua. You would also have seen that lua has been
Here is starting post of this branch:
===cut
Since you're all saying that scripting languages can simplify
programming so much, why restrict their use to a couple modules? Why
not use them for the whole thing? Give me one good reason.
Jotaf
===cut
> used to good effect. I mention again that this is the case of DCSS.
>
> >> Yeah yeah, I know that LUA can compile code at runtime.
> >> But this is required for really small part of game, if required at
> >> all.
> >> So, probably LUA is good for plugin/addon-like system,
> >> but not for entire game development.
> >> Probably 'powerful' is not correct term...
> >> There is nothing in LUA to simplify game development.
> >> Typeless variables and tables are not considered as simplification.
> >> In long term perspective it's just source of errors.
>
> While each of the sentences above has some justification, the total
> picture they give seems far off. I didn't want to reply to Xecutor's
> rant...
>
> > Ah, this makes a lot more sense. I agree 100%.
>
> ...but this seems to indicate he is successful in spreading half-truths. I
> don't think lua should be used as a replacement for a programming
> language. It may be true that using it (in addition to C++, say) is only a
> real benefit to larger projects, I cannot say. But lua definitely has
> proved its worth in a great number of projects, including games of all
> types, including roguelikes.
This is discussion. Everyone is expressing their own opinions.
I can't understand so excessive reaction to my posts.
Here is some basement to my opinion.
I have 12 years of professional experience in software development.
Not game development however...
During this years I tried a lot of different programming languages.
At some point I did several pretty big perl projects.
When I was using perl intensively I passed Brain Bench perl test
and took 1st place in the world.
And I can say that support of big project written in perl
is painful even if this projects are well designed and documented.
I also have experience in support of python and php project.
Problems that arose there were a little different, but in general
absence of strict typing and the fact that some errors
are moved from compile time to runtime doesn't makes thing better.
Only a true genius can write flawless code from the first try.
Normal software development cycle includes bugs fixing.
And dynamic languages in general case require 100% code coverage
to make sure that there are no typos.
And the bigger is the project, the harder it is to make such tests.
Actually for medium sized projects programming language doesn't really
matter.
Only the one who is using it is important :)
I think that for 7DRL sized projects scripting languages
can be preferred over java/c++ etc, if you are experienced with this
language.
Returning to original topic:
IMHO there is no sense in using LUA in a project maintained by single
person.
If project is developed by community or by team that consist
of developer and game designer, and the later isn't experienced in
programming, than it could be a better solution.
But not necessarily.
Xecutor
Ok. Let's come to conclusion.
Programming language doesn't really matter as long as:
1) Software written in it is of suitable quality.
2) Software written in it doesn't cause implicit negative user
experience.
David Ploog
> On Feb 11, 9:29 pm, David Ploog <pl...@mi.fu-berlin.de> wrote:
>> I am starting to assume your are deliberately trolling around. If you
>> looked at the replies (which I doubt by now), you would have seen that no
>> one recommended going all lua. You would also have seen that lua has been
> So, Jotaf is 'no one' than.
> Here is starting post of this branch:
> ===cut
> Since you're all saying that scripting languages can simplify
> programming so much, why restrict their use to a couple modules? Why
> not use them for the whole thing? Give me one good reason.
> Jotaf
> ===cut
Ah, okay. But that was a question, not someone saying "It's best to use
lua, no matter what." IIRC, all who spoke out for lua in some fashion made
remarks that it's not the solution at all problems etc.
[snip sentences]
> This is discussion. Everyone is expressing their own opinions.
> I can't understand so excessive reaction to my posts.
Everyone else tries to be moderate in his judgement, when you are going
for 100% statements -- after the discussion! I admit my reaction was too
harsh, but in some sense your post was a "final word on the topic" mail,
which I felt misleading.
> Here is some basement to my opinion.
> I have 12 years of professional experience in software development.
> Not game development however...
Hey, I am a non-coding designer :)
> Returning to original topic:
> IMHO there is no sense in using LUA in a project maintained by single
> person. If project is developed by community or by team that consist
> of developer and game designer, and the later isn't experienced in
> programming, than it could be a better solution.
> But not necessarily.
This sounds more reasonable, yes. Note that in DCSS lua is not the
interface between coders and an cod-illiterate designer (me). I am very
confident that lua would be there without me.
In a way, this thread boiled from "what good is lua" to the classical
flamewar about best programming language for roguelikes. But now we + know
that compile vs script is as dangerous a topic as emacs vs vi.
Cheers,
David
Xecutor
that it's much harder to design good game, than code it :)
Now I'm remaking magic system for the third time :(
flammifer
> On Feb 11, 9:29 pm, David Ploog <pl...@mi.fu-berlin.de> wrote:> On Wed, 11 Feb 2009, Matthew Allen wrote:
> > I am starting to assume your are deliberately trolling around. If you
> > looked at the replies (which I doubt by now), you would have seen that no
> > one recommended going all lua. You would also have seen that lua has been
>
> So, Jotaf is 'no one' than.
> Here is starting post of this branch:
> ===cut
> Since you're all saying that scripting languages can simplify
> programming so much, why restrict their use to a couple modules? Why
> not use them for the whole thing? Give me one good reason.
> Jotaf
> ===cut
>
I guess you interpreted Jotaf's comment differently from me :)
I read it more as "Lua has some features that make it good for
implementing some parts of the game; why not choose a language that
has those features to code the whole game, and avoid the hassle of
dealing with two languages?" ... without implying that lua itself was
that ideal language of choice.
I develop my private projects in Python, so I'd agree with that
interpretation - making the whole game in a scripting language does
work, though whether it's the best choice depends a lot of your
experience with various languages, what kind of game you're making,
how you're distributing your game, whether performance is important,
etc.
b0rsuk
> > Feel free to point out flaws in above ranking.
>
> 1) From your later post it seems you intended to show a ranking of 6
> month old measurements from an Intel Pentium 4 machine - so one flaw
> would be it's based on old hardware.
Unfortunately this is the only benchmark out there that contains
Python Psyco, and as a Python enthusiast I consider it very
interesting.
> 2) That ranking is based on a single number, the geometric mean - so
> another flaw would be comparing a single number instead of comparing a
> range of measurements.
Still better than the other benchmark - solely on mandelbrot, which
implies that Python is 200x slower in all cases.
> Here are boxplots for those benchmarks measured on a quad-core
> machine (just g++, LuaJIT, Lua and Python) - note that some of the
> Python programs do seem to have taken >300x
>
> http://shootout.alioth.debian.org/u32q/benchmark.php?test=all〈=al...
>
> Here is a direct comparison between g++ and Python for those
> benchmarks on a quad-core machine - note that 4 of the Python programs
> do seem to have taken > 100x
In the P4 benchmarks, there are five programs > 100x
mandelbrot (107)
meteor_contest (261)
n-body (138)
recursive (285)
spectral-norm (137)
So these are potential bottlenecks. Psyco (JIT) does a lot to help:
mandelbrot (50)
meteor_contest (110)
n-body (34)
recursive (15)
spectral-norm (20)
Function calls are said to be costly in Python. Psyco optimizes
function calls. For these benchmarks where Python performs so badly,
Psyco offers at least 2x improvement.
I can't say much about multi-core benchmarks, but it has to be said
that for most part multicore CPU's are sitting idle because it's just
hard to take advantage of them. People are still arguing _if_ threads
and processes are the way to go, nevermind how to do them correctly.
And threads can no longer be considered more lightweight.
There are other approaches to concurrency, like green threads,
microthreads, continuations etc that make my head spin. Green/
microthreads are supposedly very lightweight. If I remember correctly
Erlang is supposedly good at that sort of thing, but also has a
reputation of being 'autistic' ;-). I'm not arguing for either of
these approaches, I just wait until dust settles.
Stackless Python implements most/all of the abovementioned techniques.
EVE Online uses Stackless and it enables it to support over 50 000
players on a _single_ server. Note that Stackless is still affected by
GIL and can't share these threads among cores. But with results like
these, you can start questioning the need for multicore execution.
Granted, some tasks are easy to perform in concurrent fashion
(Raytracing, which is why Intel is hyping it so much)
b0rsuk
Isaac Gouy
> On Feb 11, 9:41 pm, Isaac Gouy <igo...@yahoo.com> wrote:
>
> > On Feb 11, 10:44 am, b0rsuk <jaze...@gmail.com> wrote:
>
> > 3) Newer hardware is multi-core - so another flaw would be not
> > considering how easy or difficult it might be to exploit multi-core in
> > different programming languages, and what effect that might have.
>
> Well, Python with its GIL means it is right out of that contest!
Fork processes?
If we don't want to consider multi-core -
Jeff Lait
> On Feb 11, 8:26 pm, Jeff Lait <torespondisfut...@hotmail.com> wrote:
>
> > On Feb 11, 9:41 pm, Isaac Gouy <igo...@yahoo.com> wrote:
>
> > > On Feb 11, 10:44 am, b0rsuk <jaze...@gmail.com> wrote:
>
> > > 3) Newer hardware is multi-core - so another flaw would be not
> > > considering how easy or difficult it might be to exploit multi-core in
> > > different programming languages, and what effect that might have.
>
> > Well, Python with its GIL means it is right out of that contest!
>
> Fork processes?
"how easy or difficult it might be..."
Python's threading is fun and easy to play with. So one might think
Python would be great for multicore. But then you hit the GIL. If
your "solution" is to fork you've thrown away the whole nice threading
environment of Python and might as well be writing C++.
Ido Yehieli
Well, it seems Guido believes using processes instead of threads is
the way to go:
http://mail.python.org/pipermail/python-3000/2007-May/007414.html
"Nevertheless, you're right the GIL is not as bad as you would
initially think: you just have to undo the brainwashing you got from
Windows and Java proponents who seem to consider threads as the only
way to approach concurrent activities.
Just because Java was once aimed at a set-top box OS that didn't
support multiple address spaces, and just because process creation in
Windows used to be slow as a dog, doesn't mean that multiple processes
(with judicious use of IPC) aren't a much better approach to writing
apps for multi-CPU boxes than threads."
-Ido.
zai...@zaimoni.com
> On 12 Lut, 03:41, Isaac Gouy <igo...@yahoo.com> wrote:
> > 2) That ranking is based on a single number, the geometric mean - so
> > another flaw would be comparing a single number instead of comparing a
> > range of measurements.
Geometric mean is actually better than arithmetic mean here; it keeps
catastrophic behavior from mismatches between the language and the
problem from completely dominating the rating.
> > Here are boxplots for those benchmarks measured on a quad-core
> > machine (just g++, LuaJIT, Lua and Python) - note that some of the
> > Python programs do seem to have taken >300x
>
> >http://shootout.alioth.debian.org/u32q/benchmark.php?test=all〈=al...
>
> > Here is a direct comparison between g++ and Python for those
> > benchmarks on a quad-core machine - note that 4 of the Python programs
> > do seem to have taken > 100x
>
> In the P4 benchmarks, there are five programs > 100x
> mandelbrot (107)
> meteor_contest (261)
> n-body (138)
> recursive (285)
> spectral-norm (137)
Mandelbrot, n-body, and spectral-norm are completely unsurprising. I
bet all five of these completely swamp Python by requiring dynamic
allocation/deallocation of hordes of temporaries. (One of my in-house
Python applications, an area-averaging image resizer, has the same
issue.)
> So these are potential bottlenecks. Psyco (JIT) does a lot to help:
> mandelbrot (50)
> meteor_contest (110)
> n-body (34)
> recursive (15)
> spectral-norm (20)
Perhaps Psyco should be merged into mainline Python once the version
shock from 3.0 intentionally breaking "almost all large" Python 2.x
scripts shakes out?
Isaac Gouy
> On Feb 12, 5:10 am, b0rsuk <jaze...@gmail.com> wrote:
>
> > On 12 Lut, 03:41, Isaac Gouy <igo...@yahoo.com> wrote:
> > > 2) That ranking is based on a single number, the geometric mean - so
> > > another flaw would be comparing a single number instead of comparing a
> > > range of measurements.
>
> Geometric mean is actually better than arithmetic mean here; it keeps
> catastrophic behavior from mismatches between the language and the
> problem from completely dominating the rating.
The arithmetic mean is not shown - so the advantage of the geometric
mean over the arithmetic mean is irrelevant.
The point is that boxplots provide a better summary of the
measurements than a single number ranking.
Drakalor Tourist
> Why should I include Lua scripting?
>
> - Gio
I just wanted to put my two cents in quick, even though this whole
thread has been beaten to death. As a Lua fan, I have to say that the
rapid prototyping ability, as well as the ease of use, more than make
up for any speed issues, at least on modern PCs. I'm somewhat
surprised there hasn't been any RLs made mostly in Lua yet, at least
for a 7drl or the like, given it's naturally rapid development.
I'm working on a game currently that is mostly done in Lua, and only
uses C++ as a curses wrapper. So far, speed has not been an issue,
although, to be fair, I have yet to implement A* (just using dumb
pathfinding at present) or FOV, although I'm debating leaving FOV out
for gameplay reasons.
Working from a data/script first, engine later approach seems to be
working somewhat well. I designed a few sample level/monster/item/etc
scripts that would reflect what I want my game to be capable of, and
then built up a game that could run the aforementioned scripts. Lua's
made it pretty easy so far, and I've made far more progress on my
current game than I ever have on a C++ exclusive game. Although,
admittedly, I'm not a very talented programmer. But that's part of my
argument. Lua is just plain easy to use, and renders complex data
structures and algorithms trivial to implement.
Anyway, just my opinion on the matter.
Jeff Lait
> On Feb 12, 5:17 pm, Jeff Lait <torespondisfut...@hotmail.com> wrote:
>
> > On Feb 12, 11:06 am, Isaac Gouy <igo...@yahoo.com> wrote:
>
> > > Fork processes?
>
> > "how easy or difficult it might be..."
>
> > Python's threading is fun and easy to play with. So one might think
> > Python would be great for multicore. But then you hit the GIL. If
> > your "solution" is to fork you've thrown away the whole nice threading
> > environment of Python and might as well be writing C++.
>
> Well, it seems Guido believes using processes instead of threads is
> the way to go:
Well, he's wrong.
> http://mail.python.org/pipermail/python-3000/2007-May/007414.html
>
> "Nevertheless, you're right the GIL is not as bad as you would
> initially think: you just have to undo the brainwashing you got from
> Windows and Java proponents who seem to consider threads as the only
> way to approach concurrent activities.
The brainwashing does not come from Java and Windows people. It comes
from the Python language itself. The Python language encourages the
use of threads for multitasking. Having formulated your problem with
Queues, shared memory, and locks (all of which the Python language
exposes!) it is not the least bit unreasonable for someone to merely
assume that these separate threads could run on different cores. The
fact they don't is an embarrassing deficiency in Python.
> Just because Java was once aimed at a set-top box OS that didn't
> support multiple address spaces, and just because process creation in
> Windows used to be slow as a dog, doesn't mean that multiple processes
> (with judicious use of IPC) aren't a much better approach to writing
> apps for multi-CPU boxes than threads."
Multiple processes certainly have their uses. And, all things being
equal, are a cleaner way to decouple the problem. Further, they have
the nice advantage of easily scaling into a distributed system since
you have well controlled communication channels.
Of course, all else isn't equal, and the task of properly marshaling
your world in an efficient manner across IPC is a real pain. As a
programmer, the vectorization of a loop across N processes should be
as transparent as possible. This is a lot easier to achieve in shared-
memory thread models than in IPC models.
Eg, I want to multicore this:
foreach monster in map:
monster->fovcache = map->buildFOV(monster->position)
If I have to marshall the map across processes, I'll likely need a
ridiculous number of monsters to make up for the one-time cost. Or I
get to carefully optimize my map structure for ease of transmission,
yay!
zai...@zaimoni.com
wrote:
> On Feb 7, 1:54 am, Gio <gioman...@sbcglobal.net> wrote:
>
> > Why should I include Lua scripting?
>
> > - Gio
>
> I just wanted to put my two cents in quick, even though this whole
> thread has been beaten to death. As a Lua fan, I have to say that the
> rapid prototyping ability, as well as the ease of use, more than make
> up for any speed issues, at least on modern PCs. I'm somewhat
> surprised there hasn't been any RLs made mostly in Lua yet, at least
> for a 7drl or the like, given it's naturally rapid development.
Agreed.
Lua is so close to C in coding style* and idioms, that the only real
reason to prefer C to Lua as the sole language of a roguelike is
personal fluency.
* as viewed by someone whose dominant languages are C++ and Perl. The
few blindingly obvious differences to a novice, are all in favor of
Lua.
Gelatinous Mutant Coconut
> few blindingly obvious differences to a novice, are all in favor of
> Lua.
One major advantage of Lua that I just considered is that (very
lightweight) interpreter executables exist for a very wide variety of
systems:
http://luaforge.net/frs/?group_id=110
(Look under "Executables")
I'm very much in favor of source code distribution, but it's always
nice to be able to give people working binary packages if possible.
I've always had difficulty getting compilers setup in Windows, so
being able to hand out a zip file with an interpreter and some LUA
script sounds pretty tempting.
Maybe I need to give the language a second look.
Martin Read
>I just wanted to put my two cents in quick, even though this whole
>thread has been beaten to death. As a Lua fan, I have to say that the
>rapid prototyping ability, as well as the ease of use, more than make
>up for any speed issues, at least on modern PCs. I'm somewhat
>surprised there hasn't been any RLs made mostly in Lua yet, at least
>for a 7drl or the like, given it's naturally rapid development.
Large parts of TOME and its variants are implemented in LUA.
--
\_\/_/ turbulence is certainty turbulence is friction between you and me
\ / every time we try to impose order we create chaos
\/ -- Killing Joke, "Mathematics of Chaos"
Jotaf
> I'm working on a game currently that is mostly done in Lua, and only
> uses C++ as a curses wrapper.
> Lua's
> made it pretty easy so far, and I've made far more progress on my
> current game than I ever have on a C++ exclusive game.
This is pretty convincing. There are only two issues that make me
hesitate between Python and Lua:
- Fearing a death trap of Pythonic slowness later down the road (my
only qualm really); and...
- The fact that there's no interface of libtcod to Lua yet. (Although
I could probably fix that given some time.)
Jotaf
Mario Lassnig
> On 13 Fev, 19:34, Drakalor Tourist <drakalor.tour...@gmail.com> wrote:
>> I'm working on a game currently that is mostly done in Lua, and only
>> uses C++ as a curses wrapper.
>> ...
>> Lua's
>> made it pretty easy so far, and I've made far more progress on my
>> current game than I ever have on a C++ exclusive game.
>
> This is pretty convincing. There are only two issues that make me
> hesitate between Python and Lua:
>
> - Fearing a death trap of Pythonic slowness later down the road (my
> only qualm really); and...
We are using Python at work to manage Petabytes of data in distributed
systems. It's very computationally and memory-intensive.
If there is any reason for such a thing as "slow" Python code, then
it's because you don't write "Python" code, but Java/C/C++/whatever code
with a Python syntax.
flammifer
> Jotaf wrote:
> > - Fearing a death trap of Pythonic slowness later down the road (my
> > only qualm really); and...
>
> We are using Python at work to manage Petabytes of data in distributed
> systems. It's very computationally and memory-intensive.
> If there is any reason for such a thing as "slow" Python code, then
> it's because you don't write "Python" code, but Java/C/C++/whatever code
> with a Python syntax.
Seconded; a friend of mine made Slune (home.gna.org/oomadness/en/
slune/, though the website may be down) a realtime 3D game in python -
and that was maybe 8 years ago. With today's machines and today's
python, I don't think a turn-based game with ASCII art would have
major performance issues (... maybe if you're doing complicated line
of sight / lighting calculation, or AI for all the NPCs on the map and
you have a lot of them ...) - and if you do, you can still rewrite the
slow parts in C or C++, Python supports that pretty well (come to
think of it, that's pretty much the opposite of Lua scripting :D).
Isaac Gouy
> On 12 Lut, 03:41, Isaac Gouy <igo...@yahoo.com> wrote:
>
> > > Feel free to point out flaws in above ranking.
>
> > 1) From your later post it seems you intended to show a ranking of 6
> > month old measurements from an Intel Pentium 4 machine - so one flaw
> > would be it's based on old hardware.
>
> Unfortunately this is the only benchmark out there that contains
> Python Psyco, and as a Python enthusiast I consider it very
> interesting.
Yes Psyco is interesting, although the ongoing work seems to have
moved to PyPy - as a Python enthusiast made you have enough interest
to do a Great Python Shootout like "The Great Ruby Shootout"
http://antoniocangiano.com/2008/12/09/the-great-ruby-shootout-december-2008/
As a Python enthusiast you wouldn't have any problems using The
Benchmarks Game python measurement programs ;-)
http://shootout.alioth.debian.org/u32q/faq.php#measurementscripts
-snip-
> I can't say much about multi-core benchmarks, but it has to be said
> that for most part multicore CPU's are sitting idle because it's just
> hard to take advantage of them.
-snip-
> Granted, some tasks are easy to perform in concurrent fashion
> (Raytracing, which is why Intel is hyping it so much)
Already people have contributed programs that effectively exploit
naive parallelism in 6 of the benchmarks game tests.