View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000232 | LDMud | Implementation | public | 2004-11-26 23:38 | 2022-10-06 23:47 |
| Reporter | Assigned To | Gnomi | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | won't fix | ||
| Summary | 0000232: Bytecode Design | ||||
| Description | Short: Revamp the bytecode design From: Lars Date: 20000906 Type: New State: Feature Redesign the bytecode so that it uses 16- or 32-Bit Words: masking and shifting on modern processors should be faster than memory accesses. Note: on x86 using 16-Bit words in 32-Bit code might be slow. Investigate changing the stackmachine into a registermachine, e.g. instead of load var1 load var2 add store var3 the bytecode would be add var1, var2, var3 The compiler might be complexer, but it could speed up the machine. Also, think about storing the addresses of the instruction routines directly in the 'bytecode'. | ||||
| Tags | No tags attached. | ||||
| External Data (URL) | |||||
| related to | 0000661 | confirmed | LDMud 3.6 | Bytecode cleanup |
|
|
I discussed this with Gnomi today very shortly. He made a very good point: he does not like optimizations which make the code more difficult to read and this sounds like such. I agree. This should only be considered if it speeds up the interpreter by a lot in usual applications. Von Gnomi@UNItopia: Aber ist nicht gerade der CPU Cache genau dazu Von Gnomi@UNItopia: da, um solche kontinuierlichen Abfragen aus dem Von Gnomi@UNItopia: Speicher zu optimieren? Von Gnomi@UNItopia: Ich mag jedenfalls keine Optimierungen, die den Von Gnomi@UNItopia: Code unuebersichtlicher machen, und das klingt Von Gnomi@UNItopia: nach so einem. (Ich find ja schon die Von Gnomi@UNItopia: Optimierung mit dem inter_sp/pc/fp schrecklich.) Concerning the change to a registermachine: this does not seem to be anything we can do in the near future. I don't see that for 3.5.x. If we do this, is is a good opportunity to use LLVM to re-create the LPC compiler from scratch. Then we can even build an optimizing compiler. It promises a lot, but needs a lot of work concerning the compiler. I would suggest to think about this for 3.7. |
|
|
Well, would this even be necessary? Has anyone got real problems with ldmud interpretation speed? Even with hardware from 2004, I doubt it. Sincerely, if there are performance issues with ldmud, Avalon only has had these with IO/memory like restoring huge mappings, garbage collection, etc. But you already know this. I would suggest you poll for feedback if there is even widespread interest in such an untertaking. |
|
|
I personally don't think it is worth the effort doing just this, we usually also don't have speed issues. Gnomi and me discussed some more. ;-) The basic idea here is to redesign the bytecode so that every instruction+payload fits into a 32 bit package and all instructions are then 32 bit long. But we both agree, that such a fundamental redesign of the bytecode, interpreter and compiler should include a switch to open source VMs like LLVM (or parrot, or ...). That would be beneficial in several ways and will probably pay off in the loong run. Though it is quite a lot of work and we will not do something like that in 3.5. Gnomi commented: when we do it, it will merit to increase to 4.0. ;-) |
|
|
Closing this with reference to the previous comments. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-11-26 23:38 |
|
New Issue | |
| 2009-09-27 03:33 | zesstra | Relationship added | related to 0000661 |
| 2009-11-10 18:07 | zesstra | Note Added: 0001620 | |
| 2009-11-20 06:16 | _xtian_ | Note Added: 0001636 | |
| 2009-11-20 07:22 | zesstra | Note Added: 0001638 | |
| 2022-10-06 23:47 | Gnomi | Assigned To | => Gnomi |
| 2022-10-06 23:47 | Gnomi | Status | new => closed |
| 2022-10-06 23:47 | Gnomi | Resolution | open => won't fix |
| 2022-10-06 23:47 | Gnomi | Note Added: 0002708 |
