Flash rewrite lifetime is mostly non-issue nowadays. With wear levelling (and taking into account the not-that-great writing speed of flash), I'm pretty sure other components will fail before the flash.
It runs on movitz (image available for download, if you want to run it yourself). I guess it'd be easier to extend LiCE than to port FSF Emacs to a non-C-based OS. Or porting McCLIM to work on movitz(+ framebuffer), which, in addition to enabling movitz to run Climacs, would also open up other programs.
*cough* 6502 *cough* (the 6502's the one with page 0 and all)
Interestingly enough, it might very well lower performance, rather than improve it, since that makes much, much more state to save during thread switches. It would also just about kill any chance of older programs (even for the same arch) running as well as new ones on each new iteration.
Isn't that another Goto? (of hash-consing fame, which makes deep-equality on functional lists O(1) and often significantly reduces memory consumption by discovering duplicates at runtime)
Well, I guess I could name my first-born Foobar Gosub and s/he should be a good computer scientist;)
That's not what they're doing. They're representing a player's skill by a tuple of an average and standard dev. I.E., it can make the difference between a player who has a lot of ups and downs, versus a consistent player, even though they have the same "average skill."
Really? Weird. Doesn't look French to me, a native speaker.
Dict.org says:
Egress \E"gress\, n. [L. egressus, fr. egredi to go out; e out +
gradi to go. See Grade.]
1. The act of going out or leaving, or the power to leave;
departure.
[1913 Webster]
Fully English, although the word does have a latin origin.
Scratch the stack part if you want. If the whole store is marked unexecutable by default, both methods will die if the CLR doesn't/can't mark the relevant pages as executable. Also, keep in mind that W^X emulation isn't available in vanilla Windows XP SP2, so if a third-party program somehow messes with the heap and stack to mitigate the effect of buffer overflows in the absence of NX, we can't really expect the CLR team to interface with that program to mark the relevant pages as executable (unless that program can hijack the relevant system calls), if it's even possible.
Cheney on the MTA by Henry Baker. Look it up. Basically, when you want tail-call optimisation (as in no stack depth limit, but not necessarily O(1) speed), but still want to use C, that's one of the best solution.
One solution (used in RABBIT, or a derivative, I believe), is to output everything in a big switch, and have each function call target be a case in it. (What about returns, you ask? You just CPS (transform into continuation passing style) the code first, so that every return becomes a call to the rest of the continuation) Of course, that means you can't really use automatic variables for anything, and have to create your own argument passing conventions and hope the compiler gets it right. Additionally, the huge size of the switch statement for non-trivial code means most compilers will choke on the output at high optimisation levels. (There are partial fixes, like breaking up the switch, but no real solution)
Another is to use a trampoline, where, again you CPS the code, and then, instead of calling functions, each function return a pointer to their continuation. The trampoline then call the continuation. Thus, each function call entails the cost of both a call and a return. To alleviate this problem, it is doable to only longjmp back to the trampoline when the stack is about to be exhausted, which I believe is what SML/NJ uses.
Cheney on the MTA is similar to a trampoline+longjmp, except that it also allocates objects on the stack, treating it like a nursery in a generational GC. When the stack is about to be exhausted, you GC with copying GC scheme the stack first (treating it like any other part of the store, just by following the root pointers), and then longjmp back to the trampoline. This is where it gets the Cheney on the MTA name: Cheney is a copying GC scheme, and [Someone?] on the MTA is a song about some dude who never returns from the MTA, while our code never returns. So, we get tail-call "optimisation", and can save one pointer compared to the two other method, which must have a pointer to the allocation space, while Cheney on the MTA overloads the stack pointer with that task (it must still keep a pointer to the older generation(s), but that's fine, since it's not used that often and can thus be a global in memory, and isn't an extra cost compared to other generational GCs). Chicken Scheme uses that to compile (nearly?) full (with GMP for the numerical tower) R5RS Scheme to C. As to why this won't break on machines with register windows: whenever we take the address of something, that something _must_ be in memory, and stay there [observably]. I'm sure someone can quote the part of the C standard that says so.
Note that VMs usually take code that is already CPSed (in that there is no implicit return, since they manage their own return stack), so converting a VM to Cheney on the MTA wouldn't be hard.
As to how I would distinguish between already compiled functions and those that must be interpreted/compiled: add one layer of indirection (we agree for that), but not where you put it. Instead, each function "call" says to call the function at location x (which I'll call function cell). At x, we find a pointer to either IL or machine code (we could make the difference with tags, an additional word or simply by having different address ranges for IL and machine code. Using that, we can dispatch to either the compiler/interpreter or jump directly to the target. If we inline the dispatch, branch prediction should make it nearly free (we only compile a function once, and, once it's compiled, we usually keep that version for the rest of the program's lifetime, so the jump target doesn't change either). We just have to make the function cells part of the root set so that they can be moved whenever there's a GC (they'll simply be copied out of the nursery, and the pointers to them updated).
So, no, it wouldn't be that surprising, and it would actually be a defendable choice, with regards to both performance and elegance.
John's a corewar god (all that 6502 assembly probably has something to do with that;), so nPaper is nearly all his: the constant twiddling (by hand!), the QS, etc. All I did was basically write the framework for the paper; the only non-standard parts were the attack engine and the djn at the end of the timescape component... and I believe the djn was removed, because, even though it was more aggressive, it was effective than a checksum with a jmz. Read CoreWarrior #.. erh. I think it was it the high 70s or low 80s. John describes the process of optimising a newbie's paper (nPaper), all by hand (He might have used some BASIC scripting:).
Even now that we have evolvers throwing tons of computing power at a relatively small search space (nano), John submitted something that rocketted to 1st place and manages more than 50% wins. Again, the dude is a corewar genius.
The CLR does JIT (or, at least, runtime) compilation. A common way to do so is to output the machine code on the stack. W^X usually breaks programs that do runtime code generation. Now, this is a WAG, but that's where my money's at.
Seriously, while it is possible to do optical switching, methods either are inefficient or need hugely powerful light sources. There is some research to alleviate the problem _in Si_, but it's still only research, years away from practical use. As it is, I think that using optics only for interconnects is an already doable way of improving performance, and not just within the chip. Content associative memories (which can be built with SLMs, passive optics and cameras) can greatly help tasks like DB querying, but (I suppose), could also be used to improve communications between a large number of not-so-loosely-interconnected-anymore processors (something similar to Linda tuplespace in hardware).
I'm a dental students. RSI and other such problems are an important concern for us, since we/will/ often work 6-10h/day (unlike gaming), and our profs are very careful to teach us good, ergonomic, techniques. We are consistently told to work with our wrist and forearms, and not our fingers. The revolution's controller seems much better suited to avoiding movements of the fingers than traditional controllers (oh, the pain of the analog stick) can ever hope to be.
OT: my captcha is functor. How many other websites could use such a word in their words bank?;)
The same happened with hockey a couple years ago. (I can't remember if it was SRC, CBC or both that were commentary-less). Of course, the best part about this is that at least one radio station (CHOI, the one that almost got shut down) would have its own play by play, by completely random people.
To define an alias, it's better to substitute a functions with functions and macros with macros. Losing the ability to funcall is a major loss. Just (declaim (inline foo)) if you're worried about performance. That wouldn't be needed in most implementation, though, since the function is so small it's almost certain to be inlined.
No, a processor with more independant vector processing units. Maybe not genius revolutionary, but different enough that nobody seems to know for sure how to best approach programming the PS3. (Don't go and play word games going all s/revolutionary/mind-blowingly-better/ with me)
Yes, itanium has a very large (and thus much slower than L2) L3 cache. Opterons, on the other hand, are (*iirc, i haven't googled it or anything, lector emptor or wqhateer*) closer to main memory... It could go either way, depending on how random the memory accesses really are. Also, SSE2 (maybe 3?) adds basic caching hints to the ISA, so if a program were to take advantage of those on itanium, it could use the same data on opterons.
Oh, btw, why intel will never pit Itanium VS Opteron: even if Itanium wins, cheap opterons are cheaper than cheap itaniums, and top-of-the-line opterons are cheaper than top-of-the-line itaniums. Worst, it'd only highlight the myth-itude of the MHz myth, or that P4s do little with their high clockrate. Until their next generation low-power 64bit line is out, I don't think they want to risk that.
Moreover, this is Lisp we're talking about. If you want your own syntax, just start defining your own package. There's no visible difference between user-defined functions/macros and standard ones.
Good point. Still, "putting large amounts of data in a queue" might not happen that often: the (lightweight, not necessarily system, so we can mostly ignore the cost of context switches) threading can be scheduled to help ensure that the queues are emptied af quickly as possible. We can also queue references to large chunks of data instead of the data itself. Of course that may require a more functional way of doing things, in addition to a more complex GC. Fortunately, concurrent or realtime (not sure about both at the same time) GC algorithms have been studied and extensive descriptions can be found in freely available litterature.
To return to the topic of threading, I think that most of us have a view of threading that is tainted by the way threads/processes are implemented in most OSes we use. Erlang threads, for example, scale much better than native threads, because they do less *but still enough*. This is games we're talking about here; I don't remember ever hearing of game dev who was afraid of shooting himself in the foot;)
Re latency, I'm not quite sure... Would an environment running at 30 fps with the graphics at 60 fps be really worse than both the environment and the graphics at 30 fps?
"All of these threads, however, may need to interact with each other. When objects collide, you get a callback and that callback may trigger rendering, AI, sound, etc. AI needs to use physics data for line-of-sight checks and so on."
Communication between agents isn't exactly a new problem. Queues (bounded or unbounded) could be used to implement asynchronous message passing. IIRC, bounded queues dont even need atomic operations.
Yeah, i guess you're right. There shall be no sh on my servers! The so-called vulnerability is only the consequence of the fact that *gasp*, when you execute a shell script, the script can modify files(!, etc etc).
Slashdot Mirror
The solution to that problem is simply more introspection. See http://common-lisp.net/project/slime/ for an example.
;)
BTW, emacs all the way
Flash rewrite lifetime is mostly non-issue nowadays. With wear levelling (and taking into account the not-that-great writing speed of flash), I'm pretty sure other components will fail before the flash.
It already exists (sort of): http://www.emmett.ca/~sabetts/
"LiCE is the GNU Emacs clone I'm building."
It runs on movitz (image available for download, if you want to run it yourself). I guess it'd be easier to extend LiCE than to port FSF Emacs to a non-C-based OS. Or porting McCLIM to work on movitz(+ framebuffer), which, in addition to enabling movitz to run Climacs, would also open up other programs.
*cough* 6502 *cough* (the 6502's the one with page 0 and all)
Interestingly enough, it might very well lower performance, rather than improve it, since that makes much, much more state to save during thread switches. It would also just about kill any chance of older programs (even for the same arch) running as well as new ones on each new iteration.
Isn't that another Goto? (of hash-consing fame, which makes deep-equality on functional lists O(1) and often significantly reduces memory consumption by discovering duplicates at runtime)
;)
Well, I guess I could name my first-born Foobar Gosub and s/he should be a good computer scientist
If you're gonna pick nits, criticize writing, etc., at least get your accents right when you try and look cultured by using them.
That's not what they're doing. They're representing a player's skill by a tuple of an average and standard dev. I.E., it can make the difference between a player who has a lot of ups and downs, versus a consistent player, even though they have the same "average skill."
Ah, what wouldn't one do for an FP...
Really? Weird. Doesn't look French to me, a native speaker.
Dict.org says:
Egress \E"gress\, n. [L. egressus, fr. egredi to go out; e out +
gradi to go. See Grade.]
1. The act of going out or leaving, or the power to leave;
departure.
[1913 Webster]
Fully English, although the word does have a latin origin.
Scratch the stack part if you want. If the whole store is marked unexecutable by default, both methods will die if the CLR doesn't/can't mark the relevant pages as executable. Also, keep in mind that W^X emulation isn't available in vanilla Windows XP SP2, so if a third-party program somehow messes with the heap and stack to mitigate the effect of buffer overflows in the absence of NX, we can't really expect the CLR team to interface with that program to mark the relevant pages as executable (unless that program can hijack the relevant system calls), if it's even possible.
Cheney on the MTA by Henry Baker. Look it up. Basically, when you want tail-call optimisation (as in no stack depth limit, but not necessarily O(1) speed), but still want to use C, that's one of the best solution.
One solution (used in RABBIT, or a derivative, I believe), is to output everything in a big switch, and have each function call target be a case in it. (What about returns, you ask? You just CPS (transform into continuation passing style) the code first, so that every return becomes a call to the rest of the continuation) Of course, that means you can't really use automatic variables for anything, and have to create your own argument passing conventions and hope the compiler gets it right. Additionally, the huge size of the switch statement for non-trivial code means most compilers will choke on the output at high optimisation levels. (There are partial fixes, like breaking up the switch, but no real solution)
Another is to use a trampoline, where, again you CPS the code, and then, instead of calling functions, each function return a pointer to their continuation. The trampoline then call the continuation. Thus, each function call entails the cost of both a call and a return. To alleviate this problem, it is doable to only longjmp back to the trampoline when the stack is about to be exhausted, which I believe is what SML/NJ uses.
Cheney on the MTA is similar to a trampoline+longjmp, except that it also allocates objects on the stack, treating it like a nursery in a generational GC. When the stack is about to be exhausted, you GC with copying GC scheme the stack first (treating it like any other part of the store, just by following the root pointers), and then longjmp back to the trampoline. This is where it gets the Cheney on the MTA name: Cheney is a copying GC scheme, and [Someone?] on the MTA is a song about some dude who never returns from the MTA, while our code never returns. So, we get tail-call "optimisation", and can save one pointer compared to the two other method, which must have a pointer to the allocation space, while Cheney on the MTA overloads the stack pointer with that task (it must still keep a pointer to the older generation(s), but that's fine, since it's not used that often and can thus be a global in memory, and isn't an extra cost compared to other generational GCs). Chicken Scheme uses that to compile (nearly?) full (with GMP for the numerical tower) R5RS Scheme to C. As to why this won't break on machines with register windows: whenever we take the address of something, that something _must_ be in memory, and stay there [observably]. I'm sure someone can quote the part of the C standard that says so.
Note that VMs usually take code that is already CPSed (in that there is no implicit return, since they manage their own return stack), so converting a VM to Cheney on the MTA wouldn't be hard.
As to how I would distinguish between already compiled functions and those that must be interpreted/compiled: add one layer of indirection (we agree for that), but not where you put it. Instead, each function "call" says to call the function at location x (which I'll call function cell). At x, we find a pointer to either IL or machine code (we could make the difference with tags, an additional word or simply by having different address ranges for IL and machine code. Using that, we can dispatch to either the compiler/interpreter or jump directly to the target. If we inline the dispatch, branch prediction should make it nearly free (we only compile a function once, and, once it's compiled, we usually keep that version for the rest of the program's lifetime, so the jump target doesn't change either). We just have to make the function cells part of the root set so that they can be moved whenever there's a GC (they'll simply be copied out of the nursery, and the pointers to them updated).
So, no, it wouldn't be that surprising, and it would actually be a defendable choice, with regards to both performance and elegance.
John's a corewar god (all that 6502 assembly probably has something to do with that ;), so nPaper is nearly all his: the constant twiddling (by hand!), the QS, etc. All I did was basically write the framework for the paper; the only non-standard parts were the attack engine and the djn at the end of the timescape component... and I believe the djn was removed, because, even though it was more aggressive, it was effective than a checksum with a jmz. Read CoreWarrior #.. erh. I think it was it the high 70s or low 80s. John describes the process of optimising a newbie's paper (nPaper), all by hand (He might have used some BASIC scripting :).
Even now that we have evolvers throwing tons of computing power at a relatively small search space (nano), John submitted something that rocketted to 1st place and manages more than 50% wins. Again, the dude is a corewar genius.
Paul(-Virak) Khuong
PS, note the position of the dash
The CLR does JIT (or, at least, runtime) compilation. A common way to do so is to output the machine code on the stack. W^X usually breaks programs that do runtime code generation. Now, this is a WAG, but that's where my money's at.
One word: how?
Seriously, while it is possible to do optical switching, methods either are inefficient or need hugely powerful light sources. There is some research to alleviate the problem _in Si_, but it's still only research, years away from practical use. As it is, I think that using optics only for interconnects is an already doable way of improving performance, and not just within the chip. Content associative memories (which can be built with SLMs, passive optics and cameras) can greatly help tasks like DB querying, but (I suppose), could also be used to improve communications between a large number of not-so-loosely-interconnected-anymore processors (something similar to Linda tuplespace in hardware).
I'm a dental students. RSI and other such problems are an important concern for us, since we /will/ often work 6-10h/day (unlike gaming), and our profs are very careful to teach us good, ergonomic, techniques. We are consistently told to work with our wrist and forearms, and not our fingers. The revolution's controller seems much better suited to avoiding movements of the fingers than traditional controllers (oh, the pain of the analog stick) can ever hope to be.
;)
OT: my captcha is functor. How many other websites could use such a word in their words bank?
Stargate, not MacGyver, I believe.
The same happened with hockey a couple years ago. (I can't remember if it was SRC, CBC or both that were commentary-less). Of course, the best part about this is that at least one radio station (CHOI, the one that almost got shut down) would have its own play by play, by completely random people.
That creates artefacts, though. You can't pull information out of thin air.
To define an alias, it's better to substitute a functions with functions and macros with macros. Losing the ability to funcall is a major loss. Just (declaim (inline foo)) if you're worried about performance. That wouldn't be needed in most implementation, though, since the function is so small it's almost certain to be inlined.
No, a processor with more independant vector processing units. Maybe not genius revolutionary, but different enough that nobody seems to know for sure how to best approach programming the PS3. (Don't go and play word games going all s/revolutionary/mind-blowingly-better/ with me)
Yes, itanium has a very large (and thus much slower than L2) L3 cache. Opterons, on the other hand, are (*iirc, i haven't googled it or anything, lector emptor or wqhateer*) closer to main memory... It could go either way, depending on how random the memory accesses really are. Also, SSE2 (maybe 3?) adds basic caching hints to the ISA, so if a program were to take advantage of those on itanium, it could use the same data on opterons.
Oh, btw, why intel will never pit Itanium VS Opteron: even if Itanium wins, cheap opterons are cheaper than cheap itaniums, and top-of-the-line opterons are cheaper than top-of-the-line itaniums. Worst, it'd only highlight the myth-itude of the MHz myth, or that P4s do little with their high clockrate. Until their next generation low-power 64bit line is out, I don't think they want to risk that.
This is CL we're talking about here. Kitchensink, etc, etc, remember?
P /HyperSpec/Body/acc_firstcm_s_inthcm_tenth.html
P /HyperSpec/Body/acc_rest.html
first: http://www.ai.mit.edu/projects/iiip/doc/CommonLIS
rest:
http://www.ai.mit.edu/projects/iiip/doc/CommonLIS
Moreover, this is Lisp we're talking about. If you want your own syntax, just start defining your own package. There's no visible difference between user-defined functions/macros and standard ones.
Good point. Still, "putting large amounts of data in a queue" might not happen that often: the (lightweight, not necessarily system, so we can mostly ignore the cost of context switches) threading can be scheduled to help ensure that the queues are emptied af quickly as possible. We can also queue references to large chunks of data instead of the data itself. Of course that may require a more functional way of doing things, in addition to a more complex GC. Fortunately, concurrent or realtime (not sure about both at the same time) GC algorithms have been studied and extensive descriptions can be found in freely available litterature.
;)
To return to the topic of threading, I think that most of us have a view of threading that is tainted by the way threads/processes are implemented in most OSes we use. Erlang threads, for example, scale much better than native threads, because they do less *but still enough*. This is games we're talking about here; I don't remember ever hearing of game dev who was afraid of shooting himself in the foot
Re latency, I'm not quite sure... Would an environment running at 30 fps with the graphics at 60 fps be really worse than both the environment and the graphics at 30 fps?
"All of these threads, however, may need to interact with each other. When objects collide, you get a callback and that callback may trigger rendering, AI, sound, etc. AI needs to use physics data for line-of-sight checks and so on."
Communication between agents isn't exactly a new problem. Queues (bounded or unbounded) could be used to implement asynchronous message passing. IIRC, bounded queues dont even need atomic operations.
Yeah, i guess you're right. There shall be no sh on my servers! The so-called vulnerability is only the consequence of the fact that *gasp*, when you execute a shell script, the script can modify files(!, etc etc).
Or maybe he was just afraid of Catholic executioners.