|
Socoder -> Concept/Design -> Multithreaded Interpreter |
|
| Tue, 15 Dec 2009, 20:17 | |
|
mindstorm8191 |
Hello. I'm currently working on a programming language I call Graphite. This will be a very unique language, where the primary language feature will be to allow you to modify code - while its running. I don't know how well this feature will work, but I know there's very few languages that allow you to change code while its running. One of the other features I wanted to have in the language is to have it multithreaded. Being an interpreted language, having it also multithreaded will be quite difficult. I mean, with general interpreters complex tasks (like calling functions for a math expression) can be done with functions, each calling others where needed. But with threading, you have to stop at some point and start working on other problems. With me doing this in Blitz, making such adjustments isn't so easy. Has anyone here ever ventured down this path? It is certainly a difficult niche, but could turn out fun to make. This is actually a fairly old project now, I've had it since way back in 2005. At one time I had a rather complex structure to manage all the operational tasks, which unique structures to manage function calls, class objects, the works. But it never worked - my plans never ultimately solved any problems. I'm currently working on a new system that still uses the same principal of objects for managing work, but with less pre-defined structure and more emphasis on getting things done. Let me know if anyone is interested - perhaps I could get someone involved on working on this. -=-=- Vesuvius web game 
|
| Wed, 16 Dec 2009, 00:29 | |
JL235
|
I have an interest in programming languages, and recently an interest in highly concurrent languages. So I'd definitely be interested in seeing more of this. But I have three questions, first most interpreted languages allow you to modify code on the fly. This is not a niche idea. This is because most support an 'eval' statement (or similar) which takes a string which is then parsed on run (for example PHP and Ruby). Your app can just generate new code as strings, passing it in. Several other languages have support to allow you to call their compiler whilst running and to load new versions of existing code at run-time. For example both Java and Erlang allow you to do this. How is yours different? Second, are you making this in Blitz Basic? Because it has no in-built support for threads. So are you adding that support (i.e. through a .dll) or is it only going to ever use 1 OS thread? Third, how are you going to allow the developer to safely share state between threads/processes in the app? Are you going to support locks, channels, message passing, transactional memory or something else? Finally, in answer to your question about how to do thread switching; you can just use a round-robin approach for working out when to switch. Compile the program down into it's intermediate state (i.e. bytecode or a syntax tree) and then give each operation a cost value (i.e. add is 1, subtract is 1, division is 3, a function call is 5, reading a variable is 5, writing to a variable is 5, and so on). When each thread is allowed to run you have a maximum cost value that they can get up to (i.e. 100). So for example a thread could execute 100 adds, 20 functions calls or a mix of both. When they reach their cost limit you move the currently running thread to the back of your runnable thread queue and then start running the next thread at the front of the runnable queue. This is exactly what Erlang does, which can support running literally millions of processes. For working out the cost values you should write some test apps that benchmark each indevidual operation in turn. If one operation is 5 times more expensive then another, then it should take 5 times the amount of time to execute. |
| Wed, 16 Dec 2009, 08:35 | |
shroom_monk
|
JL235  first most interpreted languages allow you to modify code on the fly. This is not a niche idea. I think what he means is the ability to edit the code in the editor while it's running, rather than building it into code as with a PHP eval statement. At least, I think that's what he means... although that's an idea worth exploring, I can see it leading to problems with putting bad code into the program, causing it to get very confused. But it's still worth a shot. -=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom! |
| Wed, 16 Dec 2009, 09:11 | |
|
JL235
|
shroom_monk I think what he means is the ability to edit the code in the editor while it's runningBecause of the eval statement, lots of interpreted languages have an interactive terminal allowing you to type code as it's run. Here is one for Ruby which runs in the browser. Lots of languages have this. If your talking about being able to properly edit the code in a proper editor, as I said above languages like Erlang and Java allow you to reload libraries already whilst they are running. I'm just saying it's not unique, that's all. I'm not trying to rain down on this idea, it's an excellent feature to include and those languages that already allow you to do all this evalling and reloading of code allow it because people want it. |
| Wed, 16 Dec 2009, 16:57 | |
|
mindstorm8191 |
Well, my current plan involves allowing the code to be modified on the program-front. For example, you write code to modify a specific function. This could, perhaps, be converted into an on-the-fly editor, but that can be done by the coder. To answer your second question, I won't be using any dll's to manage multi-threading, so I'll have to manage all the multithreading by code. The reason for this is mainly because I don't know of any dll's to use, and don't know how flexible it is on doing different things, or how I would have to change the general design I have going. To answer your third question, I haven't exactly worked ou the details of how task switching will work. But as I see it now, I will probably change tasks for every 'task' object that the interpreter creates, destroys, or modifies. Each of these task objects will manage a different goal. Consider a complicated line like r = track(x*7, y/(10+h), map[r,q], soldier->thought(t))-10, where track is a user-defined function, and solder->thought() is a class function call. Before you can even call the track function, you have to solve the parameters, including the map array and calling the soldier->thought() function. But my intention is to use unique task objects to handle each of these tasks, creating a work stack for each thread that can step into and out of complicated work like this. A statement like this may take a long time to complete! But your idea of putting weights on each low-level commands sounds reasonable... though I don't know how it will relate to a system like this. My plans did include thread priorities; each thread would have a counter variable incremented by different amounts depending on their priority. JL, my internet connection is quite limited ATM, but maybe once I'm settled in from moving we can get in better touch. -=-=- Vesuvius web game
|
| Wed, 16 Dec 2009, 17:18 | |
|
JL235
|
mindstorm8191 Performing threading at the application level in software is known as green threads. They are typically a lot lighted and faster at certain operations then real threads, however they don't take advantage of multiple processors. You need to use real hardware threads in order to do that.To answer your second question, I won't be using any dll's to manage multi-threading, so I'll have to manage all the multithreading by code. The reason for this is mainly because I don't know of any dll's to use, and don't know how flexible it is on doing different things, or how I would have to change the general design I have going.Erlang (a language well known for it's concurrency) essentially uses green threads (although they are known as processes). To make your app parrallelised and take advantage of all of your CPU cores it will start up a bunch of hardware threads in the background and then run batches of it's green threads in each. This allows it to have the best of both worlds. A solution that didn't use green threads would be if when I started a thread in your language it would directly startup a real thread in the background that it mapped directly too. Only that one thread will be run in the OS thread. My overall point is that unless you are going to be using threads provided by the OS, then it's not going to take advantage of all of the computers CPUs. That kinda defeats the point of building a highly concurrent language if it's not going to ever be parrallelised. |
| Wed, 16 Dec 2009, 21:10 | |
|
mindstorm8191 |
Well, personally I'm not worried about true performance. But, I could possibly keep track of how much work each thread does (as a way for coders to see how much time each thread uses). Anyway, I see this as an experimental language, to test the ideas of on-the-fly code modification (by way of code-driven edits), so actual performance isn't the first consideration to this - though I'm starting to think that it may become very important, as others may choose to use Graphite in other ways. In the future, I may need to look into using hardware threads the way Erlang does. -=-=- Vesuvius web game
|
| Thu, 17 Dec 2009, 11:34 | |
|
Paul |
Hi! i worked on such a project this summer, found it very interesting. I'm far from finished but i'll upload a working preview. The first part I made was the Virtual machine so that part is almost completly done. Then i started on the compiler which i found a lot harder. As of now it doesn't support untangling statements, aka : "a=1+2*3" and all functions are called like function param1,param2,param3 where a parameter can be either in or out. the only implemented loop is the foorloop, and constants are not properly supported. Just gotta warn you that I haven't edited the code for sharing so it's probably a mess. Still, I hope it might help you to have a look and i must say that this is one of my most fun projects so far  Edit: link www.megaupload.com/?d=JYX515OS Edit2: just ask here if you have any questions about how anything works
|
|
|
| |||
|
| ||||