Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Most Important Project Was a Bytecode Interpreter

gpfault.net

Post reply on HN
Print view View original

111–120 of 154 posts

Re: My Most Important Project Was a Bytecode Interpreter

#111

Post by nadam »

Rexxar wrote: post #102
Jasper_ wrote: post #21

Earlier quoted context omitted.

Tracks I've done and suggested to friends and colleagues as learning experiences: * Compression (lossless, lossy, image, audio, texture, video) * Languages (bytecode interpreter, AST interpreter, parser/lexer for a simple language, simple JIT, understanding instruction scheduling) * DSP programming (writing programs for fast, branchless math) * Comfort with binary and binary formats (start with packfiles .zip/.tar, m…

Concerning last point, do you know nice example of non-scanline-based 2D renderers ?

A very informative tutorial on high performance edge-function based rasterization:

https://fgiesen.wordpress.com/2013/02/17/optimizing-sw-occlu...

(articles 6, 7, 8, others are not closely related)

As far as I know modern hardware has been non-scanline-based for ages btw.

Re: My Most Important Project Was a Bytecode Interpreter

#112

Post by hvidgaard »

wyager wrote: post #65
hvidgaard wrote: post #59

Earlier quoted context omitted.

While it is true for Regular Languages (FSM) strict RegExs, it's hardly true for any contemporary implementation of RegExs. They have back references and other constructs that make them more powerful than a Regular Language, and thereby make it impossible to decide equivalence in the general case.

Hence "not to be confused with PCREs", which most pseudo-regex implementations are based off of.

Did you edit the comment? I cannot recall reading that at all, but I may have been in a hurry.

Re: My Most Important Project Was a Bytecode Interpreter

#113

Post by _RPM »

chii wrote: post #96
_RPM wrote: post #39

I saw the matrix after I first implemented a virtual machine. I recommend everyone does it because it will teach you a lot about how code is executed and transformed from the syntax to the actual assembly/bytecode. A stack based virtual machine is so simple it takes a lot of thinking to understand how they work. (or maybe I'm just not that smart). It's interesting that he implemented function calls via a jump. In my…

A CS education is incomplete without a semester on writing a simple compiler, and a corresponding emulator for the output for said compiler.

Sure. That's why I did it on my own.

Re: My Most Important Project Was a Bytecode Interpreter

#114

Post by 0xcde4c3db »

sillysaurus3 wrote: post #3

Also: a software rasterizer. Most people refuse to write one because it's so easy not to. Why bother? It will make you a better coder for the rest of your life. Let's make a list of "power projects" like this. A bytecode interpreter, a software rasterizer... What else?

A screen-oriented text editor with undo and search/replace. Can you make it handle a 10MB file without "simple" operations having annoying delays? How about 100MB? 1GB? 100GB? With no line breaks in the file?

Re: My Most Important Project Was a Bytecode Interpreter

#115

Post by signa11 »

Marazan wrote: post #109
signa11 wrote: post #61

Earlier quoted context omitted.

having written one as a slightly larger python thingy, i can fully attest to that. now that it is kind of done, i want to make it faster :) for example, having a home-grown vector_3d class kind of sucks (performance wise). it might be better to have vector_3d be actually based on, say, numpy.array ? once that is done, and i start seeing some real improvement, it might be possible to go the other route as well i.e. wr…

Simply replacing your own vector_3d class with numpy.array() won't actually speed you up that much as the overhead of creating all the tiny 3 element arrays kills you (I think I got only a 2x speed up from going from a pure python vector_3d to numpy arrays). Numpy is optimised for the creation of a small number of big arrays. The massive enormous speed ups come from creating massive arrays and implicitly working on t…

> The massive enormous speed ups come from creating massive arrays and implicitly working on them in parallel. So instead of iterating through every pixel and creating a origin and direction vector for each one you create a Total_number_of_pixels X 3 numpy array and pass that to your ray tracing function. Due to the way numpy broadcasts arrays the amount of rewriting you need to do is incredibly minimal and the speed ups over pure python are astronomical.

thank you for your insight! this is very useful indeed.

Re: My Most Important Project Was a Bytecode Interpreter

#116

Post by mynewtb »

0xcde4c3db wrote: post #114
sillysaurus3 wrote: post #3

Also: a software rasterizer. Most people refuse to write one because it's so easy not to. Why bother? It will make you a better coder for the rest of your life. Let's make a list of "power projects" like this. A bytecode interpreter, a software rasterizer... What else?

A screen-oriented text editor with undo and search/replace. Can you make it handle a 10MB file without "simple" operations having annoying delays? How about 100MB? 1GB? 100GB? With no line breaks in the file?

Is there any such editor?

Re: My Most Important Project Was a Bytecode Interpreter

#117

Post by zeveb »

kovrik wrote: post #7
sillysaurus3 wrote: post #3

Also: a software rasterizer. Most people refuse to write one because it's so easy not to. Why bother? It will make you a better coder for the rest of your life. Let's make a list of "power projects" like this. A bytecode interpreter, a software rasterizer... What else?

Your own Lisp-like language (or Scheme implementation). Really recommend it.

Seconded. One of my plethora of hobby projects has been an interpreter or compiler (it changes from month to month) for Common Lisp, for an esoteric platform. It's a huge amount of fun, and I have learnt so much about software from it.

Re: My Most Important Project Was a Bytecode Interpreter

#118

Post by zeveb »

chii wrote: post #96
_RPM wrote: post #39

I saw the matrix after I first implemented a virtual machine. I recommend everyone does it because it will teach you a lot about how code is executed and transformed from the syntax to the actual assembly/bytecode. A stack based virtual machine is so simple it takes a lot of thinking to understand how they work. (or maybe I'm just not that smart). It's interesting that he implemented function calls via a jump. In my…

A CS education is incomplete without a semester on writing a simple compiler, and a corresponding emulator for the output for said compiler.

I think I agree. I really wish that I'd been walked through The Right Way (or just A Right Way) to write a compiler and bytecode interpreter by a professor. Oh well, it's fun to learn on my own!

Re: My Most Important Project Was a Bytecode Interpreter

#119

Post by wyager »

halter73 wrote: post #68
wyager wrote: post #38

Earlier quoted context omitted.

I mean, the whole point of regexes (not to be confused with PCREs) is that any given regex is isomorphic to some canonical finite state machine. It is, specifically speaking, a tiny description of an FSM over the alphabet of ASCII characters (or whatever charset you're using). Interestingly, regexes/FSMs are (IIRC) the most powerful class of machines for which equivalence is decidable. So if you give me any two regex…

Isn't it possible to decide the equivalence of deterministic pushdown automata? Wouldn't DPDAs be considered more powerful than FSMs due to the addition of a stack? Wikipedia [1] shows there's a paper called "The equivalence problem for deterministic pushdown automata is decidable" that won the Gödel Prize is 2002. I haven't read the paper nor do I currently have access to it though. [1] https://en.wikipedia.org/wiki…

Huh! Well there you go.

Re: My Most Important Project Was a Bytecode Interpreter

#120

Post by douche »

This reminds me a little bit of my computer architecture class. We started at logic gates in a simulator[1], and worked our way up from there to flip-flops and adders, memory chips, a simple ALU, and eventually a whole 8-bit CPU in the simulator. I want to think that we were even writing assembly for it, loading the programs into the simulated memory, and executing it. It was a great way to get a sense of how everything works, and I think it's when C-style pointers really clicked for me.

[1] this one, IIRC https://sourceforge.net/projects/circuit/

Post reply on HN