One idea for GPU would be to implement a CAS frontend (Computer Algebra System like Maple, Matlab or Mathematica, see also http://en.wikipedia.org/wiki/Computer_algebra_system ). The frontend would parse complex expressions including integration and differentation, complex matrix problmes etc., translate it into some kind of postfix notation e.g. with Shunting Yard (?). The postfix notation could be GPU stack language that would be eventually distributed to nodes.
The CAS language would be then partially executed in a distributed manner (if possible), and this is why we would name the frontend CAScade...
Last edit: dangermouse 2012-09-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think what needs to be done first is to create clear API protocol for GPU. Like bittorrent. Another thing is, Sqlite has stupid way of locking. I don't like it personally and can go into details why.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hi Alex, in fact in the unfinished code in gpu_freedom i experienced problems with sqlite and locking... i remember that there were different versions of the sqlite dll, but i thought i would have downloaded the right one. if you want to give some detail of the sqlite locking problems i would be very interested...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
when one process locks DB, inserts or updates are not waiting for lock to release, but just fail. I used mutexes to wait for DB locks. What gpu_freedom can do now?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
anyway let's discuss server side, it can be split into 3 parts: connectivity, task scheduling, task execution.
What are the ideas for connectivity? I want to have Linux server along with Windows one.
We will keep push model?
Task execution: a more clean plug-in design model?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The idea of gpu_freedom is a hybrid model with servers in PHP/mySQL and clients in Freepascal.
Freepascal now is very mature and stable, we could have Windows and x86-Linux clients as well. For connectivity i would now prefer pure HTTP or HTTPS (in gpu_freedom there are libraries which can do both fairly well, i tested them on hacker.org) because they work through firewalls and proxies, especially behind corporate proxies.
In gpu_freedom there is a PUSH on server/PULL on clients model.
Task execution: we could use the mparith library for big number support. The plugin design is a bit complicated because modules can be dynamically loaded... But in principle there is only one signature method which contains the stack definition... This for the low level part...
Part of the task execution is the language to express tasks (in GPU there is this GPU stack language, which is kind of postfix notation). There were also experiments to include some other scripting language... Python would be cool. Or some kind of CAS language like in Maple or Maxima (the free Maple)...
I realise here i am working from bottom-up, i assume you'd prefer a top-down approach. But maybe discussing we can meet in the middle...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've seen so many bad projects, so I want code quality to be of certain level here.
Therefore I will keep asking questions to refine the ideas.
The stack was funny but due to string memory being overwritten in DLL there was unrepairable memory deallocation problems.
Now sqlite is great thing but multithreading access to DB sucks. I used wrapping methods that access (and lock) db with mutexes, but windows mutexes are not available in linux, so in order for code to be generic I had to use boost. But then another problem arises: boost mutex remains set even if you kill application, and you have to unset it via application or reboot PC.
Firefox for example uses many sqlite DB files, in this way they try to minimize locking problems by having DB for each process.
And lately I am C/C++/C# guy, not much in Delphi/Pascal, sorry to say.
so my next question: what does server and what does client? Cheers, Alex
Last edit: Alex Fihman 2012-10-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ok Alex, excluse the late reply, i did not notice you replied.
Thinking at what was done in the GPU freedom codebase, and to save some parts of it:
what about of such an approach:
- use PHP/mySQL server just to relay messages between rich flat clients. Messages would be sent via HTTPS (they can bypass most proxies at companies). people setting up such servers would have some cool graphs to stare at (with the OpenFlashChart component).
Messages would be of two types: broadcast and to single nodes.
- rich flat client would have some good CAS language (no dlls), still the rich flat client should have a separation (in two executable) between code doing computations and GUI
A key point of gpu freedom i'd like to port in the next codebase:
Each rich fat client and each server should have a geolocation. Geo location will then be used to route messages. There should be a supernode where servers advertise themself. I believe Napster and Gnutella 2 had such a hierarchical structure.
The gpu freedom codebase would have mature routines to handle https in Freepascal. Now that Freepascal reached version 1.0 and is usable. Delphi is in my opinion dead now.
For C/C++/C# no problem, i also did work in C/C++ and Java and would like to practice C#.
I tried once to start a GPU codebase in C++, but partly failed because i could not find any good socket routines (this was ten years ago :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi C# is nice in dev and debug (except for some new libs and linq that are debugging problem, we can skip using those), compiler is free, what's the catch? The catch is that with most projects you have to use MSSQL and therefore have to use windows platform. We of course will be able to run on Mono.
As for GUI I don't care - I won't develop it.
Last edit: Alex Fihman 2012-10-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
would be great to standardize first the message passing API serverside... and the geolocation mechanism. It should be so general, that also a file sharing system could be implemented on top of it... with broadcast and point to point system... and scalable on the server side as well with no central point of failure...
(in the meanwhile i ordered the book 'Computer Algebra Handbook' by Grandmeier. There is also a chapter on distributed CAS...)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here some notes, after grasping some info from the Computer Algebra handbook.
I drop the MAS approach (Modula-2 close to Freepascal) as it is not a full CAS system.
Todate Maxima is implemented on GNU Common Lisp (lisp-2 dialect, differs slightly from CLisp). There are parallel versions of lisp (schemix, multilisp) but they are all lisp-1. Scheme and Clojure support some parallelism, still they fall in the lisp-1 category.
Additionally, all parallel lisps work on shared memory, while we would like to achieve a distributed memory approach with GPU III.
There is a package for GNU Common Lisp (lisp-2) pargcl, to be release, which works with MPI on distributed memory architecture.
(The code of PhD thesis of Joel Moses for Symbolic integration is in sin.lisp under maxima/src)
Last edit: dangermouse 2012-11-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So GPU III could be a CAS system over a parallel LISP on random graph networks for some tasks and with dedicated libraries for numerical tasks (an MPI over random networks).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One idea for GPU would be to implement a CAS frontend (Computer Algebra System like Maple, Matlab or Mathematica, see also http://en.wikipedia.org/wiki/Computer_algebra_system ). The frontend would parse complex expressions including integration and differentation, complex matrix problmes etc., translate it into some kind of postfix notation e.g. with Shunting Yard (?). The postfix notation could be GPU stack language that would be eventually distributed to nodes.
The CAS language would be then partially executed in a distributed manner (if possible), and this is why we would name the frontend CAScade...
Last edit: dangermouse 2012-09-27
I think what needs to be done first is to create clear API protocol for GPU. Like bittorrent. Another thing is, Sqlite has stupid way of locking. I don't like it personally and can go into details why.
hi Alex, in fact in the unfinished code in gpu_freedom i experienced problems with sqlite and locking... i remember that there were different versions of the sqlite dll, but i thought i would have downloaded the right one. if you want to give some detail of the sqlite locking problems i would be very interested...
when one process locks DB, inserts or updates are not waiting for lock to release, but just fail. I used mutexes to wait for DB locks. What gpu_freedom can do now?
anyway let's discuss server side, it can be split into 3 parts: connectivity, task scheduling, task execution.
What are the ideas for connectivity? I want to have Linux server along with Windows one.
We will keep push model?
Task execution: a more clean plug-in design model?
The idea of gpu_freedom is a hybrid model with servers in PHP/mySQL and clients in Freepascal.
Freepascal now is very mature and stable, we could have Windows and x86-Linux clients as well. For connectivity i would now prefer pure HTTP or HTTPS (in gpu_freedom there are libraries which can do both fairly well, i tested them on hacker.org) because they work through firewalls and proxies, especially behind corporate proxies.
In gpu_freedom there is a PUSH on server/PULL on clients model.
Task execution: we could use the mparith library for big number support. The plugin design is a bit complicated because modules can be dynamically loaded... But in principle there is only one signature method which contains the stack definition... This for the low level part...
Part of the task execution is the language to express tasks (in GPU there is this GPU stack language, which is kind of postfix notation). There were also experiments to include some other scripting language... Python would be cool. Or some kind of CAS language like in Maple or Maxima (the free Maple)...
I realise here i am working from bottom-up, i assume you'd prefer a top-down approach. But maybe discussing we can meet in the middle...
I've seen so many bad projects, so I want code quality to be of certain level here.
Therefore I will keep asking questions to refine the ideas.
The stack was funny but due to string memory being overwritten in DLL there was unrepairable memory deallocation problems.
Now sqlite is great thing but multithreading access to DB sucks. I used wrapping methods that access (and lock) db with mutexes, but windows mutexes are not available in linux, so in order for code to be generic I had to use boost. But then another problem arises: boost mutex remains set even if you kill application, and you have to unset it via application or reboot PC.
Firefox for example uses many sqlite DB files, in this way they try to minimize locking problems by having DB for each process.
And lately I am C/C++/C# guy, not much in Delphi/Pascal, sorry to say.
so my next question: what does server and what does client? Cheers, Alex
Last edit: Alex Fihman 2012-10-02
ok Alex, excluse the late reply, i did not notice you replied.
Thinking at what was done in the GPU freedom codebase, and to save some parts of it:
what about of such an approach:
- use PHP/mySQL server just to relay messages between rich flat clients. Messages would be sent via HTTPS (they can bypass most proxies at companies). people setting up such servers would have some cool graphs to stare at (with the OpenFlashChart component).
Messages would be of two types: broadcast and to single nodes.
- rich flat client would have some good CAS language (no dlls), still the rich flat client should have a separation (in two executable) between code doing computations and GUI
A key point of gpu freedom i'd like to port in the next codebase:
Each rich fat client and each server should have a geolocation. Geo location will then be used to route messages. There should be a supernode where servers advertise themself. I believe Napster and Gnutella 2 had such a hierarchical structure.
The gpu freedom codebase would have mature routines to handle https in Freepascal. Now that Freepascal reached version 1.0 and is usable. Delphi is in my opinion dead now.
For C/C++/C# no problem, i also did work in C/C++ and Java and would like to practice C#.
I tried once to start a GPU codebase in C++, but partly failed because i could not find any good socket routines (this was ten years ago :-)
Hi C# is nice in dev and debug (except for some new libs and linq that are debugging problem, we can skip using those), compiler is free, what's the catch? The catch is that with most projects you have to use MSSQL and therefore have to use windows platform. We of course will be able to run on Mono.
As for GUI I don't care - I won't develop it.
Last edit: Alex Fihman 2012-10-18
would be also great to create a process for each plugin
would be great to standardize first the message passing API serverside... and the geolocation mechanism. It should be so general, that also a file sharing system could be implemented on top of it... with broadcast and point to point system... and scalable on the server side as well with no central point of failure...
(in the meanwhile i ordered the book 'Computer Algebra Handbook' by Grandmeier. There is also a chapter on distributed CAS...)
broadcast messages will be broadcast only to subscription "channels"
nodes are nodes in some sort of DHT
Perhaps we can just take existing DHT for messaging core?
Here some notes, after grasping some info from the Computer Algebra handbook.
I drop the MAS approach (Modula-2 close to Freepascal) as it is not a full CAS system.
Todate Maxima is implemented on GNU Common Lisp (lisp-2 dialect, differs slightly from CLisp). There are parallel versions of lisp (schemix, multilisp) but they are all lisp-1. Scheme and Clojure support some parallelism, still they fall in the lisp-1 category.
Additionally, all parallel lisps work on shared memory, while we would like to achieve a distributed memory approach with GPU III.
There is a package for GNU Common Lisp (lisp-2) pargcl, to be release, which works with MPI on distributed memory architecture.
(The code of PhD thesis of Joel Moses for Symbolic integration is in sin.lisp under maxima/src)
Last edit: dangermouse 2012-11-22
So GPU III could be a CAS system over a parallel LISP on random graph networks for some tasks and with dedicated libraries for numerical tasks (an MPI over random networks).