builtin lists and Intel SSE support?
Brandon J. Van Every
1) runs on Windows
2) has support for lists in the language syntax itself, not just as a
standard library
3) supports Intel SSE instructions in some manner
Regarding (3), it could be inline ASM, builtin compiler functions, or some
other form of tedious manual labor. I'm not expecting automagical Intel SSE
compiler support, although indeed that would be nice if it existed.
The application domain, if you want to know, is pathfinding on a 3D model of
a planet. Currently I'm looking at using a node / graph approach, and it
promises to be both list heavy and vector heavy.
BTW these are hard requirements for purposes of this question. If I was
willing to forego (2), I could of course use C++. If I forego (3), I'm
aware of tons of options, I don't need to be asking the question. And I'm
certainly not going to give up both (2) and (3), let alone (1) !
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
When no one else sells courage, supply and demand take hold.
Vincenzo aka Nick Name
> Cheers, www.indiegamedesign.com
So you use functional languages for game design ? It would be worth if, when
you have experiences, you posted it here. Sorry for mess with verbs :)
V.
Matthew Danish
> Can anyone tell me of a language + compiler that
>
> 1) runs on Windows
> 2) has support for lists in the language syntax itself, not just as a
> standard library
> 3) supports Intel SSE instructions in some manner
There are 3 native-code compilers for Common Lisp which run in Windows,
that I am aware of: Xanalys LispWorks, Franz Allegro CL, and Corman CL.
I don't know about the SSE support, but most Lisp compilers include some
way to tinker with/extend the compiler and any commercial vendor would
be willing to write custom patches, I imagine, for a price of course.
--
; Matthew Danish <mda...@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Brandon J. Van Every
> On Thu, Jan 22, 2004 at 02:51:48PM -0800, Brandon J. Van Every wrote:
>> Can anyone tell me of a language + compiler that
>>
>> 1) runs on Windows
>> 2) has support for lists in the language syntax itself, not just as a
>> standard library
>> 3) supports Intel SSE instructions in some manner
>
> There are 3 native-code compilers for Common Lisp which run in
> Windows, that I am aware of: Xanalys LispWorks, Franz Allegro CL, and
> Corman CL. I don't know about the SSE support, but most Lisp
> compilers include some way to tinker with/extend the compiler and any
> commercial vendor would be willing to write custom patches, I
> imagine, for a price of course.
Well, writing custom patches really doesn't fulfil the criteria. No
industrial strength testing, no real world provenness, and it would send
alarm bells in my head if a compiler claimed to be performance oriented and
didn't have the capability already.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed Mckenzie
Joachim Durchholz
> Can anyone tell me of a language + compiler that
>
> 1) runs on Windows 2) has support for lists in the language syntax
> itself, not just as a standard library
This is a bit difficult to answer for your typical functional language.
Most FPLs have an in-language definition of lists, but implement them in
the compiler anyway. Most also have some (actually very little)
syntactic sugar for lists (less than for monads, if you measure size in
terms of the complexity of the map-to-the-unsugared-kernel-language
transformation).
> 3) supports Intel SSE instructions in some manner
>
> Regarding (3), it could be inline ASM, builtin compiler functions, or
> some other form of tedious manual labor.
Would a C interface qualify? You could do the SSE stuff in C with inline
assembly, or in assembly with C linkage.
BTW there's another approach, exemplified in the FFTW package
(http://www.fftw.org/).
It's advertised as a C package for fast Fourier transforms; it gets its
speed by generating C code that exploits any special properties that
your particular transformation demand might have (e.g. if you know that
your matrices are always square and have a power-of-two size, FFTW will
generate C code that's optimized for this case).
Somewhere hidden in the pages is the hints that FFTW is written in a
functional language.
It's very easy to process simple languages in functional languages;
lexers are generally available, simple recursive-descent parsers can be
done at the drop of a hat, and tree transformations are far simpler than
in imperative languages (though the latter unrelated to imperativeness,
the main reason why the latter is to easy comes from pattern matching).
This becomes interesting if you have your SSE model code but are
dissatisfied with it; you'd like to vary it (to adapt it to new
requirements, or just for tweaking to squeeze another percent out of
it), but variation would involve large-scale changes.
If you can express your SSE code as a set of "codelets" plus some rules
how to comine them, a functional language is most definitely the best
choice for generating that SSE stuff.
Note that this is *not* a roll-your-own SSE compiler. The codelets are
still assembly (or C). It might grow into an SSE compiler if you
continue to tweak and generalize it, but full generality is definitely
not necessary for the first go.
> I'm not expecting automagical Intel SSE compiler support, although
> indeed that would be nice if it existed.
I don't think that this exists.
Your best bet is probably a C interface (the standard term for this in
the functional arena is FFI, for Foreign Function Interface - I'm not
sure wether that FFI nomenclature implies a real difference with the
usual C interface stuff, or whether it's just elaborate terminology).
Regards,
Jo
--
Currently looking for a new job.
Robert Bruce Carleton
Corman lisp has support for assembler. I haven't used it, but I can
provide some excerpts from the user manual on it. I don't think Roger
Corman will mind that. The user manual is part of the Corman lisp
evaluation download:
The web site is:
--snip--
The following example shows how to create an entire function in
assembler. There are many more examples of this in the Corman Lisp
source file kernel-asm.lisp. To use assembler, you must understand the
way Lisp objects are tagged (see the section on Lisp Data Structures).
DEFASM
Example:
;;;;
;;;; Common Lisp IDENTITY function.
;;;;
(defasm identity (obj)
{
push ebp ;; maintain stack frame
mov ebp, esp ;; maintain stack frame
cmp ecx, 1 ;; number of args = 1?
je short :next ;; if yes, branch
callp _wrong-number-of-args-error ;; else error
:next
mov eax, [ebp + ARGS_OFFSET] ;; eax = first arg
mov ecx, 1 ;; returning 1 value
pop ebp ;; maintain stack frame
ret
})
DEFCODEGEN
Another use of assembler is to define special code generation code for
the compiler,
using DEFCODEGEN.
Example:
(defcodegen call-com-method (form dest)
(let* ((vtable-index (cadr form)))
(parse-assembler
{
mov eax, [esp] ;; eax -> interface
mov eax, [eax] ;; eax -> vtable
call [eax + (* 4 vtable-index)]
})))
Mixing Assembler With Common Lisp Code
A third method of embedding assembler into source code allows you to mix
Lisp source and assembly code. Note the double curly braces surrounding
the embedded assembly code.
Example:
(defun foo (x)
(format t "Called foo...")
{{
mov eax, [ebp + ARGS_OFFSET]
mov ecx, 1
}})
Some assembler operators are not yet implemented, and not all addressing
modes are supported. Only 8-bit and 32-bit operations are supported for
most instructions, with MOV as the notable exception. You can browse the
assembler source code (operators are defined with DEFOP) to see which
operators are available.
DEFASM-MACRO
Assembler macros are supported via DEFASM-MACRO (in the X86 package).
Example:
(defasm-macro callf (sym)
(let* ((env-offset (* (uref sym symbol-jump-table-offset) 4))
(jump-offset (+ env-offset 4)))
(if (zerop env-offset)
(error "The function ~A does not have a jump table offset" sym))
{
mov edi, [esi + env-offset]
call [esi + jump-offset]
}))
Brandon J. Van Every wrote:
John Thingstad
I am not sure I undestand the last criteria.
SSE is hardware support for various operations usually used in linear
algeba used mostly for 3d gaphics.
It consists of macinecode instructions and the best way to access them
directly is through assembler.
As for languages supporting it directly none exist.
http://www.tommesani.com/Download/QuexalDemo.exe
contains a program that can help generate and debug SSE code and make a C
wapper and the like.
What you seem to want though is just to make sure it uses the harware to
handle vector operations fast.
In this case high level libaries like DirectX or OpenGL should provide you
with what you neeed.
These libraies can of course be accessed from lisp (or any other language
for that matter)
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Frank Andreas de Groot
message
> Can anyone tell me of a language + compiler that
>
> 1) runs on Windows
Delphi (I hope you are not angry that it *also* runs on Linux and *also* on .net
> 2) has support for lists in the language syntax itself, not just as a
> standard library
Delphi. The TList class is built in, for example.
> 3) supports Intel SSE instructions in some manner
Delphi. Its inline assembler (Since Delphi 6) supports MMX, SSE, SSE2 and 3DNOW!
Hope this helps,
Frank
Dave Roberts
> Can anyone tell me of a language + compiler that
>
> 1) runs on Windows
> 2) has support for lists in the language syntax itself, not just as a
> standard library
> 3) supports Intel SSE instructions in some manner
>
> Regarding (3), it could be inline ASM, builtin compiler functions, or some
> other form of tedious manual labor. I'm not expecting automagical Intel
> SSE compiler support, although indeed that would be nice if it existed.
>
> The application domain, if you want to know, is pathfinding on a 3D model
> of
> a planet. Currently I'm looking at using a node / graph approach, and it
> promises to be both list heavy and vector heavy.
>
> BTW these are hard requirements for purposes of this question. If I was
> willing to forego (2), I could of course use C++. If I forego (3), I'm
> aware of tons of options, I don't need to be asking the question. And I'm
> certainly not going to give up both (2) and (3), let alone (1) !
Looks like Corman Lisp is a good bet (www.cormanlisp.com). I have never used
it, but just ran into it. Looks like it supports a full Intel assembler,
which would hopefully allow you to insert the SSE instructions you want.
And you'd have the full CL implementation with native compiler to do
anything else you want. Again, I don't have any experience with this
implementation. I just got everything above off the web site.
-- Dave
Brandon J. Van Every
> Brandon J. Van Every wrote:
>
>> 3) supports Intel SSE instructions in some manner
>>
>> Regarding (3), it could be inline ASM, builtin compiler functions, or
>> some other form of tedious manual labor.
>
> Would a C interface qualify? You could do the SSE stuff in C with
> inline assembly, or in assembly with C linkage.
It's a valid point, and one I realized belatedly. But for purposes of this
question, I think having a C interface doesn't count. C interfaces are
common. There are tons of languages that run on Windows, have builtin
lists, and have a C interface, so not really any need to ask the question.
I'd really like to find out if anything has first-class SSE support, such as
via compiler intrinsics or at least inline ASM. I also think such support
indicates a general concern with performance, instead of the "well, if you
need performance you can just do it in C" mentality.
> [using functional languages to generate SSE code]
>
> Note that this is *not* a roll-your-own SSE compiler. The codelets are
> still assembly (or C). It might grow into an SSE compiler if you
> continue to tweak and generalize it, but full generality is definitely
> not necessary for the first go.
I'm thinking this is a distraction from real work. I've done enough 3D
graphics problems with SSE by hand to feel that SSE is an awkward fit to 3D
graphics. I'm not expecting SSE to have general utility for all kinds of
problems, which is how you'd justify a codelet effort. Rather, there will
be times when a problem just happens to have a form that I could do in SSE.
More often than not, I'm stuck with the plain old X87 FPU stack.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
Brandon J. Van Every
> Brandon,
>
> Corman lisp has support for assembler. I haven't used it, but I can
> provide some excerpts from the user manual on it. I don't think Roger
> Corman will mind that. The user manual is part of the Corman lisp
> evaluation download:
>
> The web site is:
>
> http://www.cormanlisp.com/
Thanks! Since the devil is in the details, I wonder if their inline ASM
supports the full IA-32 instruction set? In Visual Studio, back in the bad
old days, when some newfangled instruction came out you had to EMIT it until
real support was available. Not really practical for more than trivial
usage.
Brandon J. Van Every
> On Thu, 22 Jan 2004 14:51:48 -0800, Brandon J. Van Every
> <try_vanevery_a...@yahoo.com> wrote:
>
>> Can anyone tell me of a language + compiler that
>>
>> 1) runs on Windows
>> 2) has support for lists in the language syntax itself, not just as a
>> standard library
>> 3) supports Intel SSE instructions in some manner
>
> SSE is hardware support for various operations usually used in linear
> algeba used mostly for 3d gaphics.
3D graphics, ha! You're making me laugh. In my experience, SSE was
designed for image processing and multimedia, not 3D graphics. For
instance, the lack of a "sum of scalar fields" instruction, essential for
dot products and rather helpful for matrices as well. We'll have to wait
for the Prescott New Instructions to get a half-assed fix for that, and
it'll still take 2 HADDPS instructions to do the job. Since the newfangled
chips with PNI will still be called "Pentium 4," how easy do you think it's
going to be to product spec that? But enough of this rant. Thanks for the
chuckle.
> http://www.tommesani.com/Download/QuexalDemo.exe
> contains a program that can help generate and debug SSE code and make
> a C wapper and the like.
Looks like that's only integer SSE code though. I'm mainly doing 32-bit
floats.
Brandon J. Van Every
>> standard library
>
> Delphi. The TList class is built in, for example.
I'm probably not being specific enough about what I want here. I don't want
class.method(blah) syntax. Too much verbiage! I want [a b c d e] or (a b c
d e), completely minimal syntax. Like what Python, Lisp, or OCaml have.
Frank A. Adrian
> Delphi. The TList class is built in, for example.
But I thought that TList was part of the VCL - a library - not part of the
core language. At least it was 3 or 4 years ago (the last time I used
Delphi). In reality, I'm not really sure what difference it makes and
why this is a requirement. Maybe what the OP is looking for is a
transparent list structure that can be manipulated by the SSE instructions?
faa
Frank A. Adrian
> Thanks! Since the devil is in the details, I wonder if their inline ASM
> supports the full IA-32 instruction set? In Visual Studio, back in the bad
> old days, when some newfangled instruction came out you had to EMIT it until
> real support was available. Not really practical for more than trivial
> usage.
If it doesn't, you also get the source code for the core system. The
assembler portion is simple enough that it can be easily extended to
support new instructions (and I'm sure that Roger would be grateful for
the contribution).
faa
Marcin 'Qrczak' Kowalczyk
>> Delphi. The TList class is built in, for example.
>
> I'm probably not being specific enough about what I want here. I don't want
> class.method(blah) syntax. Too much verbiage! I want [a b c d e] or (a b c
> d e), completely minimal syntax. Like what Python, Lisp, or OCaml have.
I also suspect that it has the same typing problem as Java collections,
i.e. requires a cast to get an object of the correct type.
--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Frank Andreas de Groot
>
> But I thought that TList was part of the VCL - a library - not part of the
> core language.
Just like C, Delphi has almost *nothing* in its core language.
Anyway, I strongly oppose using lists and tables that come with a language.
They are almost never half as fast as what you can make yourself in an hour or
two.
Edi Weitz
> Anyway, I strongly oppose using lists and tables that come with a
> language. They are almost never half as fast as what you can make
> yourself in an hour or two.
Sure. That's why we all still use assembly language exclusively.
Edi.
Brandon J. Van Every
Hrm... a strange mentality, is this common among Lisp folk? Why would I
want to use a tool to do something rather basic that isn't already complete?
To me that's a Complete Waste Of Time. Let alone pay for it, as Corman Lisp
is not free for commerical use. This is for a game I intend to make money
off of someday.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
Brandon J. Van Every
>
> Maybe what the OP is looking for is a
> transparent list structure that can be manipulated by the SSE
> instructions?
No, it would be pretty silly to use SSE to manipulate lists. I want (1)
lists with a highly convenient syntax like (a b c d e), (2) SSE capability
for 3D graphics problems. Bad fit to 3D graphics though it may be, it
sometimes can be useful.
Actually, I probably also want fullblown inline ASM support. Often you
don't get your Conditional Move instructions any other way.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
Brandon J. Van Every
> On Fri, 23 Jan 2004 09:33:27 -0800, Brandon J. Van Every wrote:
>
>>> Delphi. The TList class is built in, for example.
>>
>> I'm probably not being specific enough about what I want here. I
>> don't want class.method(blah) syntax. Too much verbiage! I want [a
>> b c d e] or (a b c d e), completely minimal syntax. Like what
>> Python, Lisp, or OCaml have.
>
> I also suspect that it has the same typing problem as Java
> collections,
> i.e. requires a cast to get an object of the correct type.
Yeah, I didn't bother to add dynamic typing as a requirement. I wanted to
see if it would emerge as some kind of inevitable byproduct of convenient
list syntax. I don't really want dynamic typing, but I do want my lists to
do what I want without me having to fuss over them.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
Marcin 'Qrczak' Kowalczyk
>> I also suspect that it has the same typing problem as Java
>> collections, i.e. requires a cast to get an object of the correct type.
>
> Yeah, I didn't bother to add dynamic typing as a requirement.
Proper typing of collection operations doesn't require dynamic typing!
See Haskell, OCaml, SML, Clean, Mercury, or just about any statically
typed functional language. For some reason most "mainstream" languages
are slowly starting to get it after 20 years it has been known how it
can be done.
Followup-To: comp.lang.functional
Will Hartung
message news:bus3ld$lse54$1...@ID-207230.news.uni-berlin.de...
> Frank A. Adrian wrote:
> > If it doesn't, you also get the source code for the core system. The
> > assembler portion is simple enough that it can be easily extended to
> > support new instructions (and I'm sure that Roger would be grateful
> > for the contribution).
>
> Hrm... a strange mentality, is this common among Lisp folk? Why would I
> want to use a tool to do something rather basic that isn't already
complete?
> To me that's a Complete Waste Of Time. Let alone pay for it, as Corman
Lisp
> is not free for commerical use. This is for a game I intend to make money
> off of someday.
Yeah, nothing like tossing the baby out with the bathwater.
Simply put, here is a system that just happens to meet all 3 of your
criteria:
> 1) runs on Windows
> 2) has support for lists in the language syntax itself, not just as a
standard library
> 3) supports Intel SSE instructions in some manner
But now you say "Oh, it must support the entire x86 instruction set", with
the justification that you didn't like emitting hex codes in systems that
didn't, even though it is no doubt utterly trivial to add pretty much any
op-code you want with this system, especially since you get the source code
to the ENTIRE THING. Not just the runtime library, not just the examples,
but to the core system and the COMPILER.
That simple fact, that the system with all of this capability, this system
that does EXACTLY what you asked for, the fact that it may not implement
some obscure x86 mnemonic, even though if you never uses that op-code, you'd
never miss it, even though it could be added in probably 10 minutes of work,
work done once, never to be done again, and integrated seemlessly with all
of the other "standard" op-codes, that simple detail disqualifies the ENTIRE
thing.
Oh, and of course, lest we forget, that sending the CRIPPLING, MIND NUMBING,
and 3rd World Debt overburdening license fee of $250 that will allow you to
do ANYTHING YOU WANT (with one minor, irrelevant caveat), without ever
sending Roger another NICKLE, FOREVER, that cast it out as well.
Just trying to make sure we're clear on the ground rules of this quest of
yours.
I won't even go into the fact that it also, on top of all of the other
details mentioned, happens to be Common Lisp.
Regards,
Will Hartung
(wi...@msoft.com)
Brandon J. Van Every
> On Fri, 23 Jan 2004 13:46:12 -0800, Brandon J. Van Every wrote:
>
>>> I also suspect that it has the same typing problem as Java
>>> collections, i.e. requires a cast to get an object of the correct
>>> type.
>>
>> Yeah, I didn't bother to add dynamic typing as a requirement.
>
> Proper typing of collection operations doesn't require dynamic typing!
> See Haskell, OCaml, SML, Clean, Mercury, or just about any statically
> typed functional language. For some reason most "mainstream" languages
> are slowly starting to get it after 20 years it has been known how it
> can be done.
Right, the *other* reason I didn't add dynamic typing as a requirement, is
because I'm fuzzy-headed about what it's good for, why I should want it, or
what it even is. Figuring I'm stupid on this point, I shouldn't ask for a
buzzword. Seems like dynamic typing means "anything can become anything,"
and for the low-level 3D graphics problems I'm currently worrying about,
that's the exact opposite of what I want. I've put a lot of trouble into
figuring out how much storage I want everything to use, and what the layout
is... why would I want to wreck that by adding dynamic typing?
Pascal Costanza
Brandon J. Van Every wrote:
> Frank A. Adrian wrote:
>
>>On Fri, 23 Jan 2004 09:20:19 -0800, Brandon J. Van Every wrote:
>>
>>>Thanks! Since the devil is in the details, I wonder if their inline
>>>ASM supports the full IA-32 instruction set? In Visual Studio, back
>>>in the bad old days, when some newfangled instruction came out you
>>>had to EMIT it until real support was available. Not really
>>>practical for more than trivial usage.
>>
>>If it doesn't, you also get the source code for the core system. The
>>assembler portion is simple enough that it can be easily extended to
>>support new instructions (and I'm sure that Roger would be grateful
>>for the contribution).
>
> Hrm... a strange mentality, is this common among Lisp folk?
Yes.
> Why would I
> want to use a tool to do something rather basic that isn't already complete?
Because you don't want to wait for some vendor to add full support for
the things you actually need right now? Because these things are
generally almost trivial to do in Lisp? Because there is no real
distinction between core language and APIs in Lisp?
> To me that's a Complete Waste Of Time.
What you probably want is a high-level language that ultimately emits
proprietary instructions. This is almost trivial to do with Lisp-style
macros. If you don't get a complete solution that is optimal for your
task right out of the box in another language, it's very likely that
Lisp will get you to a workable and seamless solution in a very short
amount of time.
> Let alone pay for it, as Corman Lisp
> is not free for commerical use. This is for a game I intend to make money
> off of someday.
Then it should be an advantage that you have based your software on a
proprietary solution that your competitors will have trouble to catch up
with.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Brandon J. Van Every
> "Brandon J. Van Every" <try_vanevery_a...@yahoo.com>
> wrote in message news:bus3ld$lse54$1...@ID-207230.news.uni-berlin.de...
>> Frank A. Adrian wrote:
>>> If it doesn't, you also get the source code for the core system.
>>> The assembler portion is simple enough that it can be easily
>>> extended to support new instructions (and I'm sure that Roger would
>>> be grateful for the contribution).
>>
>> Hrm... a strange mentality, is this common among Lisp folk? Why
>> would I want to use a tool to do something rather basic that isn't
>> already complete? To me that's a Complete Waste Of Time. Let alone
>> pay for it, as Corman Lisp is not free for commerical use. This is
>> for a game I intend to make money off of someday.
>
> Yeah, nothing like tossing the baby out with the bathwater.
Where's the baby?
> Simply put, here is a system that just happens to meet all 3 of your
> criteria:
>
>> 1) runs on Windows
>> 2) has support for lists in the language syntax itself, not just as
>> a standard library
>> 3) supports Intel SSE instructions in some manner
It has not been verified that Corman Lisp actually fulfils (3). In fact,
one person says it doesn't.
> That simple fact, that the system with all of this capability,
"All of this capability" doesn't appear to be including the capability I
want. MS Word has a lot of capabilities. You don't see me asking for it as
high performance programming language, do you?
> Oh, and of course, lest we forget, that sending the CRIPPLING, MIND
> NUMBING, and 3rd World Debt overburdening license fee of $250 that
> will allow you to do ANYTHING YOU WANT (with one minor, irrelevant
> caveat), without ever sending Roger another NICKLE, FOREVER, that
> cast it out as well.
I don't hand over $250 for products that don't meet my criteria.
Even if Corman Lisp were free for commercial use, I don't look for
opportunities to gratuitously implement stuff. "It'll take 10 minutes" is
bullshit. By the time you actually get through understanding, designing,
coding, testing, redesigning, and real world shaking out of bugs, it'll take
weeks or months. And if you don't understand that, then you don't code
commercially. Or else you are completely insulated from any financial
impacts, i.e. you're someone's employee, and you sit around wasting a lot of
your employer's time and money implementing stupid stuff like that. Those
of us bearing our own development costs, want things off-the-shelf that save
us labor.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
Brandon J. Van Every
> Brandon J. Van Every wrote:
>>
>> Why would I
>> want to use a tool to do something rather basic that isn't already
>> complete?
>
> Because you don't want to wait for some vendor to add full support for
> the things you actually need right now?
I can be using C++ and foregoing nice list syntax, or writing SSE code in a
C function. Both of these are better options than finishing incomplete
compilers for people.
> Because these things are generally almost trivial to do in Lisp?
I'll believe it when I see it. From someone else. Let them suffer the
pain.
> Because there is no real
> distinction between core language and APIs in Lisp?
Maybe that's a basic problem behind Lisp's lack of industrial adoption.
Maybe it's not really about the funky parentheses after all.
>> To me that's a Complete Waste Of Time.
>
> What you probably want is a high-level language that ultimately emits
> proprietary instructions. This is almost trivial to do with Lisp-style
> macros. If you don't get a complete solution that is optimal for your
> task right out of the box in another language, it's very likely that
> Lisp will get you to a workable and seamless solution in a very short
> amount of time.
I'm also a bit suspicious of a language community who's mentality is
"everyone roll their own" for very basic capabilities that should be
standardized by now. Intel SSE has been out for a long time, it's a Pentium
III capability. Really, how seriously can I take some compiler writer's
performance knowhow if they don't support basic ASM instructions?
The fact that nobody in these newsgroups is popping up with a list of ready
answers, tells me that functional programmers do not, in general, deal with
things like ASM and Intel SSE. Ergo, their tools can be expected to be
inadequate in this regard.
>> Let alone pay for it, as Corman Lisp
>> is not free for commerical use. This is for a game I intend to make
>> money off of someday.
>
> Then it should be an advantage that you have based your software on a
> proprietary solution that your competitors will have trouble to catch
> up with.
The use of SSE is not a competitive advantage. Any C++ programmer can do
it. I am not sure if using a nice clean list syntax is a competitive
advantage or not. Haven't gotten deep enough into the problems I think
it'll be useful for.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
Marc Battyani
> want to use a tool to do something rather basic that isn't already
complete?
> To me that's a Complete Waste Of Time. Let alone pay for it, as Corman
Lisp
> is not free for commerical use. This is for a game I intend to make money
> off of someday.
The Complete Waste Of Time is trying to help somebody who can't afford to pay
for his own developing tools for a commercial application and want to have
people write free code so that he can code his application faster.
BTW Edi is right, we use assembly language almost exclusively. But when we
want real speed, we use VHDL.
Marc
Feuer
> that's the exact opposite of what I want. I've put a lot of trouble into
> figuring out how much storage I want everything to use, and what the layout
> is... why would I want to wreck that by adding dynamic typing?
That doesn't have much to do with dynamic typing; You're working below
that level it seems.
David
Vincenzo aka Nick Name
>
> The fact that nobody in these newsgroups is popping up with a list of
> ready answers, tells me that functional programmers do not, in general,
> deal with things like ASM and Intel SSE. Ergo, their tools can be
> expected to be inadequate in this regard.
Yes, I think so, too :) Maybe there are other goals in functional
programming than writing asm snippets... however maybe you can express you
asm code with a monad in haskell - which does the job of dynamically
compiling it. This would be research however, not production.
V.
Brandon J. Van Every
> "Brandon J. Van Every" <try_vanevery_a...@yahoo.com> wrote
>>
>> Hrm... a strange mentality, is this common among Lisp folk? Why
>> would I want to use a tool to do something rather basic that isn't
>> already complete? To me that's a Complete Waste Of Time. Let alone
>> pay for it, as Corman Lisp is not free for commerical use. This is
>> for a game I intend to make money off of someday.
>
> The Complete Waste Of Time is trying to help somebody who can't
> afford to pay for his own developing tools for a commercial
> application and want to have people write free code so that he can
> code his application faster.
I don't think you get it. I'd pay for a *solution*. I'm not paying for a
non-solution. Generally speaking, people don't.
I'm also not interested in spending my time finishing incomplete compilers,
even if they are free. I have all sorts of other incomplete things to
finish that are far more important, and a far better use of my time.
This conversation is increasingly taking a turn devoid of commercial
production reality. I feel like I'm talking to a few people who think that
the goal of Life is to sit around writing Lisp programs because they can.
That's not my goal. My goal is to identify tools that will save me labor,
not create it.
I don't think Lisp is "neat." I don't think programming is "neat." I think
programming is In The Way [TM]. A language or tool either removes barriers
for certain problems, or it creates them.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
Pascal Costanza
Brandon J. Van Every wrote:
>>Because there is no real
>>distinction between core language and APIs in Lisp?
>
> Maybe that's a basic problem behind Lisp's lack of industrial adoption.
http://alu.cliki.net/Industry%20Application
> Maybe it's not really about the funky parentheses after all.
http://www.google.com/search?q=%22those+parentheses+are+there+for+a+reason%22
> The fact that nobody in these newsgroups is popping up with a list of ready
> answers, tells me that functional programmers do not, in general, deal with
> things like ASM and Intel SSE. Ergo, their tools can be expected to be
> inadequate in this regard.
http://www.lisp.org/table/objects.htm
http://www.lisp.org/table/macros.htm
Will Hartung
> >> would I want to use a tool to do something rather basic that isn't
> >> already complete? To me that's a Complete Waste Of Time. Let alone
> >> pay for it, as Corman Lisp is not free for commerical use. This is
> >> for a game I intend to make money off of someday.
> >
> > Yeah, nothing like tossing the baby out with the bathwater.
>
> Where's the baby?
Let's go all the way back to your original query:
> From: "Brandon J. Van Every" <try_vanevery_a...@yahoo.com>
> Sent: Thursday, January 22, 2004 2:51 PM
>
> Can anyone tell me of a language + compiler that
>
> 1) runs on Windows
> 2) has support for lists in the language syntax itself, not just as a
> standard library
> 3) supports Intel SSE instructions in some manner
>
> Regarding (3), it could be inline ASM, builtin compiler functions, or some
> other form of tedious manual labor. I'm not expecting automagical Intel
SSE
> compiler support, although indeed that would be nice if it existed.
> It has not been verified that Corman Lisp actually fulfils (3). In fact,
> one person says it doesn't.
Hmm. "Some other form of tedious manual labor", but, of course, not, for
example, making one set of "tedious manual" changes to the built-in,
extensible assembler. I've looked at the assembler, it pretty darn
straightforward. Given the Intel manual and perhaps a nice email to Roger,
SSE support would quickly appear.
> I don't hand over $250 for products that don't meet my criteria.
No, certainly not. Not even for systems that even come close to your
criteria.
> Even if Corman Lisp were free for commercial use, I don't look for
> opportunities to gratuitously implement stuff.
Oh, then I assume that you're licensing all of your other infrastructure?
(3-D engine, animations, modeling, sound, etc) That's all been done over and
over to death. But, no doubt they don't quite meet your exacting
specifications, so best to dig out the Foley, van Dam book and start fresh.
> "It'll take 10 minutes" is bullshit. By the time you actually get through
> understanding, designing, coding, testing, redesigning, and real world
> shaking out of bugs, it'll take weeks or months.
Whatever you say, you're the expert.
> And if you don't understand that, then you don't code commercially.
> Or else you are completely insulated from any financial impacts,
> i.e. you're someone's employee, and you sit around wasting a lot of
> your employer's time and money implementing stupid stuff like that.
> Those of us bearing our own development costs, want things off-the-shelf
> that save us labor.
I'm reknowned for living in my own little Ivory Tower. Infamous even. Ask
anyone. (I'd be happier in a Mac Ivory Tower, but, alas...)
The crux is that because you're not willing to invest ANY time in the tool
(after all, it's supposed to save labor), and since this tool happens to
meet 90+ % of your criteria (as stated, whether you believe it or not), and
the other 10% is less than a days work away (because assemblers are really
pretty simple, and this one is already written, but that's not important
right now, you don't have time to look at it anyway), you're willing to toss
ALL of it away and crawl back to an environment that offers nothing that you
asked for (save the Windows part).
Yup. You're right.
It's much better to stick with the system that doesn't meet your criteria at
all. Best to dig your trench with the spoon you have than with a shovel
who's handle is a wee bit short. Why take three steps forward if you have to
take a step back? You're much better off using a system you can not change,
and fighting its limitations repeatedly, over and over again rather than
eliminate them completely once. The best part is that you can better plan
your time, because you know how long your tasks will take. With an
extensible system you may foolishly waste time adding something to actually
improve your productivity, and you don't want that to happen. Throws the
schedules in to a tail spin.
Just use this as an object lesson. Next time you feel that your system is
letting you down, that you think that there HAS to be something better,
don't waste your valuable time looking. Best to flog through the devil you
know than poke your head out of your cave. It's dangerous world of
imperfection out here. Nobody wants to see you get hurt.
Regards,
Will Hartung
(wi...@msoft.com)
Brandon J. Van Every
>
> Hmm. "Some other form of tedious manual labor", but, of course, not,
> for example, making one set of "tedious manual" changes to the
> built-in, extensible assembler. I've looked at the assembler, it
> pretty darn straightforward.
I'm definitely running into a serious clash of programmer culture here. I
cannot abide a Lisp culture of "everyone rolls their own," instead of
expecting certain basic things to be standard and off-the-shelf.
> Given the Intel manual and perhaps a
> nice email to Roger, SSE support would quickly appear.
From an industrial provenness, production schedule dependency standpoint,
that's the most ridiculous crock of shit I've ever heard. When you figure
out how to plan your business based on factors within your control, get back
to me. And if you think the answer is, "I'm sure Roger will do lotsa things
for you, for an hourly fee," yes I'm sure he will. But I'm not interested
in a $5000 compiler with no field testing.
>> Even if Corman Lisp were free for commercial use, I don't look for
>> opportunities to gratuitously implement stuff.
>
> Oh, then I assume that you're licensing all of your other
> infrastructure? (3-D engine, animations, modeling, sound, etc) That's
> all been done over and over to death. But, no doubt they don't quite
> meet your exacting specifications, so best to dig out the Foley, van
> Dam book and start fresh.
I have my own legacy 3D code, and http://nebuladevice.sourceforge.net is the
3D engine off-the-shelf I'm considering. I will probably buy a Maya seat
someday, because the game industry has proven that it's "worth it." There's
also http://www.blender3d.org for $0, but when I tried it 2 years ago I
didn't like it. I don't know / care about sound at this point, it's the
least of my concerns.
Why am I sitting around arguing about my production concerns with you? What
you're spouting is baloney, and this is a waste of time. I really can't
stand people who don't understand what commercial production is, and I'm
tired of arguing with academic / hobbyist pigs about this sort of thing.
Time to unsubscribe. If anyone knows of a Lisp with Intel SSE in it, I'd be
much obliged with an e-mail. A serious community of Lisp SSE users
definitely does not exist here. I've found a few possibile compilers on
Google, but the listings are scant, and do not necessarily fulfil "runs on
Windows."
> The crux is that because you're not willing to invest ANY time in the
> tool (after all, it's supposed to save labor), and since this tool
> happens to meet 90+ % of your criteria (as stated, whether you
> believe it or not), and the other 10% is less than a days work away
> (because assemblers are really pretty simple, and this one is already
> written, but that's not important right now, you don't have time to
> look at it anyway), you're willing to toss ALL of it away and crawl
> back to an environment that offers nothing that you asked for (save
> the Windows part).
*You* cough out the tool in 1 day then. And e-mail me about your results.
Brandon J. Van Every
> Brandon J. Van Every wrote:
>
>> Maybe it's not really about the funky parentheses after all.
>
>
http://www.google.com/search?q=%22those+parentheses+are+there+for+a+reason%22
>
>> The fact that nobody in these newsgroups is popping up with a list
>> of ready answers, tells me that functional programmers do not, in
>> general, deal with things like ASM and Intel SSE. Ergo, their tools
>> can be expected to be inadequate in this regard.
>
> http://www.lisp.org/table/objects.htm
> http://www.lisp.org/table/macros.htm
Taking these points in tandem, I am not certain enough of my problem domain
to know that "writing a program to write a program" is a good idea. For my
3D planet topology, maybe it is, maybe it isn't. I won't know until I get
deeper into development.
Strategically, I'm afraid there's a lot of business determinants in computer
games that have nothing to do with choice of technology. I think Eye Candy
and Marketing are the prime determinants. I'm hoping Game Design can be a
determinant, but I'm undertaking substantial risk in thinking so. The
business model of "add more programmatic features rapidly" does not strike
me as compelling for games, not without a subscription model or other way to
pay for ongoing feature development. "Add art assets rapidly" would be a
far more important business model, for instance. And I think it would be
better to spend time on better marketing of a smaller number of features,
rather than giving gamers a kitchen sink / smorgasbord for their measly $30.
If I had confidence in why a particular functional language would enable me
to develop anything and everything faster, or even some specific, important
problem domain faster, I'd use it. But I don't have that confidence. Call
that chicken-and-egg, or call that too much staring at Microsoft SDKs to
think that anything can be a magic bullet for API interfacing problems.
In the case of Intel SSE support, "programs writing programs" definitely
strikes me as a bad idea. SSE is a straightforward standard that should
simply be supported in a compiler as a matter of boring gruntwork. It can
hardly represent a competitive advantage compared to, say, inline ASM used
by a C++ programmer.
Now, if somoene has a treatise / testimonial about how they used Lisp macros
or some other functional language's features to roll a bunch of SSE code
together, I'd be interested to hear about it. But I don't regard the SSE
instruction set very highly for 3D graphics problems anyways. I've done a
good number of 'em by hand, my brain is better than any compiler for that
kind of small problem, and SSE instrucitons are just slow and don't fit.
There's only so much to think about because there's only so much you can get
done with them.
Consequently, as a matter of taking business risk, I'm not willing to walk
down the primrose path of rolling my own SSE assembler just to see if I "get
something" for the trouble. I suspect that compared to inline ASM in C++, I
won't.
Frank A. Adrian
> I don't think programming is "neat." I think
> programming is In The Way [TM]. A language or tool either removes barriers
> for certain problems, or it creates them.
Then why do you choose a path that seems to irritate you so much? It's
not that I don't agree that sometimes using current tools is hard, but you
should either (a) understand the limitations of current tools and not be
so unhappy with them that it turns you into a big whiner or (b) find
something else to do that will make you happier. In either case, don't
expect your crybaby attitude to go over particularly well. Mature people
either pull up their socks and improve the situation (which you could do
by either coding the stuff yourself or by paying someone to do it for
you) or go on without complaining. Either way, this is about as good as
it's going to get as far as commercial tools go, so accept it or go away.
faa
Thomas F. Burdick
> I don't hand over $250 for products that don't meet my criteria.
>
> Even if Corman Lisp were free for commercial use, I don't look for
> opportunities to gratuitously implement stuff. "It'll take 10 minutes" is
> bullshit. By the time you actually get through understanding, designing,
> coding, testing, redesigning, and real world shaking out of bugs, it'll take
> weeks or months. And if you don't understand that, then you don't code
> commercially.
Have you never worked with a well factored system? Have you never
seen an assembler? It's not rocket science. Get your free trial of
Corman Lisp, tell them that you need SSE instruction support in the
assembler to use it commercially, and I'm sure you'll have either the
support itself, or an ABC123 set of instructions on how to type in
your definitions.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Erik Naggum
| "It'll take 10 minutes" is bullshit. By the time you actually get
| through understanding, designing, coding, testing, redesigning, and
| real world shaking out of bugs, it'll take weeks or months. And if
| you don't understand that, then you don't code commercially.
Then why do you ask people to help you for free?
| Or else you are completely insulated from any financial impacts,
| i.e. you're someone's employee, and you sit around wasting a lot of
| your employer's time and money implementing stupid stuff like that.
| Those of us bearing our own development costs, want things
| off-the-shelf that save us labor.
If any of this pontification was honest, you would already have been
able to recognize that you ask people to help you as favor. What kind
of person is so much in tune with the «financial impacts» and still
goes out in the world and /demands/ that people help him and complain
when the help is not to his liking, without offering compensation to
those who are willing to help?
Your concept of the value of the information you seek is faulty, and
the most likely cause is that your concept of the value of the labor
you want to be saved from doing is /missing/.
If you valued both your own time and that of others, you would step
down from the soapbox and find ways to entice people to help you, but
now you have angered many of those who could have helped you. You
come off not as someone who is financially responsible, but as someone
who is strapped for financial resources and therefore turns to other
with demands to ease your unfair suffering instead of with offers of
remuneration for what you value properly. Trust me, USENET is full of
people who are poor and demanding, but fora like this exists because
people are willing to share of their tremendous surplus. Those who
approach such fora with demands, bring an imbalance to the table that
annoys people, because instead of two people sharing of their surplus,
the one who has something to share feels taken advantage of when the
person he shares with only offers arguments from poverty.
If my predictions about you hold true, you will now attack me because
you believe you were attacked and will focus your energy on exacting
revenge on me for having exposed something uncomfortable about you,
and you will focus your energy into feeling insulted and mistreated,
instead of understanding that you have been asked politely not to be
so demanding of those you ask for help. If my predictions about you
are false, you will surprise everybody with an apology for your
aggressive and insulting behavior and offer us a better understanding
of your actual problem in such a way that people who can think of
better ways to solve them than you can, will feel free to either help
you or offer you their solutions in exchange for real, hard cash.
Which path do you want to follow? Both are equally open to you now.
--
Erik Naggum | Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum
I appreciate the private aside that is often so crucial to effective
communication between two people. However, I do not appreciate it
when people use private e-mail to attack me. Attacks should be out in
the open so everybody can see. Personal mail exchanges are there for
the benefit of people who would like to /think/ and would like to do
so privately before publishing their unfinished thoughts. In keeping
with this spirit, I share his inappropriate private communication.
---------------------------------------------------------------------------
From: "Brandon J. Van Every" <vane...@indiegamedesign.com>
To: <er...@naggum.no>
Subject: Re: builtin lists and Intel SSE support?
Date: 2004-024F09:25:27Z
Message-ID: <OOEALCJCKEBJBIJHCN...@indiegamedesign.com>
[privately]
"Erik Naggum" <er...@naggum.no> wrote in message
news:<32839235320...@naggum.no>...
> * Brandon J. Van Every
> | "It'll take 10 minutes" is bullshit. By the time you actually get
> | through understanding, designing, coding, testing, redesigning, and
> | real world shaking out of bugs, it'll take weeks or months. And if
> | you don't understand that, then you don't code commercially.
>
> Then why do you ask people to help you for free?
I didn't. If something is free and doesn't do the job, I just decline.
If something costs money and doesn't do the job, I look for a product
that does.
> If any of this pontification was honest, you would already have been
> able to recognize that you ask people to help you as favor. What kind
> of person is so much in tune with the «financial impacts» and still
> goes out in the world and /demands/ that people help him and complain
> when the help is not to his liking, without offering compensation to
> those who are willing to help?
I think you have a listening / reading comprehension problem. And your
ideologies are both pretentious and stupid.
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.561 / Virus Database: 353 - Release Date: 1/13/2004
---------------------------------------------------------------------------
The astute reader will have noticed that I gave this crippled mind the
option of a graceful recovery, but he chose to attack and is obviously
the kind of person who has yet to understand the purpose of publishing
the means of private communication.
I strongly urge people to make note of this person's name and company
and to share it with as many people as possible to prevent him from
having any business success at the expense of the friendly, helpful
USENET community whom he abuses for no discernible reason.
Tim Bradshaw
> Even if Corman Lisp were free for commercial use, I don't look for
> opportunities to gratuitously implement stuff. "It'll take 10 minutes" is
> bullshit. By the time you actually get through understanding, designing,
> coding, testing, redesigning, and real world shaking out of bugs, it'll take
> weeks or months. And if you don't understand that, then you don't code
> commercially.
I agree. I'm sure that any of the commercial Lisp vendors would be
quite happy to discuss doing this kind of extension for you for a fee.
Like you I'm fed up with the stupid `oh you can just implement it
yourself because you have *source*, which solves everything' mantra
that the open source cultists repeat endlessly when they're not
burning each other or stealing music from people. Like I want to
spend hundreds of hours wading through megabytes of crappily-written
code to try and implement some feature.
--tim
Erik Naggum
| I'm sure that any of the commercial Lisp vendors would be quite happy
| to discuss doing this kind of extension for you for a fee. Like you
| I'm fed up with the stupid `oh you can just implement it yourself
| because you have *source*, which solves everything' mantra that the
| open source cultists repeat endlessly when they're not burning each
| other or stealing music from people. Like I want to spend hundreds of
| hours wading through megabytes of crappily-written code to try and
| implement some feature.
At issue here is whether the Open Source community effective prevents
the commercial Common Lisp vendors from offering to implement this
kind of extension for a fee. We witness a change in the response to a
request for a feature from either «NO» or «YES, for $$$» to «NO, build
it yourself», but it appears to me that the «YES, for $$$» option may
have drowned in the noise because some believe the response was really
«YES, build it yourself» and thereby killed off the commercial option.
Ideally, the availability of an option you do not want to invoke would
not have affected any other options and the likelihood that would want
to invoke any of them, but a curious artifact of human psychology is
that we /are/ influenced by what we do not want, in that the things we
want to do must have a sufficient /distance/ to the things we do not
want to do. If someone argues that you could do it yourself, but you
do not want that, someone else who asks for money to do it, will of
necessity ask for money for something that you could do yourself, and
most people's willingness to pay for something is proportional to how
much they are saved from doing. It is therefore a major disservice to
the commercial developers to tell requestors of features that they are
within reach, however hypothetical this really is.
Those who would be willing to rush to the aid of requestors with $$$
to pay for a feature are also quite reserved when the difficulty of
implementing the feature is implicitly reduced to only having source
code access. The cost of actually doing it is further reduced by the
hypothetical willingness of other people to do it for free, so the
most pronounced consequence of saying «you have the source, enjoy!»,
is to remove the commercial viability of the undertaking from both
sides: The customer's willingness to pay for it, and the vendors'
willingness to risk anything to do it in return for future profits.
This sort of pre-emptive competition is extremely unhealthy.
Those of us who have worked on Open Source and Free Software projects,
and who have had source access to large systems, know that the worst
and most expensive downside of obtaining access to source code that
has evolved under the pressure and competition of a different group of
people, is not that it takes a lot of time to understand the source,
but that it takes a lot more time to be satisfied with understanding
the evolutionary pressures that formed it. Having source code access
is more often than not a strong disincentive to working on it, because
the choices other people have made will always include a number that
are /objectively/ braindamaged and/or literally insane. The absence
of understanding of the evolutionary pressure of anything that has
evolved over a long time, tends to make people want to invent all
sorts of idiotic explanations for how things became what they are, and
Common Lisp itself is no exception to this rule: Many people come to
Common Lisp with barely understood evolutionary pressures of their own
and refuse to do the mental work that understanding how Common Lisp
grew into what it is requires, and are doomed to a life of stupid
objections to decisions that cannot be undone, and some of them run
off to create their own pet languages, decrying the «braindamage» of
Common Lisp and virtually shouting that they are /not/ going to make
the same kind of mistakes that other people did. (I know just how
this feels, by the way -- I could never learn to use C++, because of
the completely overwhelming desire to redesign the language every time
I tried to use it, but this is the normal, healthy reaction to C++.)
Vincenzo aka Nick Name
> the open source cultists repeat endlessly when they're not
> burning each other or stealing music from people.
Yeah, now open source cultist steal music from people :) This is going to be
my next .signature, you know. Can I do this without a fee or did you put a
copyright on your post? Did you mean also the freebsd people, stealing
music, or only those crappy Stallmaninists? Oh yes, I will also mention the
Nazists, 1. for par conditio, 2. to end this thread according to the old
tradition :)
V.
Joachim Durchholz
> Joachim Durchholz wrote:
>
>>Brandon J. Van Every wrote:
>>
>>
>>>3) supports Intel SSE instructions in some manner
>>>
>>>Regarding (3), it could be inline ASM, builtin compiler functions, or
>>>some other form of tedious manual labor.
>>
>>Would a C interface qualify? You could do the SSE stuff in C with
>>inline assembly, or in assembly with C linkage.
>
> It's a valid point, and one I realized belatedly. But for purposes of this
> question, I think having a C interface doesn't count. C interfaces are
> common. There are tons of languages that run on Windows, have builtin
> lists, and have a C interface, so not really any need to ask the question.
Hmm... in general, I think that question is better answered by asking
about performance in general.
Direct SSE support is just one aspect of many. From a language
designer's point of view, it's relatively uninteresting - it's a feature
that's available only for a specific architecture, and useful only for a
limited set of programs. Implementing smarter code transformation and
optimization algorithms would be a real contender for SSE work.
> I'd really like to find out if anything has first-class SSE support, such as
> via compiler intrinsics or at least inline ASM. I also think such support
> indicates a general concern with performance, instead of the "well, if you
> need performance you can just do it in C" mentality.
Well, for that, I think a more interesting criterion would be whether
the compiler generates machine code directly. If it goes through C,
performance is obviously not first on the minds of the compiler writers.
I think you're doing at least marginal injustice to high-level people
though. I believe that the general thinking is more like "if you need
*small-scale* performance, you can do it in C". Functional people tend
to be quite performance-minded, since naive implementations tend to be
really, really slow. It's just that the techniques that have proven to
be effective to get today's level of speed are about improving things on
the grand scale. Inter-module analysis is important (just as with OO
languages, where automatic detection of inlining opportunities requires
whole-system analysis). Small-scale optimizations like SSE tend to get
lost from view in such a context.
In general, I'd take a look at what OCaml does and how it performs. I
don't think it emits SSE instructions, but it will give you a feel for
what's considered fast in the FPL arena.
Regards,
Jo
--
Currently looking for a new job.
Joe Marshall
> Frank A. Adrian wrote:
>> On Fri, 23 Jan 2004 09:20:19 -0800, Brandon J. Van Every wrote:
>>>
>>> Thanks! Since the devil is in the details, I wonder if their inline
>>> ASM supports the full IA-32 instruction set? In Visual Studio, back
>>> in the bad old days, when some newfangled instruction came out you
>>> had to EMIT it until real support was available. Not really
>>> practical for more than trivial usage.
>>
>> If it doesn't, you also get the source code for the core system. The
>> assembler portion is simple enough that it can be easily extended to
>> support new instructions (and I'm sure that Roger would be grateful
>> for the contribution).
>
> Hrm... a strange mentality, is this common among Lisp folk?
I like to believe so. I'd be a bit disillusioned to learn that
someone sharp enough to use Common Lisp decided to abandon the entire
language over something as trivial as a new opcode in the assembler;
especially when the source is available and adding it would take all
of ten minutes of thought.
> Why would I want to use a tool to do something rather basic that
> isn't already complete?
Why would you want to use a tool at all? The answer to your question
follows directly from the answer to this.
> To me that's a Complete Waste Of Time.
You have the time to complain.
> Let alone pay for it, as Corman Lisp is not free for commerical use.
Corman Lisp is exceptionally reasonable in this regard: $250 will get
you the license you need to distribute products made with CCL. This
is an order of magnitude less than Lispworks or Franz Allegro.
> This is for a game I intend to make money off of someday.
--
~jrm
Joe Marshall
Joe Marshall
> I can be using C++ and foregoing nice list syntax, or writing SSE code in a
> C function. Both of these are better options than finishing incomplete
> compilers for people.
Instead, you are annoying people.
--
~jrm
Brandon J. Van Every
> In keeping with this spirit, I share his inappropriate private
communication.
Ok, if you insist (not like I could stop you). But I take issue with my
private communication to you being inappropriate.
Brandon said to Erik in private:
>> I think you have a listening / reading comprehension problem.
Totally fair comment, since you said I asked for work for free when I
hadn't, and this was the very basis of your umbrage.
>> And your ideologies are both pretentious and stupid.
>
> The astute reader will have noticed that I gave this crippled mind
> the option of a graceful recovery,
Finding you pretentious does not make my mind crippled. You most certainly
are.
Finding your ideologies stupid is a matter of opinion. I've given you mine.
Personally, I think your whole "Usenet is for caring and sharing" ideology
is stupid, as well as your psychobabble analysis of how I was going to react
to your post, and the whole "paths laid before you" thing. Who are you, the
King Of Norway, and I your loyal subject? Usenet is an anarchy. People are
here for many reasons, and they don't have to be your reasons.
> but he chose to attack
Ah, I see. You attack me publically. I have the good graces to respond
briefly in private, with not particularly the worst words I could think of,
to spare all parties the waste of time. You figure that's your cue to air
some dirty laundry and paint it as my character flaw. I'll decline further
fulfilments of your prophecies.
> I strongly urge people to make note of this person's name and
> company and to share it with as many people as possible to prevent
> him from having any business success at the expense of the
> friendly, helpful USENET community whom he abuses for no
> discernible reason.
Wow, you certainly are full of yourself. But I already knew you were
pretentious.
Welcome to my killfile.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"Trollhunt" - (n.) A searching out for persecution
of persons accused of Trolling. (c.f. witch-hunt)
Brandon J. Van Every
Amen, brother! In fairness, I've seen aspects of both Xconq and Freeciv
that were implemented well. The Windows builds weren't among those aspects,
hence my frustration with Linuxers. So my point is, the open source guys
actually do some things well, but they tend to oversell the real world value
of their open source code. When features are missing and labor hasn't been
done, other people end up having to do a lotta work.
Brandon J. Van Every
>
> Hmm... in general, I think that question is better answered by asking
> about performance in general.
> Direct SSE support is just one aspect of many. From a language
> designer's point of view, it's relatively uninteresting - it's a
> feature that's available only for a specific architecture, and useful
> only for a limited set of programs.
Actually, current PowerPC CPUs have similar instructions... and last I
looked, similar flaws in the lack of a "sum of scalar fields" instruction.
Bastards! Why don't these people get it??!? Anyways, "scalar register" and
"4-field vector" programming models definitely don't play well together, so
I understand the reluctance of compiler writers to embrace the latter. It's
really not a very good model, it's just what the CPU vendors have handed us
in industrial practice. I would have strongly preferred that we keep going
in a proper RISC direction, like the DEC Alpha CPU was doing. If it were
still extant, and running at current clock speeds, it would be blowing the
doors off of everything. As it is, I've contemplated switching to PowerPC
solely to get away from fucking Intel, but I don't yet have the budget or
business model to be that idealistic.
> Implementing smarter code
> transformation and optimization algorithms would be a real contender
> for SSE work.
But having done a fair number of 3D graphics problems by hand in SSE, the
reality is there's only so much you can do. They're slow instructions, and
often in 3D graphics you don't have a whole lot of things you want to be
working on at once. Rather, you want a dot product test and you want it
over quickly, so you can get on with the next serially dependent
computational step. Parallelism is grossly overrated, there are all kinds
of problems that aren't parallel.
> Well, for that, I think a more interesting criterion would be whether
> the compiler generates machine code directly. If it goes through C,
> performance is obviously not first on the minds of the compiler
> writers.
Good point. Maybe I'll ask that question at some point.
> I think you're doing at least marginal injustice to high-level people
> though. I believe that the general thinking is more like "if you need
> *small-scale* performance, you can do it in C". Functional people tend
> to be quite performance-minded, since naive implementations tend to be
> really, really slow. It's just that the techniques that have proven to
> be effective to get today's level of speed are about improving things
> on
> the grand scale. Inter-module analysis is important (just as with OO
> languages, where automatic detection of inlining opportunities
> requires whole-system analysis). Small-scale optimizations like SSE
> tend to get lost from view in such a context.
Well, computers aren't really any good. They have bad memory controllers,
meaning you can't really control them. If you could control memory like a
laser, then you could blend all kinds of computations together and get
maximum execution out of CPUs. But memory controllers can't synchronize
anything that well. They're fundamentally sloppy. Really our computers are
built for MS Word.
Even the DEC Alpha had a shitty memory controller. There was this one
budget series that was particularly shitty, I forget the name. It was so
bad that 533 MHz machines would run slower than 333 MHz machines with better
memory controllers. We Christened one of these junkers as the Yugo and put
an appropriate desktop picture on them in our lab. Ours was a DEC lab, BTW.
:-)
> In general, I'd take a look at what OCaml does and how it performs. I
> don't think it emits SSE instructions, but it will give you a feel for
> what's considered fast in the FPL arena.
OCaml does seem to be the performance contender. But it's hard to tell for
sure with just synthetic benchmarks like http://dada.perl.it/shootout/ .
The broad pattern that emerges from the synthetics is "compiled functional
languages have comparable ballparks of performance." But what of
application peformance, like heavy duty pathfinding problems? I feel
another question coming on...
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"Desperation is the motherfucker of Invention." - Robert Prestridge
Tim Haynes
[snip]
> Your concept of the value of the information you seek is faulty, and
> the most likely cause is that your concept of the value of the labor
> you want to be saved from doing is /missing/.
(Just so I can agree with it, I'll leave that in place.)
> If you valued both your own time and that of others, you would step
> down from the soapbox and find ways to entice people to help you, but
> now you have angered many of those who could have helped you.
To be fair, it doesn't help that c.l.l is also overpopulated with people
with high verbosity:tolerance:helpfulness ratios. IME these are best
identified and their attitudes ignored. Take the helpfulness where it's
given, stick around and be helpful to restore karma to the 'Net or
something, maybe do some of your *own* damn' research, but neither
whinging, nor spewing apologetics, are profitable to anyone.
[snip]
~Tim
--
Can you tell me how to get, |pig...@stirfried.vegetable.org.uk
How to get to Sesame Street? |http://spodzone.org.uk/
Tim Haynes
>> Because you don't want to wait for some vendor to add full support for
>> the things you actually need right now?
>
> I can be using C++ and foregoing nice list syntax, or writing SSE code in a
> C function. Both of these are better options than finishing incomplete
> compilers for people.
A compiler's completeness is determined by whether it can take a program's
source and generate an executable, not whether it chooses to use specific
assembler code to do so.
It could be said that your definition of `incomplete' overlaps rather a lot
with expecting others to do the work for you; there has to be a line drawn,
somewhere, where you take over and generate the program while the compiler
does its job.
I tentatively suggest that the priorities in the lisp world may be
different, e.g. focussing on cross-platform compatibility and the
higher-level language. However, I also suggest that part of your job in
developing this game is to write a core engine as you see fit, and
invoke that in whatever other ways you feel fit, afterwards.
The hierarchy of "functions in a HLL, calling stuff written in C and maybe
even down to assembler" is a reasonable balance between authoring large
chunks of high-level functionality and having their underlying components
run fast, without risking the Root of All Evil (at least not too much).
[snip]
~Tim
--
17:02:55 up 53 days, 20:16, 0 users, load average: 0.33, 0.28, 0.16
pig...@stirfried.vegetable.org.uk |Another day,
http://spodzone.org.uk/cesspit/ |Another apt-get dist-upgrade
Brandon J. Van Every
> "Brandon J. Van Every" <try_vanevery_a...@yahoo.com>
> writes:
>
>>> Because you don't want to wait for some vendor to add full support
>>> for the things you actually need right now?
>>
>> I can be using C++ and foregoing nice list syntax, or writing SSE
>> code in a C function. Both of these are better options than
>> finishing incomplete compilers for people.
>
> A compiler's completeness is determined by whether it can take a
> program's source and generate an executable, not whether it chooses
> to use specific assembler code to do so.
What a crock of shit! We'll all be waiting for our 16-bit thunking output
then!
> It could be said that your definition of `incomplete' overlaps rather
> a lot with expecting others to do the work for you;
For $250 ??!? You're damn straight I do. You want my money, you'd better
have done the work for me that I want done. Even if that's $10 to sweep
leaves off the front sidewalk.
> I tentatively suggest that the priorities in the lisp world may be
> different, e.g. focussing on cross-platform compatibility and the
> higher-level language.
Maybe so. Equally, C++ coders shopping around for functional language
replacements are looking for certain things. They are potential customers;
if the product doesn't meet their needs, they won't be sending their
business that way.
> The hierarchy of "functions in a HLL, calling stuff written in C and
> maybe even down to assembler" is a reasonable balance between
> authoring large chunks of high-level functionality and having their
> underlying components run fast, without risking the Root of All Evil
> (at least not too much).
C++ developers mitigate that risk all the time.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
Brandon's Law (after Godwin's Law):
"As a Usenet discussion grows longer, the probability of
a person being called a troll approaches one RAPIDLY."
Tim Haynes
>> A compiler's completeness is determined by whether it can take a
>> program's source and generate an executable, not whether it chooses
>> to use specific assembler code to do so.
>
> What a crock of shit! We'll all be waiting for our 16-bit thunking output
> then!
>
>> It could be said that your definition of `incomplete' overlaps rather
>> a lot with expecting others to do the work for you;
>
> For $250 ??!? You're damn straight I do. You want my money, you'd better
> have done the work for me that I want done. Even if that's $10 to sweep
> leaves off the front sidewalk.
Why don't you just pay someone to write the entire game for you, then?
>> The hierarchy of "functions in a HLL, calling stuff written in C and
>> maybe even down to assembler" is a reasonable balance between
>> authoring large chunks of high-level functionality and having their
>> underlying components run fast, without risking the Root of All Evil
>> (at least not too much).
>
> C++ developers mitigate that risk all the time.
Feel free to write in C++ if it makes you happy, I would wish for no less ;]
~Tim
--
Not every discomfort should |pig...@stirfried.vegetable.org.uk
be criminalised. (Bill Unruh) |http://spodzone.org.uk/
Brandon J. Van Every
>>> rather a lot with expecting others to do the work for you;
>>
>> For $250 ??!? You're damn straight I do. You want my money, you'd
>> better have done the work for me that I want done. Even if that's
>> $10 to sweep leaves off the front sidewalk.
>
> Why don't you just pay someone to write the entire game for you, then?
You realize that you've asked a complete non-sequitor, don't you? There's
no "then" here.
But since you asked, the reasons I'm not going to pay someone to write Ocean
Mars for me in its entireity are (1) nobody is capable of that but me, (2)
to the extent that other people are capable of providing labor, I still need
to make a lot of architectural decisions to ensure that things are done the
way I want, (3) I don't currently have a budget to pay anybody anything.
But when that changes, rest assured I'll be looking at hiring some Indians,
Slavs, and/or Russians to do some gruntwork for me. The trick is figuring
out what they can do, turnkey on the other side of the world, with little
oversight, that contributes value and they can't screw up.
The way I see it, American programming jobs are going to disappear and be
devalued in the face of an onslaught of cheap foreign programming labor.
It's starting now, and within 10 years the process will be alarmingly
complete, as all those foreigners will have gone up their requisite customer
service learning curves. The only ways to beat this are to either (1) have
a tech skill that almost nobody else can perform - a tall order in this
Internet-based world of ours, (2) be a fantastic salesman / customer service
guy, (3) utilize that cheap labor and resell it. That's going to be the new
drill about how to get ahead in technology.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
Ray Dillinger
>
> The Complete Waste Of Time is trying to help somebody who can't afford to pay
> for his own developing tools for a commercial application and want to have
> people write free code so that he can code his application faster.
>
Clearly, he just needs invoice therapy. He won't
appreciate or value any advice or help anyone gives him until
he's required to pay money for it. Responding to this
personality type on usenet is a waste of time. The only way
to help him is to send a salesman to waste his time and money
hammering out a contract, show up and charge him an outrageous
fee, spend the ten minutes or so it takes to do the work, but
don't give it to him for at least a week so he thinks he's
getting his money's worth.
FWIW, grepping for other mnemonics finds the right file
to edit and the right section of the file to edit in five seconds
flat. Referencing the index of the manual allows you to look up
the hex code of any missing mnemonic. That took another minute.
Thirty seconds to edit, sixty to recompile. Done.
Bear
Brandon J. Van Every
>
> Clearly, he just needs invoice therapy. He won't
> appreciate or value any advice or help anyone gives him until
> he's required to pay money for it. Responding to this
> personality type on usenet is a waste of time. The only way
> to help him is to send a salesman to waste his time and money
> hammering out a contract, show up and charge him an outrageous
> fee, spend the ten minutes or so it takes to do the work, but
> don't give it to him for at least a week so he thinks he's
> getting his money's worth.
A bizzare pile of prejudices on your part.
Vincenzo aka Nick Name
>
> A bizzare pile of prejudices on your part.
Said by one who does not look at open-source windows project if they do not
build in visual studio .... :)
V.
Tim Haynes
>>> For $250 ??!? You're damn straight I do. You want my money, you'd
>>> better have done the work for me that I want done. Even if that's
>>> $10 to sweep leaves off the front sidewalk.
>>
>> Why don't you just pay someone to write the entire game for you, then?
>
> You realize that you've asked a complete non-sequitor, don't you? There's
> no "then" here.
Just because you don't see or acknowledge a relation there doesn't mean
it's not there.
You're appearing like you want to dictate both how much something costs,
and what it should do (in order for you to accuse someone else's product of
being "incomplete" because it doesn't meet arbitrary criteria of yours that
I doubt you requested at its design-time).
Getting someone else to do it all, because you don't trust your own
abilities to write a small optimised core, sounds as viable an option as
any to me.
> But since you asked, the reasons I'm not going to pay someone to write
> Ocean Mars for me in its entireity are (1) nobody is capable of that but
> me, (2) to the extent that other people are capable of providing labor, I
> still need to make a lot of architectural decisions to ensure that things
> are done the way I want, (3) I don't currently have a budget to pay
> anybody anything.
So you *are* asking a bunch of usenet volunteers to recommend a 0-cost
solution into which you're not prepared to put any feedback.
[snip]
~Tim
--
The phrase 'object-oriented' means |pig...@stirfried.vegetable.org.uk
a lot of things. Half are obvious, and |http://spodzone.org.uk/
the other half are mistakes. (Paul Graham) |
Eternal Vigilance
What kind of 'list' support are you taling about ??
Is it more the syntax part ?? (how clean is a clean list syntax??)
Versatility -- something that ignores types in dealings with lists
High performance ?? How much do you want it near high optomization C/C++ ??
(And if you want all 3, is that even possible due to type-less list overhead)
To meet your other 2 criteria ( Windows/SSE)
You may be stuck with C++ with inherited List class functionality
and overloading/MACROs/inlining to smooth the syntax (somewhat).
"Brandon J. Van Every" wrote:
> Can anyone tell me of a language + compiler that
>
> 1) runs on Windows
> 2) has support for lists in the language syntax itself, not just as a
> standard library
> 3) supports Intel SSE instructions in some manner
>
> Regarding (3), it could be inline ASM, builtin compiler functions, or some
> other form of tedious manual labor. I'm not expecting automagical Intel SSE
> compiler support, although indeed that would be nice if it existed.
>
> The application domain, if you want to know, is pathfinding on a 3D model of
> a planet. Currently I'm looking at using a node / graph approach, and it
> promises to be both list heavy and vector heavy.
>
> BTW these are hard requirements for purposes of this question. If I was
> willing to forego (2), I could of course use C++. If I forego (3), I'm
> aware of tons of options, I don't need to be asking the question. And I'm
> certainly not going to give up both (2) and (3), let alone (1) !
>
> --
> Cheers, www.indiegamedesign.com
> Brandon Van Every Seattle, WA
>
> When no one else sells courage, supply and demand take hold.
Thomas F. Burdick
> Marc Battyani wrote:
> >
> > The Complete Waste Of Time is trying to help somebody who can't afford to pay
> > for his own developing tools for a commercial application and want to have
> > people write free code so that he can code his application faster.
>
> FWIW, grepping for other mnemonics finds the right file
> to edit and the right section of the file to edit in five seconds
> flat. Referencing the index of the manual allows you to look up
> the hex code of any missing mnemonic. That took another minute.
> Thirty seconds to edit, sixty to recompile. Done.
Even better, it's mentioned in the Cormann Lisp manual. Grepping
through sources to make changes you need is very handy to have as an
option. Even better is having support for what you want to do.
That's exactly what I meant by "a well factored assembler" in an
earlier post; a few DEFOPs, and you've got the instructions you need.
Brandon J. Van Every
> What kind of 'list' support are you taling about ??
> Is it more the syntax part ?? (how clean is a clean list syntax??)
It is more the clean syntax part. I do not want to type a lot of verbal
gobbledygook. Python and Lisp I would consider clean.
> Versatility -- something that ignores types in dealings with lists
I will almost always be using elements of known type in expected ways. In
fact, the list elements will usually have the same type.
> High performance ?? How much do you want it near high optomization
> C/C++ ??
"In the ballpark." 50% of C++'s speed would be acceptable if the language
was much more productive than C++ due to syntax. Of course I'd like better.
But I can't abide Python, which seems to be 10x slower on all the benchmarks
I look at. Python has a lot of dynamic flexibility that for my problems, I
really don't need. I know what my planetary mesh is composed of, I went to
a lot of trouble to make those decisions so that it wouldn't be wasteful.
OCaml is looking like the appropriate language at this point, but now I have
to figure out how well it's going to play with other languages.
> To meet your other 2 criteria ( Windows/SSE)
> You may be stuck with C++ with inherited List class functionality
> and overloading/MACROs/inlining to smooth the syntax (somewhat).
Possibly. I'm currently looking at SWIG www.swig.org , since there seems to
be no one language that can do it all for me. I'm thinking of having C# as
the top level / system interface / GUI language, and then calling more
interesting languages like OCaml or whatnot. Drop to Managed C++ and Native
C++ if need be. C# is now an ISO standard, see
http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=36768&ICS1=35&ICS2=60&ICS3=
but I don't know about various libraries associated with it. So I'm
currently running that down.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
Brandon J. Van Every
> "Brandon J. Van Every" <try_vanevery_a...@yahoo.com>
> writes:
>
>>>> For $250 ??!? You're damn straight I do. You want my money, you'd
>>>> better have done the work for me that I want done. Even if that's
>>>> $10 to sweep leaves off the front sidewalk.
>>>
>>> Why don't you just pay someone to write the entire game for you,
>>> then?
>>
>> You realize that you've asked a complete non-sequitor, don't you?
>> There's no "then" here.
>
> Just because you don't see or acknowledge a relation there doesn't
> mean it's not there.
>
> You're appearing like you want to dictate both how much something costs,
> and what it should do (in order for you to accuse someone
> else's product of being "incomplete" because it doesn't meet
> arbitrary criteria of yours that I doubt you requested at its
> design-time).
All *discerning* customers specify what they want products to do. Suppliers
either meet those demands or they don't. Customers either bite on the
product or they move on. None of this has a damn thing to do with whether
I'm willing to pay people to write all of Ocean Mars for me.
>> But since you asked, the reasons I'm not going to pay someone to
>> write Ocean Mars for me in its entireity are (1) nobody is capable
>> of that but me, (2) to the extent that other people are capable of
>> providing labor, I still need to make a lot of architectural
>> decisions to ensure that things are done the way I want, (3) I don't
>> currently have a budget to pay anybody anything.
>
> So you *are* asking a bunch of usenet volunteers to recommend a 0-cost
> solution into which you're not prepared to put any feedback.
I could have said, (3) I don't currently have a budget to pay people
salaries, nor to do small amounts of turnkey contract work. I did not
literally mean, my solutions must be 0-cost. $250 for a Lisp compiler is
not unreasonable; what's unreasonable is expecting me to buy it when it
doesn't do what I want. You snipped the bit about using cheap foreign labor
someday when my budget is larger. And nowhere, ever, have I said that I
require open source solutions powered by Usenet volunteers. In fact, I
don't even like most Usenet volunteers, because most of them are idealistic
and preachy like you. Most of them are not practical people and don't wrap
their heads around commercial reality.
Dang Griffith
<usenet-...@stirfried.vegetable.org.uk> wrote:
...
>So you *are* asking a bunch of usenet volunteers to recommend a 0-cost
>solution into which you're not prepared to put any feedback.
...
Come now... Brandon not provide any feedback?
--dang
Ken Rose
>>>But since you asked, the reasons I'm not going to pay someone to
>>>write Ocean Mars for me in its entireity are (1) nobody is capable
>>>of that but me, (2) to the extent that other people are capable of
>>>providing labor, I still need to make a lot of architectural
>>>decisions to ensure that things are done the way I want, (3) I don't
>>>currently have a budget to pay anybody anything.
>>
>>So you *are* asking a bunch of usenet volunteers to recommend a 0-cost
>>solution into which you're not prepared to put any feedback.
>
>
> I could have said, (3) I don't currently have a budget to pay people
> salaries, nor to do small amounts of turnkey contract work. I did not
> literally mean, my solutions must be 0-cost. $250 for a Lisp compiler is
> not unreasonable; what's unreasonable is expecting me to buy it when it
> doesn't do what I want. You snipped the bit about using cheap foreign labor
> someday when my budget is larger. And nowhere, ever, have I said that I
> require open source solutions powered by Usenet volunteers. In fact, I
> don't even like most Usenet volunteers, because most of them are idealistic
> and preachy like you. Most of them are not practical people and don't wrap
> their heads around commercial reality.
I spent 15 years in the games industry, including time as a freelancer
and time at Sega & Atari. I've seen 'em succeed and I've seen 'em fail.
The main cause of failure is bad project management, and that comes in
two major flavors. The first is trying to do it on the cheap, and the
second is not having a good idea of what you want to make in a form that
communicates it to others. Technical failure (where the staff or the
hardware isn't up to the job) is way down the list.
You need a little humility, some decent funding, and a plan, or you're
gonna crash.
- ken
Stefan Axelsson
J. Van Every wrote:
> But I can't abide Python, which seems to be 10x slower on all the benchmarks
> I look at.
Check out psyco (http://psyco.sourceforge.net/) a i386 compiler for
Python. Delivers speedups from 2x to 100x, but typical is 4x (for
'typical' Python programs that mainly call 'C' code). If you actually
try to do work in Python, you'll see a bigger speedup than 4x. Be sure
to use the new object model for the biggest speedup.
I've made the switch and no longer (well mostly) have any concerns
about efficiency.
Unfortunately it doesn't play perfectly with pychecker, but it's not
too bad.
Stefan,
--
Stefan Axelsson (email at http://www.cs.chalmers.se/~sax)
Brandon J. Van Every
> In article <bv44ga$o6ro4$1...@ID-207230.news.uni-berlin.de>, Brandon
> J. Van Every wrote:
>> But I can't abide Python, which seems to be 10x slower on all the
>> benchmarks I look at.
>
> Check out psyco (http://psyco.sourceforge.net/) a i386 compiler for
> Python. Delivers speedups from 2x to 100x, but typical is 4x (for
> 'typical' Python programs that mainly call 'C' code). If you actually
> try to do work in Python, you'll see a bigger speedup than 4x. Be sure
> to use the new object model for the biggest speedup.
>
> I've made the switch and no longer (well mostly) have any concerns
> about efficiency.
A friend of mine has used this, I'll ask him about his results.
Eternal Vigilance
"Brandon J. Van Every" wrote:
A good question (since you mention using 2 languages at one) is whats your
expected usages:
Graphics (you mentioned SSE for that and map geometry calculations)
which would probably require most efficient speedwise.
A group of standard functions for this...
Game mechanics/engine - rule object actions -- middle level logic (may have
cpu intensive analysis) would probably want high efficiency here too.
Question would be how many times as much code as the low level code above...
If you go further having a scripting language (hopefiully mostly invoking
high level call of the game engine.)
Could be a slower language as invocation of logic per unit isnt every cycle.
Depending on how you design it, this could be 60+% of all the code and ease
of coding scripts would be good (Is a general purpose language even a requirement
here, though the advantage of inserting full-blown language at any point rather than
constantly adding irregular flavoring to the script language...)
Ive looked at this for years, bouncing back and forth between custom byte code
interpretor/compiler and native code and data driven mechanisms (FSM using data).
My current project will be an attempt to use MACROs (behavior scripts) ontop of a
C++ engine and maybe a simple script language for terrain/unit creation, it being more
an RPG style sim/game and much more irregular generation via recursive template
and class mechanisms (class/template in a generic sense not as C++ stuff).
Of course Im implementing heavy duty AI which is a CPU pig even with optomized
C++ (and I still expect to need clustered CPU even with the next generaion speeds)
tel...@xenon.triode.bogus.au
> I agree. I'm sure that any of the commercial Lisp vendors would be
> quite happy to discuss doing this kind of extension for you for a fee.
> Like you I'm fed up with the stupid `oh you can just implement it
> yourself because you have *source*, which solves everything' mantra
> that the open source cultists repeat endlessly when they're not
> burning each other or stealing music from people.
(or (and (got-the-source)
(or (and (feel-up-to-the-job)
(time-to-build-it)
(build-it-yourself))
(and (know-someone-good)
(offer-cash-to-friend))
(and (advertise-on-usenet)
(trust-stranger)
(offer-cash-to-stranger))))
(offer-cash-to-vendor))
;;; Probability of success when (got-the-source) can be proven
;;; to be no worse than when (not (got-the-source)) and usually
;;; is considerably higher because of greater options.
;;; HOMEWORK: rewrite the above to always follow the least-cost
;;; path and prove that (got-the-source) will never increase
;;; that cost over and above (not (got-the-source)) but may
;;; decrease cost.
;;; HINT: use (min ...) (max ...) rather than (and ...) (or ...)
- Tel
Brandon J. Van Every
>
> ;;; HOMEWORK: rewrite the above to always follow the least-cost
> ;;; path and prove that (got-the-source) will never increase
> ;;; that cost over and above (not (got-the-source)) but may
> ;;; decrease cost.
Understanding source code consumes time, and if the source code does not
turn out to do the job wanted, that is time down the drain for nothing.
Also it takes time to identify usable source code in the first place.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
Brandon J. Van Every
>
> Ive looked at this for years, bouncing back and forth between custom
> byte code interpretor/compiler and native code and data driven
> mechanisms (FSM using data).
I have despaired of all of this language hunting. My conclusion is that for
lowish-level 3D graphics, nothing is any better than C++. This is
depressing because C++ is not a good language in a number of ways, and it
certainly isn't an interesting / labor saving language. I wish that in 2004
that language technologies didn't basically suck for 3D graphics, that
something more sophisticated had emerged by now, but industry moves
sloooooooooowly and it hasn't.
These general purpose virtual machines for C# and Java are never going to be
any good for 3D graphics. The market volume is in boring apps like
accounting software. On CPUs, 3D graphics performance is a "native code
thing." Virtual machines are used successfully in 3D HW for vertex / pixel
shaders, ala HLSL, but that's because the problem is totally locked into 3D
graphics and nothing else. Sadly, vertex / pixel shaders are not
interesting for computational geometry.
If I had time to learn how to write a proper 3D graphics language, I would
do so, but I don't. So it's punting with C++ until my designs stabilize and
higher level, sloppy languages become appropriate.
Sergio Roa Ovalle
Brandon> If I had time to learn how to write a proper 3D graphics
Brandon> language, I would do so, but I don't. So it's punting
Brandon> with C++ until my designs stabilize and higher level,
Brandon> sloppy languages become appropriate.
I am not an expert in computer graphics efficient programming, but
sometime I heard about the Cg language developed by Nvidia. I don't
know if that might really interest you:
http://developer.nvidia.com/page/cg_main.html
Anyway, I wonder if you are interested in programming GPUs
specifically from NVidia ;). Taking into account that these processors
are specially designed for high performance computing tasks, that
could be a good election, couldn't it be?
I read the FAQ, and I found out that the specification is open and the
NVidia compiler technology is open source:
http://www.nvidia.com/object/cg_faq.html
--
Sergio Roa Ovalle
Key fingerprint = 5427 E535 8E18 8B3B C38B ADB5 9DF5 89DE FBF4 738C
Brandon J. Van Every
> Brandon J Van Every escribió (Wed, 28 Jan 2004 14:26:40 -0800):
>
> Brandon> If I had time to learn how to write a proper 3D graphics
> Brandon> language, I would do so, but I don't. So it's punting
> Brandon> with C++ until my designs stabilize and higher level,
> Brandon> sloppy languages become appropriate.
>
> I am not an expert in computer graphics efficient programming, but
> sometime I heard about the Cg language developed by Nvidia. I don't
> know if that might really interest you:
>
> http://developer.nvidia.com/page/cg_main.html
>
> Anyway, I wonder if you are interested in programming GPUs
> specifically from NVidia ;). Taking into account that these processors
> are specially designed for high performance computing tasks, that
> could be a good election, couldn't it be?
Vertex / pixel shader hardware is only designed to handle the vertex / pixel
shader problem. Much as I'd like those circuits to become a general purpose
3D graphics computing resource, they aren't, and they won't be. It's a
strictly one-way ticket from the CPU to the GPU to the screen.
Stupid shader tricks are moderately useful for decompression of procedural
models, if your output is ultimately vertices and pixels. But such
decompressions have to be relatively simple, there's only so many
instructions these GPUs were designed to execute, and only so many flow
control constructs available.
On the other hand, *if* all you want to do is work on vertex / pixel shader
problems, HLSL is indeed a properly designed language for that 3D graphics
task.
Sergio Roa Ovalle
Brandon> Vertex / pixel shader hardware is only designed to handle
Brandon> the vertex / pixel shader problem. Much as I'd like
Brandon> those circuits to become a general purpose 3D graphics
Brandon> computing resource, they aren't, and they won't be. It's
Brandon> a strictly one-way ticket from the CPU to the GPU to the
Brandon> screen.
What possibilities should offer a properly-designed graphics language?
Is it not a matter of different specific optimized libraries? For
example, a library to handle approppriately graph algorithms, I don't
know...
Bill Bouma
> If I had time to learn how to write a proper 3D graphics language, I would
> do so, but I don't. So it's punting with C++ until my designs stabilize and
> higher level, sloppy languages become appropriate.
What exactly is a proper 3D language? I have been writing a new
language you might like or might not. It has stuff like matrix,
quaternion, and vector operations built in. It has a built in
differential equations solver and physics simulator built on that.
But it doesn't really do anything with graphics yet and maybe it
doesn't have to. An external C++ program can read the geometry
out of memory and display it. It is pretty cool. I basically
have been scarfing what I think are the best ideas out of other
languages and puting them in mine. If you have any great ideas
I might use them. And all of my stuff compiles in both visualc++
and on linux. Language isn't quite done yet, though. Still a
few puzzles to solve and features to add. Example, it needs a
(real) garbage collector.
Bill
Santa Clara, CA
Brandon J. Van Every
> Brandon J Van Every escribió (Wed, 28 Jan 2004 23:37:13 -0800):
>
> Brandon> Vertex / pixel shader hardware is only designed to handle
> Brandon> the vertex / pixel shader problem. Much as I'd like
> Brandon> those circuits to become a general purpose 3D graphics
> Brandon> computing resource, they aren't, and they won't be. It's
> Brandon> a strictly one-way ticket from the CPU to the GPU to the
> Brandon> screen.
>
> What possibilities should offer a properly-designed graphics language?
> Is it not a matter of different specific optimized libraries?
No. 3D graphics algorithms have many simple parts that in an ideal
optimization universe, should be ruthlessly recombined with each other in
great quantities. The problems have a smaller "grain" than what libraries
can handle.
> For
> example, a library to handle approppriately graph algorithms, I don't
> know...
That's way higher level than what I'm talking about. A proper 3D graphics
language would have optimizations for *traversing* that graph. In fact,
that is exactly a problem I'm working on right now. Intel SSE sucks as
usual.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
Brandon J. Van Every
> Brandon J. Van Every wrote:
>
>> If I had time to learn how to write a proper 3D graphics language, I
>> would do so, but I don't. So it's punting with C++ until my designs
>> stabilize and higher level, sloppy languages become appropriate.
>
> What exactly is a proper 3D language? I have been writing a new
> language you might like or might not. It has stuff like matrix,
> quaternion, and vector operations built in.
That's a good start!
> It has a built in
> differential equations solver and physics simulator built on that.
> But it doesn't really do anything with graphics yet and maybe it
> doesn't have to.
That's a bad sign.
> An external C++ program can read the geometry
> out of memory and display it. It is pretty cool. I basically
> have been scarfing what I think are the best ideas out of other
> languages and puting them in mine. If you have any great ideas
> I might use them. And all of my stuff compiles in both visualc++
> and on linux.
Huh, real cross-platform support. Well, let me know when you're ready to
show your code to the world.
tel...@xenon.triode.bogus.au
> tel...@xenon.triode.bogus.au wrote:
>>
>> ;;; HOMEWORK: rewrite the above to always follow the least-cost
>> ;;; path and prove that (got-the-source) will never increase
>> ;;; that cost over and above (not (got-the-source)) but may
>> ;;; decrease cost.
> Understanding source code consumes time, and if the source code does not
> turn out to do the job wanted, that is time down the drain for nothing.
> Also it takes time to identify usable source code in the first place.
Yup, takes time to identify a usable proprietary package too.
Most vendors of proprietary solutions will give you a lot LESS information
about what their package is and how it works so you are forced to do your
evaluation from a position of ignorance. If it turns out not to do what you
wanted then you will only figure out what is missing after 6 months and
thousands of dollars spent. If you enjoy that cosy feeling of security that
only complete ignorance brings then have fun.
Suppose you are using your MS compiler and you write a nice clean algorithm
in C++ but then the compiler produces some crappy inefficient assembler
for your nice routine. You look at it and see that the C++ should optimise
cleanly but the compiler is too dumb to realise how to handle it.
Do you:
[A] rewrite your C++ five different ways until you hit something
that the compiler can figure out how to optimise properly
(which is trial and error because the compiler is a black box).
[B] rewrite the whole thing in hand optimised assembler and then have
a maintenance issue forever.
[C] buy the latest version of the compiler in the hope that the
optimiser is better.
[D] complain to Microsoft in the desperate hope that they give a toss.
[E] switch the entire project to some other compiler.
[F] forget about optimisation.
None of these options are good, and this situation cannot be predicted
before you buy the compiler and spend a long time using it.
Now, if you have source code for your tools you have a bunch of ADDITIONAL
options plus you have ALL the options above, at least option [A] is easier
if you peek at what the optimiser is doing and usually option [C] is
cheaper because open source projects are typically cheaper to upgrade.
- Tel
Brandon J. Van Every
>> not
>> turn out to do the job wanted, that is time down the drain for
>> nothing.
>> Also it takes time to identify usable source code in the first place.
>
> Yup, takes time to identify a usable proprietary package too.
> Most vendors of proprietary solutions will give you a lot LESS
> information
> about what their package is and how it works so you are forced to do
> your
> evaluation from a position of ignorance. If it turns out not to do
> what you
> wanted then you will only figure out what is missing after 6 months
> and
> thousands of dollars spent. If you enjoy that cosy feeling of
> security that
> only complete ignorance brings then have fun.
That's not entirely true. Proprietary solutions, as a matter of market
reality, often have more users. So you can ask them what their experiences
are, and read archives of their wailings. It's very much a drag to do any
archive hunt for the skinny on any tool, however. There is not time to do
it for every option out there.
> Suppose you are using your MS compiler and you write a nice clean
> algorithm
> in C++ but then the compiler produces some crappy inefficient
> assembler
> for your nice routine. You look at it and see that the C++ should
> optimise
> cleanly but the compiler is too dumb to realise how to handle it.
>
> Do you:
>
> [A] rewrite your C++ five different ways until you hit something
> that the compiler can figure out how to optimise properly
> (which is trial and error because the compiler is a black box).
Yes I do, because once learned, the principles apply to all code that I will
write with that compiler. FWIW I don't feel like doing that with Visual
C++, I've done it enough to have a sense of its capabilities, if not an
exacting sense. And my verdict is: it's a POS.
> [B] rewrite the whole thing in hand optimised assembler and then
> have a maintenance issue forever.
Small, carefully planned amounts of ASM code are not maintenance issues.
I've done it, will do it again when it's appropriate. For some kinds of
problems, like aggressive use of Intel SSE, you have no other choice.
> [C] buy the latest version of the compiler in the hope that the
> optimiser is better.
Never. Nothing has gotten better in VC++ from 6.0 to 7.0 to 7.1. I bought
my upgrades for .NET compatibility and because I could get 'em cheap, not
compiler performance.
> [D] complain to Microsoft in the desperate hope that they give a
> toss.
Not worth bothering. They're writing accounting software.
> [E] switch the entire project to some other compiler.
Definitely possible. One of the Intel C++ guys has been talking me up. I'm
leery, but since it looks like my low level code will be stuck in C++ land
indefinitely, I will try their compiler.
> [F] forget about optimisation.
I can't bring myself to do it.
> None of these options are good,
I disagree. [A] [B] [E] are definitely realistic options, although nowadays
I'd avoid [B] until the design is stabilized. That can take awhile.
> and this situation cannot be predicted
> before you buy the compiler and spend a long time using it.
Lotsa people do experiments with compilers, the information is out there.
The only problem with that kind of information is it's like reading game
reviews. You always get mixed opinions. I've heard enough people say
Intel's compiler output is lousy to make me leery. But enough positives to
try it.
It also doesn't take me that long to shake out a compiler. As far as ASM
output goes, I know what I'm looking for.
> Now, if you have source code for your tools you have a bunch of
> ADDITIONAL options
How? I don't have the time to screw around with GCC's gory internals.
> plus you have ALL the options above, at least option [A] is easier
Careful of options, you may get what you ask for!
> if you peek at what the optimiser is doing and usually option [C] is
> cheaper because open source projects are typically cheaper to upgrade.
Peeking at the optimizer isn't the issue. *Changing* the optimizer is the
issue. Changing stuff around can be prohibitively expensive to your
development time. What you want is a solution done right in the first
place, so that you don't have to do any work. Beit open source or
proprietary. Commercial people aren't religious, they're looking for
off-the-shelf solutions. Tinkering with the sources is not an off-the-shelf
solution.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
Eternal Vigilance
"Brandon J. Van Every" wrote:
I think I was trying to say -- the graphics probably will be a tiny part
of your entire project and write that in whatever it runs best (you are going to
have to tie in with opengl or directx anyway -- external data restrictions
etc..)
If you are heavily dependent on geometry crunching then you write
a library in whatever language is best (fastest) and get it out of the way.
The majority of the project (if its a complete game) will be other stuff
that will eventually feed data to the geometry/graphics.
And that language use is where your 'ease of use' features are most
important (most productivity impact) .
John Atwood
>> I am not sure I undestand the last criteria.
>> SSE is hardware support for various operations usually used in linear
>> algeba used mostly for 3d gaphics.
>
>3D graphics, ha! You're making me laugh. In my experience, SSE was
>designed for image processing and multimedia, not 3D graphics. For
>instance, the lack of a "sum of scalar fields" instruction, essential for
>dot products and rather helpful for matrices as well. We'll have to wait
>for the Prescott New Instructions to get a half-assed fix for that, and
>it'll still take 2 HADDPS instructions to do the job. Since the newfangled
>chips with PNI will still be called "Pentium 4," how easy do you think it's
>going to be to product spec that? But enough of this rant. Thanks for the
>chuckle.
>
>> http://www.tommesani.com/Download/QuexalDemo.exe
>> contains a program that can help generate and debug SSE code and make
>> a C wapper and the like.
>
>Looks like that's only integer SSE code though. I'm mainly doing 32-bit
>floats.
Have you looked at the BrookGPU project? It might suit your needs.
John
Fergus Henderson
>Can anyone tell me of a language + compiler that
>
>1) runs on Windows
>2) has support for lists in the language syntax itself, not just as a
>standard library
>3) supports Intel SSE instructions in some manner
Mercury supports all of those, I think.
Regarding (3), Mercury supports inline C, and then you can either use the
new GCC intrinstic functions for SSE, or write inline assembler inside
the inline C. You won't have to pay the overhead of a function call in
the generated code.
Regarding (2), there is special syntactic sugar for lists, but other than
that lists are not treated specially; you need to import the standard library
"list" module to use them.
Regarding (1), I think there were some minor problems with building
Mercury from source on Windows in the current official release (0.11.0).
These have long since been fixed in the stable release branch versions
(0.11.1-beta*) which you can download from our web site.
We never got around to issuing an official 0.11.1 release, but
the 0.11.1-betas are just as stable as 0.11.0.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.