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
A proper performance-oriented language would handle lists as efficiently
they could be handled.
--
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)
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
Pascal Costanza
Brandon J. Van Every wrote:
> 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.
Apparently, you expect Lisp to be the same "total shit for tools" like
any other language.
Are actually interested in responses to your original question? It
explicitly included the possibility of "some other form of tedious
manual labor" to achieve your goal.
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
Edi Weitz
> Are [you] actually interested in responses to your original
> question?
I think it should be clear by now that he's a troll.
Edi.
Gareth McCaughan
> Brandon J. Van Every wrote:
>
> > 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.
>
> Apparently, you expect Lisp to be the same "total shit for tools" like
> any other language.
>
> Are actually interested in responses to your original question? It
> explicitly included the possibility of "some other form of tedious
> manual labor" to achieve your goal.
I think that was only if it didn't involve having to touch
Common Lisp. Why he was posting in c.l.l, I can't imagine.
--
Gareth McCaughan
.sig under construc
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
Adam Warner
I just happened upon the following topic when browsing comp.lang.asm.x86.
It was posted two minutes after the topic "convenient list syntax + SSE
support?":
Subject: Intel SSE sucks dogshit for 3D graphics
From: "Brandon J. Van Every" <try_vanevery_a...@yahoo.com>
Regards,
Adam
Adam Warner
I just happened upon the following topic when browsing comp.lang.asm.x86.
It was posted two minutes before the topic "convenient list syntax + SSE
support?":
Subject: Intel SSE sucks dogshit for 3D graphics
From: "Brandon J. Van Every" <try_vanevery_a...@yahoo.com>
Regards,
Adam
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
Pascal Costanza
Adam Warner wrote:
Oh yes, googling for his name is actually an eye opener. Thanks for this
hint...
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
> Brandon J. Van Every wrote:
>
>> 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.
>
> Apparently, you expect Lisp to be the same "total shit for tools" like
> any other language.
Yes, actually I do. I expect there to be several departments in which Lisp
is total shit. For instance, adherence to standards. I've yet to run into
a language that isn't total shit at something, that's why there are
different languages instead of just 1 UberLanguage. If I ever find a
language that's actually decent at the problem domains I regularly worry
about, I'll stop language shopping.
If you tell me I'm supposed to take "writing ASM compilers in Lisp is easy!"
on faith, sorry, but I will laugh. And look for a solution I can take
seriously.
> Are actually interested in responses to your original question? It
> explicitly included the possibility of "some other form of tedious
> manual labor" to achieve your goal.
"Marching into the detention area is not what I had in mind." - Han Solo
Brandon J. Van Every
I think it should be clear by now that there isn't a Lisp implementation
with proper Intel SSE support, and some of you are whinging about why that
shouldn't be a problem.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"Troll" - (n.) Anything you don't like.
Usage: "He's just a troll."
Brandon J. Van Every
>
> Oh yes, googling for his name is actually an eye opener. Thanks for
> this hint...
Apparently you are another person who makes snap decisions at first glance,
rather than understanding what's being asked, what's being discussed, and
what plainly stated motives are.
--
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
> Pascal Costanza <cost...@web.de> writes:
>>
>> Are actually interested in responses to your original question? It
>> explicitly included the possibility of "some other form of tedious
>> manual labor" to achieve your goal.
>
> I think that was only if it didn't involve having to touch
> Common Lisp. Why he was posting in c.l.l, I can't imagine.
I never said any such thing. I said I won't finish someone's broken
compiler for them.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"witch-hunt" - (noun) (Date: 1885)
1: a searching out for persecution of persons accused
of witchcraft
2: the searching out and deliberate harassment of
those (as political opponents) with unpopular views
- witch-hunter (noun)
- witch-hunting (noun or adjective)
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
> Hi Edi Weitz,
>>
>
> I just happened upon the following topic when browsing
> comp.lang.asm.x86.
> It was posted two minutes before the topic "convenient list syntax +
> SSE support?":
>
> Subject: Intel SSE sucks dogshit for 3D graphics
> From: "Brandon J. Van Every"
> <try_vanevery_a...@yahoo.com>
You didn't care to note the substance of the post, namely "I'm happy to be
proven wrong."
Nor did you note the other post I made at the same time: "convenient list
synatx + SSE support?" Essentially a refinement of my question based on
feedback from this thread, and addressed to the most appropriate venue.
Yes it's cognitive dissonance. I'm pretty close to saying "screw Intel and
SSE forever." As a DEC Alpha ex-pat I've actively hated Intel for 6 years
now, they're 1/2 of what made my favorite CPU go bye-bye. (The other 1/2
being DEC itself, not being able to market its way out of a paper bag.) But
I want to make sure I haven't made an error of understanding somewhere.
Personally, I think I "get it." SSE sucks for 3D. This is just the final
round of checking before I make a decision about how far away I'll stay from
Intel SSE, as an architectural consideration.
Incidentally, nobody else's 4-field vector instructions do any better, last
I looked. They're all missing "sum of scalar fields."
As for general trollishness, all kinds of people in all kinds of language
newsgroups call me a troll. It happens anytime I ask tough questions about
people's language religion. Like, why doesn't Lisp have full IA-32
instruction support in it, and what about Lisp culture might be responsible
for that. Or why doesn't Python market itself more aggressively. Or
whatever other point of sanity pushes people's buttons. Linuxers,
academics, and hobbyists hate me, and I hate them. We're not in the same
worlds of concern, and for my purposes, the stuff they produce is utter
crap.
--
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)
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! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick
Goddamn, I'm normally careful about responding to trolls. In
retrospect, I should've seen it coming, but he got me calmly irate.
Well, I can say one thing good, I guess that makes him a good troll :-P
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
| Apparently you are another person who makes snap decisions at first
| glance, rather than understanding what's being asked, what's being
| discussed, and what plainly stated motives are.
Another? Who was the /first/ such person?
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
Christophe Rhodes
> Edi Weitz wrote:
>> On Sat, 24 Jan 2004 00:22:08 +0100, Pascal Costanza <cost...@web.de>
>> wrote:
>>
>>> Are [you] actually interested in responses to your original
>>> question?
>>
>> I think it should be clear by now that he's a troll.
>
> I think it should be clear by now that there isn't a Lisp implementation
> with proper Intel SSE support, and some of you are whinging about why that
> shouldn't be a problem.
<http://www.geocrawler.com/lists/3/SourceForge/1663/0/6811094/>
No, it's not by any means "proper Intel SSE support", and in any case
the implementation under discussion doesn't run on Windows anyway, but
please take this as further evidence that the lack of explicit support
for something in a lisp compiler doesn't mean that it's incredibly
hard to add support for that something, particularly when it's as
simple as a few opcodes.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes
Tim Bradshaw <t...@cley.com> writes:
> 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.
Plenty of the open source Lisp vendors would also be quite happy to
discuss doing this kind of extension for you for a fee. For something
as simple as making instructions available for inline assembly, that
fee would probably not be excessively large.
> Like I want to spend hundreds of hours wading through megabytes of
> crappily-written code to try and implement some feature.
Charmed, I'm sure.
Frank Andreas de Groot
>
> > 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.
I use 64-bit assembly (MMX) where it brings a strong performance increase (but I
leave the Pascal equivalent in the source). And I've looked deeply into a FPGA
solution as well, even bought a FPGA dev kit. My speed concerns are real and
based on extensive (more than a few decades) of experience with speed-efficient
coding.
I will NEVER speed up something if it does not increase the bottom line, though.
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++.)
Tim Bradshaw
> Plenty of the open source Lisp vendors would also be quite happy to
> discuss doing this kind of extension for you for a fee. For something
> as simple as making instructions available for inline assembly, that
> fee would probably not be excessively large.
Yes, of course, I didn't mean to exclude them. Does anyone offer
realistic commercial support for OSS CLs (this isn't a sarcastic
question).
--tim
Bulent Murtezaoglu
TB> ... Does anyone
TB> offer realistic commercial support for OSS CLs (this isn't a
TB> sarcastic question).
Off the top of my head:
http://web.metacircles.com/Support
cheers,
BM
Christophe Rhodes
Last time we had this discussion, you seemed to imply that there were
contexts for which there was no "realistic" Lisp support options at
all, even from commercial vendors (see Message-ID
<ey3llxg...@cley.com>). So before I attempt to answer your
question, I'd like to know what kinds of things you'll shoot down as
being unrealistic in this context (remember, this specific discussion
has been sparked by the unavailability of a particular set of opcodes
in Lisp compilers out-of-the-box).
Maybe to put it another way: how much do you, or the original poster,
need to be able to sue the OSS CL supporter in damages for?
Duane Rettig
> Adam Warner wrote:
> > Hi Edi Weitz,
> >>
> >> I think it should be clear by now that he's a troll.
> >
> > I just happened upon the following topic when browsing
> > comp.lang.asm.x86.
> > It was posted two minutes before the topic "convenient list syntax +
> > SSE support?":
> >
> > Subject: Intel SSE sucks dogshit for 3D graphics
> > From: "Brandon J. Van Every"
> > <try_vanevery_a...@yahoo.com>
>
> You didn't care to note the substance of the post, namely "I'm happy to be
> proven wrong."
> Nor did you note the other post I made at the same time: "convenient list
> synatx + SSE support?" Essentially a refinement of my question based on
> feedback from this thread, and addressed to the most appropriate venue.
The "most appropriate venue" for asking a Lisp question of vendors is
to the vendors themselves. That is why you are being called a troll.
It's what I thought at first, but now I just think you don't have a
very effective methodology for finding out information.
> Yes it's cognitive dissonance. I'm pretty close to saying "screw Intel and
> SSE forever." As a DEC Alpha ex-pat I've actively hated Intel for 6 years
> now, they're 1/2 of what made my favorite CPU go bye-bye. (The other 1/2
> being DEC itself, not being able to market its way out of a paper bag.) But
> I want to make sure I haven't made an error of understanding somewhere.
> Personally, I think I "get it." SSE sucks for 3D. This is just the final
> round of checking before I make a decision about how far away I'll stay from
> Intel SSE, as an architectural consideration.
It's interesting how you've gone from blasting Lisp implementations
for not supporting SSE to not wanting SSE at all. Not only do you
not know how to get the infrmation you want, but you don't know what
you want.
> Incidentally, nobody else's 4-field vector instructions do any better, last
> I looked. They're all missing "sum of scalar fields."
>
> As for general trollishness, all kinds of people in all kinds of language
> newsgroups call me a troll. It happens anytime I ask tough questions about
> people's language religion. Like, why doesn't Lisp have full IA-32
> instruction support in it, and what about Lisp culture might be responsible
> for that. Or why doesn't Python market itself more aggressively. Or
> whatever other point of sanity pushes people's buttons. Linuxers,
> academics, and hobbyists hate me, and I hate them. We're not in the same
> worlds of concern, and for my purposes, the stuff they produce is utter
> crap.
Who's left? Lispers? Is that why you're here?
As for a real answer, I don't owe you one - you should go to each vendor
and ask. But for the sake of information exchange in the group as a
whole, I'll tell you how I see it:
I certainly wish I could support SSE/SSE2; the pseudo-stack-based fp
register architecture of the x87 style is the worst architecture I've
ever seen. It's a good idea gone terribly bad. If one is going to
implement a stack, one must make the stack large enough to actually
implement normal code without spilling over all the time. 7 fp registers
is not a large enough stack to do anything more than demonstration
calculations. Fortunately, with the 486, some instructions were added
to allow the fp registers to be accessed _as_ _if_ they were random-
access registers, as should have been the case from the beginning.
But such a hack makes the fp unit still incredibly slow.
So why, if Intel made SSE/SSE2 standard in P3, don't we put out a lisp
that uses such a hands-down better architecture? Simple. Many of
our customers don't buy Intels; they buy AMDs. And AMD didn't start
supporting SSE/SSE2 until they came out with their x86-64 architecture,
where it is standard (and even the calling convention has SSE xmm
registers as the standard parameter passing locations.
You can bet we will be supporting SSE/SSE2 on our x86-64 version.
But unless/until there are no more x86 chips in the field that
don't have SSE/SSE2 support, we won't put out a 32-bit lisp that
compiles to those instructions, because there would be a large portion
of our market that would not be able to run our lisp.
One other question that might come to mind is "why not allow the
option to compile to SSE/SSE2"? This is a valid question, and I'm
not sure how other vendors would respond. Certainly, I view at
least the Common Lisp community as placing portability as a high
priority. We have in the past created hardware-testing options that
checked the machine for, say, a hardware multiply instruction (we
did this on sparcs, for example, when we had both v7 and v8 architectures
out there, and the v7 multiply was slowed down by 10x when an emulation
trap was taken, but the v8 architecture was 10x slower to do the software
version vs the hardware version. A short timing loop at the start of
the lisp reavealed which multiply to use). We tend to add these decision
paths in such a way that the user need not specify an option, nor will
the user have to recompile any code. This emphasis on portability is
what drives us to only support common architectural features.
Finally, Allegro CL 6.2 does allow some SSE/SSE2 hand-compilation,
but it is undocumented, and you would have to talk to us about it,
as is always the appropriate thing to do when it is desired to know
whether a feature exists on a Lisp or not.
--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
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.
Tim Bradshaw
> Maybe to put it another way: how much do you, or the original poster,
> need to be able to sue the OSS CL supporter in damages for?
This depends on what you need. If I was using some tool for
exploratory programming I'd hope for some best-effort thing and expect
to pay accordingly. If I'm a large telco, and the systems in my data
centre through which my income stream comes depend on this thing I'd
want a contract with considerably more teeth (and expect to pay
accordingly). One size does not, in fact, fit all, and yes, there are
contexts where I'd be fairly nervous about how supportable Lisp
systems are.
--tim
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
> As for general trollishness, all kinds of people in all kinds of language
> newsgroups call me a troll.
Go figure.
--
~jrm
Joe Marshall
> I cannot abide a Lisp culture of "everyone rolls their own," instead
> of expecting certain basic things to be standard and off-the-shelf.
Yet here you are.
> Why am I sitting around arguing about my production concerns with you?
Why indeed?
> 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.
That's the best idea you've posted.
--
~jrm
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
Brandon J. Van Every
>>
>> Subject: Intel SSE sucks dogshit for 3D graphics
>> From: "Brandon J. Van Every"
>> <try_vanevery_a...@yahoo.com>
>
> You didn't care to note the substance of the post, namely "I'm happy
> to be proven wrong."
And returning briefly just to rub it in, 3 very experienced people agreed
with me, and so far nobody has disagreed with me. I am vindicated. Maybe
you should evaluate whether a rant is actually correct, before condemning
someone for posting a rant and labeling them a troll.
> Nor did you note the other post I made at the same time: "convenient
> list synatx + SSE support?" Essentially a refinement of my question
> based on feedback from this thread, and addressed to the most
> appropriate venue.
Crickets are still chirping on that one.
As for resolving my cognitive dissonance about Intel SSE, someone else has
pointed out that I should probably start asking about indicators of overall
language performance rather than SSE specifically. So that I will do, but
not here.
Pascal Costanza
Brandon J. Van Every wrote:
> As for resolving my cognitive dissonance about Intel SSE, someone else has
> pointed out that I should probably start asking about indicators of overall
> language performance rather than SSE specifically. So that I will do, but
> not here.
In your original posting, you have stated that support for Intel SSE is
a hard requirement. This sounded like a well-thought requirement. I
agree with Duane by now that you obviously don't know what you want.
Since you have said that you want to implement games (or was this a
similarly "hard" requirement?), you or others might be interested in
this story:
http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml
Some quotes from that page:
"Lisp was just the best solution for this job," comments Gavin. "With
leading edge game systems like ours, you have to deal with complicated
behaviors and real-time action. Languages like C are very poor with
temporal constructs. C is just very awkward for a project like this.
Lisp, on the other hand, is ideal."
As Gavin explains, "With Lisp, one can rapidly develop meta constructs
for behaviors and combine them in new ways. In addition, Lisp allows the
redefinition of the language to easily add new constructs; particularly
those needed to deal with time-based behaviors and layering of actions.
Contrary to popular belief, there is nothing inherently slow about Lisp.
It is easy to construct a simple dialect which is just as efficient as
C, but retains the dynamic and consistent qualities that make Lisp a
much more effective expression of one’s programming intentions."
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Joe Marshall
> Brandon J. Van Every wrote:
> [snip]
>
> Since you have said that you want to implement games (or was this a
> similarly "hard" requirement?), you or others might be interested in
> this story:
> http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml
According to Google he's been looking for reasons to procrastinate
game writing since last September.
--
~jrm
Adam Warner
> So why, if Intel made SSE/SSE2 standard in P3, don't we put out a lisp
> that uses such a hands-down better architecture? Simple. Many of our
> customers don't buy Intels; they buy AMDs. And AMD didn't start
> supporting SSE/SSE2 until they came out with their x86-64 architecture,
> where it is standard
The AMD Athlon XP has SSE (but not SSE2) support.
It's likely you can't even support x87 on AMD64 Windows. This appears to
be a limitation of the Windows implementation though AMD does their best
to disguise it:
<http://www.amd.com/us-en/assets/content_type/DownloadableAssets/AMD64_Porting_FAQ.pdf>
Can x87 instructions still be used by 64-bit applications?
64-bit applications cannot use x87 instructions because 64-bit
operating systems are not required to preserve the x87 stack across
interrupts and context switches. AMD has gone to great lengths to
ensure that SSE/SSE2 math library performance and accuracy exceeds that
of the x87 instruction set. We anticipate no need to use x87
instructions in 64-bit applications.
I suspect this is misleading. x87 does 80-bit extended double-float
precision. Plus as I recall from reading some of the AMD64 processor specs
a while ago there was no performance advantage from using SSE2 over x87
for non-parallel double floating point computations (my recollection could
be mistaken and needs to be verified before being relied upon).
Yesterday I found this passage in the AMD64 Linux ABI (page 68) which
appears to be a concrete statement that x87 calculations are supported in
AMD64 Linux: <http://www.x86-64.org/abi.pdf>
A.2.3 Miscelleaneous Remarks
Linux Kernel code is not allowed to change the x87 and SSE units. If
those are changed by kernel code, they have to be restored properly
before sleeping or leaving the kernel. On preemptive kernels also
more precautions may be needed.
I understand Microsoft's approach is to not assure the restoration of the
x87 unit after kernel calls in 64-bit mode, thereby rendering the x87 unit
unusable.
The good news for Common Lisp implementations like CMUCL and SBCL which
primarily run upon Linux is that the x87 backends should not have be
rewritten for them to work upon x86-64 Linux.
I am puzzled why AMD is being so cryptic about use of the x87 unit in
64-bit mode. Surely there aren't so many x86-64 operating systems that
AMD is unable to contrast their differences in an FAQ.
I have cross-posted this reply to comp.sys.ibm.pc.hardware.chips as they
may appreciate the x87 AMD64 ABI paragraph and be able to contribute
further information (I am a long time c.s.i.p.h.chips lurker and this
topic has been discussed quite extensively).
Regards,
Adam
Duane Rettig
> Hi Duane Rettig,
>
> > So why, if Intel made SSE/SSE2 standard in P3, don't we put out a lisp
> > that uses such a hands-down better architecture? Simple. Many of our
> > customers don't buy Intels; they buy AMDs. And AMD didn't start
> > supporting SSE/SSE2 until they came out with their x86-64 architecture,
> > where it is standard
>
> The AMD Athlon XP has SSE (but not SSE2) support.
Right; this only gives you single-float support; to get double-floats,
you need SSE2.
> It's likely you can't even support x87 on AMD64 Windows. This appears to
> be a limitation of the Windows implementation though AMD does their best
> to disguise it:
> <http://www.amd.com/us-en/assets/content_type/DownloadableAssets/AMD64_Porting_FAQ.pdf>
>
> Can x87 instructions still be used by 64-bit applications?
>
> 64-bit applications cannot use x87 instructions because 64-bit
> operating systems are not required to preserve the x87 stack across
> interrupts and context switches. AMD has gone to great lengths to
> ensure that SSE/SSE2 math library performance and accuracy exceeds that
> of the x87 instruction set. We anticipate no need to use x87
> instructions in 64-bit applications.
>
> I suspect this is misleading. x87 does 80-bit extended double-float
> precision. Plus as I recall from reading some of the AMD64 processor specs
> a while ago there was no performance advantage from using SSE2 over x87
> for non-parallel double floating point computations (my recollection could
> be mistaken and needs to be verified before being relied upon).
Empirically, I see about a 30% to 50% speedup in floating point on
otherwise similarly performing x86 vs x86-64 lisps. Be aware, though,
that of course these are benchmarks, and so you will likely not see
the same numbers I see right now (and in fact, I will likely not see
the same numbers next time I try it as what I see right now, just because
they are benchmarks :-).
> Yesterday I found this passage in the AMD64 Linux ABI (page 68) which
> appears to be a concrete statement that x87 calculations are supported in
> AMD64 Linux: <http://www.x86-64.org/abi.pdf>
>
> A.2.3 Miscelleaneous Remarks
>
> Linux Kernel code is not allowed to change the x87 and SSE units. If
> those are changed by kernel code, they have to be restored properly
> before sleeping or leaving the kernel. On preemptive kernels also
> more precautions may be needed.
>
> I understand Microsoft's approach is to not assure the restoration of the
> x87 unit after kernel calls in 64-bit mode, thereby rendering the x87 unit
> unusable.
Correct. I think it is a bold move for Microsoft to make to cut off the x87
for 64 bit apps, but perhaps it is safe, since they presumably aren't making
the same change for 32 bit apps. As long as the 32-bit apps don't change,
and the 64-bit apps have to be recompiled anyway, presumably the only
lossage is for any assembler-level programmers who have extensive x87
algorithms built.
> The good news for Common Lisp implementations like CMUCL and SBCL which
> primarily run upon Linux is that the x87 backends should not have be
> rewritten for them to work upon x86-64 Linux.
>
> I am puzzled why AMD is being so cryptic about use of the x87 unit in
> 64-bit mode. Surely there aren't so many x86-64 operating systems that
> AMD is unable to contrast their differences in an FAQ.
I don't see it as being cryptic. If you read the 64-bit ABI carefully it
is completely clear that they support x87 usage, but that they have given
great preference to SSE/SSE2 in the interface. Most float arguments are
passed in "xmm" (SSE/SSE2) registers, and in fact you pass up to 8 float
arguments in these registers, rather than on the stack as is the case
with the 32-bit abi. Note that the little tests that I ran above were
with fp calculations only; once we get to adding actual parameter passing
into the mix, we're probably looking at another good pro for the SSE/SSE2
case.
> I have cross-posted this reply to comp.sys.ibm.pc.hardware.chips as they
> may appreciate the x87 AMD64 ABI paragraph and be able to contribute
> further information (I am a long time c.s.i.p.h.chips lurker and this
> topic has been discussed quite extensively).
Yes, I'd also be interested in what the current thinking is.
Christophe Rhodes
Yes, I know this is your (and the market's, probably) position in
general, but your enquiry this time seemed a little more specific. If
it's not a little more specific, either in relation to your own needs
or to the plausibility of supporting the original poster's request for
an extension to inline assembly abilities, then I don't see why you
bothered asking the question, and I certainly don't see any need to
answer you only to be told that my answer is in fact "unreasonable"
because of some criterion that I'm not going to be told about until I
attempt to answer.
Christophe
(In case anyone else out there is dismayed by my unwillingness to
answer Tim's question directly about support for Open Source lisps:
there _are_ what I consider a priori plausible options, fairly easily
findable by a little guesswork, if not just following a couple of web
links from the startup banner of such a lisp, or from the ALU CLiki.)
Tim Bradshaw
> Yes, I know this is your (and the market's, probably) position in
> general, but your enquiry this time seemed a little more specific.
Absolutely. I was asking whether there were people who supported OSS
Lisps: I hadn't specified `in a large-enterprise-critical context',
and indeed from the context of the original question - someone asking
for enhancements to a compiler for writing games, I think it was clear
that I didn't intend such a context.
I think the kind of twitchy paranoid response I get when I ask these
questions has effectively answered them for me, unfortunately.
--tim
Christophe Rhodes
> * Christophe Rhodes wrote:
>
>> Yes, I know this is your (and the market's, probably) position in
>> general, but your enquiry this time seemed a little more specific.
>
> Absolutely. I was asking whether there were people who supported OSS
> Lisps: I hadn't specified `in a large-enterprise-critical context',
> and indeed from the context of the original question - someone asking
> for enhancements to a compiler for writing games, I think it was clear
> that I didn't intend such a context.
Now that you've made it clear (it wasn't to me), I can feel confident
in naming at least three companies which would have responded
positively to an enquiry for support of this nature: metacircles has
already been pointed out by another poster, but I'm fairly sure that
PMSF and Clozure would likewise have been suitable candidates. Were
the original poster serious, of course.
> I think the kind of twitchy paranoid response I get when I ask these
> questions has effectively answered them for me, unfortunately.
Oh, I don't know; given the context of the thread (I responded to a
post containing the phrase "open source cultists", after all) I think
it's valid to establish the common ground necessary for
communication.
Christophe
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
Adam Warner
> Empirically, I see about a 30% to 50% speedup in floating point on
> otherwise similarly performing x86 vs x86-64 lisps. Be aware, though,
> that of course these are benchmarks, and so you will likely not see the
> same numbers I see right now (and in fact, I will likely not see the
> same numbers next time I try it as what I see right now, just because
> they are benchmarks :-).
That was a fascinating reply (mostly snipped) thanks Duane. Most probably
these speedups can be attributed to the use of the SEE2 unit over the x87
unit. However the floating point speedups could also be related to the
generally superior architecture (e.g. your x86-64 benchmarks could also be
utilising extra integer registers). Eliminating these effects would be
possible by benchmarking SSE2 assembly against x87 assembly in AMD64 mode
upon an operating system that supports both units.
There's no question that parallel single precision floating point can't be
significantly faster using SSE2. As AMD states in their AMD64 Architecture
Programmer's Manual Volume 1: Application Programming on pages 226-227:
One of the most useful advantages of 128-bit media instructions is the
ability to intermix integer and floating-point instructions in the same
procedure, using a register set that is separate from the GPR, MMX, and
x87 register sets. Code written with 128-bit media floating-point
instructions can operate in parallel on four times as many
single-precision floating-point operands as can x87 floating-point code.
This achieves potentially four times the computational work of x87
instructions that take single precision operands. Also, the higher density
of 128-bit media floating-point operands may make it possible to remove
local temporary variables that would otherwise be needed in x87
floating-point code. 128-bit media code is also easier to write than x87
floating-point code, because the XMM register file is flat, rather than
stack-oriented, and in 64-bit mode there are twice the number of XMM
registers as x87 registers. Moreover, when integer and floating-point
instructions must be used together, 128-bit media floating-point
instructions avoid the potential need to save and restore state between
integer operations and floating-point procedures.
I don't however think "128-bit media floating-point instructions can
operate in parallel on four times as many single-precision floating-point
operands as can x87 floating-point code" necessarily translates to
"128-bit media floating-point instructions can operate in parallel on
twice as many double-precision floating-point operands as can x87
floating-point code." My reasoning is that when you perform say an
addition you are already operating upon two double floats at once. The
only speedups may come from the flat register file and twice the number of
xmm registers rather than the CPU's inherent ability to add double floats
faster than the x87 unit.
Since Intel P4 processors are clocked around 50% faster than AMD64
processors it will be interesting to see if the AMD processors can
maintain the same overall floating point performance given their superior
architecture (registers, bandwidth, excellent out-of-order execution and
lower misprediction costs) if they retire the same number of floating
point calculations per clock tick as the P4.
I believe it is fair to classify modern AMD processors as more Lisp and
dynamic language friendly than Intel P4 processors. Pointers and linked
lists defy instruction prediction and Intel's large and growing pipelines
are only useful for selling processors (through higher clock speeds) and
performing well against the kind of finely tuned static code used in some
benchmarks.
Regards,
Adam
Duane Rettig
> Hi Duane Rettig,
>
> > Empirically, I see about a 30% to 50% speedup in floating point on
> > otherwise similarly performing x86 vs x86-64 lisps. Be aware, though,
> > that of course these are benchmarks, and so you will likely not see the
> > same numbers I see right now (and in fact, I will likely not see the
> > same numbers next time I try it as what I see right now, just because
> > they are benchmarks :-).
>
> That was a fascinating reply (mostly snipped) thanks Duane. Most probably
> these speedups can be attributed to the use of the SEE2 unit over the x87
> unit. However the floating point speedups could also be related to the
> generally superior architecture (e.g. your x86-64 benchmarks could also be
> utilising extra integer registers). Eliminating these effects would be
> possible by benchmarking SSE2 assembly against x87 assembly in AMD64 mode
> upon an operating system that supports both units.
Well, as I implied, my methodology was quick-and-dirty. However, I did
account for the integer units' speed differences in my tests, by first
running the same loops on integer code and verifying that they were
approximately the same speed. Then, substituting float operations where
the integer operations were, the gross differences should have been
just measuring the floating units.
> There's no question that parallel single precision floating point can't be
> significantly faster using SSE2.
I'm not sure what you're saying here. Had you meant "can" instead of
"can't"? Or did you really mean to make a comparison between single-
precision and SSE2 (as opposed to SSE)? Note that in general, SSE pertains
to single-float operations, and SSE2 handles double-floats.
Actually, you can; the architecture specifies parallel operations on
floats which have been packed into the 128-bit registers, either two
64-bit or 4 32 bit registers (there are scalar packings of various
sizes, as well).
> My reasoning is that when you perform say an
> addition you are already operating upon two double floats at once. The
> only speedups may come from the flat register file and twice the number of
> xmm registers rather than the CPU's inherent ability to add double floats
> faster than the x87 unit.
No, the speedups described above are due to the fact that they are in
parallel on two or four pairs of operands. So if a packed single-float
add is done (addps) between xmm0 and xmm1, what you are really doing is
taking four single-float value pairs in xmm0 and xmm1 and adding them at
the same time. The SSE hardware is set up to do all four adds at once.
> Since Intel P4 processors are clocked around 50% faster than AMD64
> processors it will be interesting to see if the AMD processors can
> maintain the same overall floating point performance given their superior
> architecture (registers, bandwidth, excellent out-of-order execution and
> lower misprediction costs) if they retire the same number of floating
> point calculations per clock tick as the P4.
I'm not sure about the AMD64 vs the P4, but parallelism will definitely
help SSE/SSE2 vs x87-style fp on either architecture. And even scalar
use of SSE/SSE2 is proving to be easier to get good results from,
because it is hard to compile efficiently for the pseudo-stack-based
fp architecture of the x87 fp unit. SSE/SSE2 registers are all randomly
accessible, and thus easier for most register allocators, which tend to
expect this kind of access.
> I believe it is fair to classify modern AMD processors as more Lisp and
> dynamic language friendly than Intel P4 processors. Pointers and linked
> lists defy instruction prediction and Intel's large and growing pipelines
> are only useful for selling processors (through higher clock speeds) and
> performing well against the kind of finely tuned static code used in some
> benchmarks.
The x86-64 architecture definitely has a number of lisp-friendly features
in it (but they're also more other-language-friendy, as well). For example,
there is a new pc-relative addressing mode which helps immensly in table-
based case statements and in building catch blocks. On the x86 one must do
a call/ret pair or else relocate absolute code in order to grab the current
address in code vectors which might move. With the new "rip-relative"
addressing, no calls need be made, which is also good for the branch
prediction stack.
Adam Warner
>> > Empirically, I see about a 30% to 50% speedup in floating point on
>> > otherwise similarly performing x86 vs x86-64 lisps. Be aware, though,
>> > that of course these are benchmarks, and so you will likely not see the
>> > same numbers I see right now (and in fact, I will likely not see the
>> > same numbers next time I try it as what I see right now, just because
>> > they are benchmarks :-).
>>
>> That was a fascinating reply (mostly snipped) thanks Duane. Most probably
>> these speedups can be attributed to the use of the SEE2 unit over the x87
>> unit. However the floating point speedups could also be related to the
>> generally superior architecture (e.g. your x86-64 benchmarks could also be
>> utilising extra integer registers). Eliminating these effects would be
>> possible by benchmarking SSE2 assembly against x87 assembly in AMD64 mode
>> upon an operating system that supports both units.
>
> Well, as I implied, my methodology was quick-and-dirty. However, I did
> account for the integer units' speed differences in my tests, by first
> running the same loops on integer code and verifying that they were
> approximately the same speed. Then, substituting float operations where
> the integer operations were, the gross differences should have been
> just measuring the floating units.
Fair enough!
>> There's no question that parallel single precision floating point can't be
>> significantly faster using SSE2.
>
> I'm not sure what you're saying here. Had you meant "can" instead of
> "can't"?
Oops. Indeed I did :-) It almost reads right both ways depending upon
where you put the emphasis. There's no question the parallel unit can't
be significantly faster using (four single floats packed into a 128-bit
media register).
>> I don't however think "128-bit media floating-point instructions can
>> operate in parallel on four times as many single-precision floating-point
>> operands as can x87 floating-point code" necessarily translates to
>> "128-bit media floating-point instructions can operate in parallel on
>> twice as many double-precision floating-point operands as can x87
>> floating-point code."
>
> Actually, you can; the architecture specifies parallel operations on
> floats which have been packed into the 128-bit registers, either two
> 64-bit or 4 32 bit registers (there are scalar packings of various
> sizes, as well).
>
>> My reasoning is that when you perform say an
>> addition you are already operating upon two double floats at once. The
>> only speedups may come from the flat register file and twice the number of
>> xmm registers rather than the CPU's inherent ability to add double floats
>> faster than the x87 unit.
>
> No, the speedups described above are due to the fact that they are in
> parallel on two or four pairs of operands. So if a packed single-float
> add is done (addps) between xmm0 and xmm1, what you are really doing is
> taking four single-float value pairs in xmm0 and xmm1 and adding them at
> the same time. The SSE hardware is set up to do all four adds at once.
Many thanks for fixing this misunderstanding. I thought ADDPD added the
two double floats across an xmm register rather than the parallel addition
of two sets of two double floats. Impressive.
(snip)
>> I believe it is fair to classify modern AMD processors as more Lisp and
>> dynamic language friendly than Intel P4 processors. Pointers and linked
>> lists defy instruction prediction and Intel's large and growing pipelines
>> are only useful for selling processors (through higher clock speeds) and
>> performing well against the kind of finely tuned static code used in some
>> benchmarks.
>
> The x86-64 architecture definitely has a number of lisp-friendly features
> in it (but they're also more other-language-friendy, as well). For example,
> there is a new pc-relative addressing mode which helps immensely in
> table- based case statements and in building catch blocks. On the x86
> one must do a call/ret pair or else relocate absolute code in order to
> grab the current address in code vectors which might move. With the new
> "rip-relative" addressing, no calls need be made, which is also good for
> the branch prediction stack.
When examining the CMUCL reader-related source (derived from Spice Lisp) I
noticed vector lookups were used instead of case statements. While I
may write this function to check for a whitespace character...
(defun whitespacep (char)
(case char
((#\Space #\Newline #\Tab #\Linefeed #\Page #\Return) t)))
...another approach is to build a vector big enough to hold all character
codes (only 256 characters in CMUCL) and store the type of character in
the vector. One converts a character to its code number and uses it
as the index to the vector to find the character type (using a vector
also supports the dynamic updating of character attributes).
With this new hardware support for table-based case statements could my
function be as fast in Allegro CL as one that used explicit vector
lookup?
Regards,
Adam
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.
--
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.
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.
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.
Duane Rettig
> Many thanks for fixing this misunderstanding. I thought ADDPD added the
> two double floats across an xmm register rather than the parallel addition
> of two sets of two double floats. Impressive.
Yes. This is SIMD (single-instruction/multiple-data) architecture,
sometimes also called superscalar architecture.
> > The x86-64 architecture definitely has a number of lisp-friendly features
> > in it (but they're also more other-language-friendy, as well). For example,
> > there is a new pc-relative addressing mode which helps immensely in
> > table- based case statements and in building catch blocks. On the x86
> > one must do a call/ret pair or else relocate absolute code in order to
> > grab the current address in code vectors which might move. With the new
> > "rip-relative" addressing, no calls need be made, which is also good for
> > the branch prediction stack.
>
> When examining the CMUCL reader-related source (derived from Spice Lisp) I
> noticed vector lookups were used instead of case statements. While I
> may write this function to check for a whitespace character...
>
> (defun whitespacep (char)
> (case char
> ((#\Space #\Newline #\Tab #\Linefeed #\Page #\Return) t)))
>
> ...another approach is to build a vector big enough to hold all character
> codes (only 256 characters in CMUCL) and store the type of character in
> the vector. One converts a character to its code number and uses it
> as the index to the vector to find the character type (using a vector
> also supports the dynamic updating of character attributes).
This is a data-driven parallel to the choice between a cond statement
(or in C an if/else-if chain) and a case statement (in C: switch)
statement. One uses a chain of tests, and the other uses a vectorized
lookup.
> With this new hardware support for table-based case statements could my
> function be as fast in Allegro CL as one that used explicit vector
> lookup?
No; it would be faster than jump-table case statements on other hardware,
including x86, and it would be faster than the example of whitespacep
that you showed[1] but there is some setup required to make a jump-table
work correctly, and so each architecture has a cutoff point for N where
a case statement of N values is switched from a cond to table-based
because it crosses that efficiency threshold. On x86-64, that threshold
will be crossed with fewer values for the case statement. But such
setup is almost always larger than the setup required to access vector,
typically two instructions on RISC systems and one instruction on
x86 and x86-64.
We are starting to wander off the original topic, now; if you have
additional questions we should probably adjust the subject line...
[1] Note that a sufficiently smart compiler-macro for case could
turn the above case form into the following:
(case (char-code char)
((#.(char-code #\Space) #.(char-code #\Newline) #.(char-code #\Tab)
#.(char-code #\Linefeed) #.(char-code #\Page) #.(char-code #\Return))
t))
which would then be just comparing a bunch of integers, and that would
make it a possible candidate for a jump-table compilation (which would,
if there are enough values to make the cutover worthwhile, be faster
than checking against each value).
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.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
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.
Adam Warner
Thanks Duane. I understand the fundamental point that jump tables have a
setup cost that only becomes worthwhile when CASE contains a sufficient
number of tests. The AMD64 hardware support only makes it possible
to lower this threshold.
> [1] Note that a sufficiently smart compiler-macro for case could
> turn the above case form into the following:
>
> (case (char-code char)
> ((#.(char-code #\Space) #.(char-code #\Newline) #.(char-code #\Tab)
> #.(char-code #\Linefeed) #.(char-code #\Page) #.(char-code #\Return))
> t))
>
> which would then be just comparing a bunch of integers, and that would
> make it a possible candidate for a jump-table compilation (which would,
> if there are enough values to make the cutover worthwhile, be faster
> than checking against each value).
I suppose a sufficiently smart compiler macro could also build the
vectorised lookup, at least in this case where only a symbol needs to be
returned. Assuming the test key is a character:
(defmacro char-case (test &rest clauses)
"Provide with a long form case statement. There must be a single return value
and it must not require evaluation."
(let ((max-int 0))
(dolist (clause clauses)
(dolist (key (first clause))
(let ((code (char-code key)))
(when (> code max-int) (setf max-int code)))))
(let ((vector (make-array (1+ max-int)
:element-type t
:initial-element nil)))
(dolist (clause clauses)
(dolist (key (first clause))
(setf (aref vector (char-code key)) (second clause))))
(let ((code (gensym "CODE")))
`(let ((,code (char-code ,test)))
(when (<= ,code ,max-int)
(aref ,vector ,code)))))))
(macroexpand '(char-case char
((#\Space #\Newline #\Tab #\Linefeed #\Page #\Return) t)))
=>
(let ((#:code1625 (char-code char)))
(when (<= #:code1625 32)
(aref
#(nil nil nil nil nil nil nil nil nil t t nil t t nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil t)
#:code1625)))
It's rough but you get the idea.
Regards,
Adam
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)
Daniel Barlow
>>>>>> "TB" == Tim Bradshaw <t...@cley.com> writes:
>
> TB> ... Does anyone
> TB> offer realistic commercial support for OSS CLs (this isn't a
> TB> sarcastic question).
>
> Off the top of my head:
>
> http://web.metacircles.com/Support
Though in fairness, this is probably not what Tim had in mind by
"realistic": we've had this conversation before
http://groups.google.com/groups?selm=ey3llxgf5gn.fsf%40cley.com&oe=UTF-8
Horses, swings, roundabouts, courses, etc etc
-dan
--
http://web.metacircles.com/ - Open Source software development and support
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
Tim Bradshaw
> Though in fairness, this is probably not what Tim had in mind by
> "realistic": we've had this conversation before
I seem to be making the same point several times in this thread.
`Realistic' depends on context. I think that in the original context
of *this* thread, what metacircles can provide could well be realistic
but...
> http://groups.google.com/groups?selm=ey3llxgf5gn.fsf%40cley.com&oe=UTF-8
... in the context of *that* thread (or, for instance, of the systems
I've been looking at today which are the sort which have DR standby
systems...) it probably isn't. Unfortunately I do seem to spend a lot
of my time at present dealing with systems which must not go down,
which leads me to be a bit biased, but there are many other contexts.
--tim
John Atwood
>John Thingstad wrote:
>> 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.