http://www.niccolai.cc/ en-us Nucleus CMS v3.33 © Weblog http://backend.userland.com/rss http://www.niccolai.cc//nucleus/nucleus2.gif http://www.niccolai.cc/ http://www.niccolai.cc/index.php?itemid=375
Long story short:

Parallel programming is writing programs where one or more parts are designed to potentially or actually run at the same time on different computational nodes (processors, computers, co-processors).

Multithreading programming (or simply threading) consists in using a set of tools to control physical computational parallel resources, together with their physical synchronization and sharing devices. Some multithreading structures abstract the final physical layer, but MT never gives completely off the ability to control the minute instruction flow on every processor you have at your disposal. Mutexes and MT-wise semaphores (i.e. MS-Windows events or POSIX condition variables) may be implemented differently on different processor architectures, but their point is granting that the underlying processors and/or the operating system tightly bound to it will do a set of operation granting some specific behavior of the hardware.

So, is MT parallel programming? -- No, but you can DO parallel programming with MT tools/programs/libraries. When using MT, either you want to control the underlying hardware parallel abilities for other reasons (and you don't want to mess with the raw ASM needed to do that), or you're writing your own parallel programming environment, for how simple it is, to make your program to do tasks in parallel.

After some years in the field and in the field of programming languages, I finally came to the conclusion that high level languages, and especially scripting languages, doesn't need MT. Worse, exposing MT-level operations and concepts to high level scripts (threads, mutexes, and so on) can harm more than help.

What you want when using a low level language is to be low level as low as you can, but not lower. In C and C++, you want threads, CPU affinity masks, mutexes, condition variables. What you want when you use an high level language is to be high level as much as you can, but not more. Like, doing all the messy stuff of a whole C program in a couple of well-designed instructions or commands. You want to tell the system the LOGIC of your THOUGHTS, and then you want the system to do the stuff for you.

In short, the next Falcon version will have threads and parallel structures removed, and will embed threading in the language itself, not differently from Erlang or Ocalm. Coroutining may be reviewed as well, and be considered a special case of threading. The idea is to be able to define parallel code, and find the compiler (for what can be told at compile time) and the VM (for the runtime conditions) to run it "as parallel as possible". A VM may be assigned the limit of 0 thread, thus making all the parallel code to run as coroutines.

More on the upcoming idea in the next post.



]]> Falcon http://www.niccolai.cc/index.php?itemid=375 Mon, 28 Jun 2010 14:58:32 -0700 http://www.niccolai.cc/index.php?itemid=373 Black is white, up is down and short is long!. I'd vote for Al Yankovic to be dubbed mankind heritage. Or nobel price. Or something.

I would, but I am wrong, so I won't.

]]> General http://www.niccolai.cc/index.php?itemid=373 Tue, 15 Jun 2010 16:44:04 -0700 http://www.niccolai.cc/index.php?itemid=369
So I added a tweet panel right on the sidebar of this blog, to see if I can make some good use of it. I thought it may be interesting to keep fast notes about Falcon development and other everyday issues there.

However, it can't hurt, can it?

]]> General http://www.niccolai.cc/index.php?itemid=369 Mon, 24 May 2010 05:09:44 -0700 http://www.niccolai.cc/index.php?itemid=364
Also, if specifically constrained and shaped down with the help of well-defined language extensions, as the type contracts we're designing, altering a class may not be as bad as it sounds.
The main reason why Falcon classes had never been flexible was because there was optimization opportunities in both the Falcon-language side and in the C embedding side which couldn't be caught otherwise, at the time when the first implementation was planned (but notice that METHODS are first class entities in Falcon, as functions, so it was possible to make normal properties methods after instance creation by just assigning a callable item to them). Later on, dictionaries and Tables was added to create classless instances and pervasive instance-control (table columns). So, it's not really flexibility that was leaking; if you want flexibility in your code, you could opt for POOP constructs in blessed dictionaries, array bindings and tables.

However, the ability to transform a type, and not just a prototype at runtime is something slighly different from what we have. And it has a ring, for how dangerous it may seem.

Another problem in changing a class structure is that falcon native instances store their property value in an array that must stay parallel with the class property dictionary. So, altering a class would disrupt the property-value relationship. Also, instance properties are undifferentiated, so explicitly declared class methods are just properties to which a method item is assigned by default at class creation.

And here is where the fun begins.

Falcon instance creation is extremely efficient, as it consists of just a flat copy of the class default property vector (and then, calling the constructor function, if needed). There's no tree-based dictionary copy involved; each instance is just a sequence of the Falcon Items it is supposed to hold.

This also allows for a thing that is quite interesting in the Falcon OOP model; while class structure is fixed, you have the ability to change the properties into methods seamlessly at runtime. But, how many users take advantage of this opportunity, and how much does it cost to us to keep it?

In the new model we're gonna introduce (the one I talked about in the previous blogs), we indicated the fact that we're moving the property control logic from the object instance to the class. This allows for an interesting change.

We can now put all the methods (those you declare with "function" keyword) under the control of the class, while the properties stays under the control of the objects.

Follow this example:

class MyClass
// a property
prop = "value"

// an instance-specific method -- a property where you store a function
imethod = function( param )
return param + self.prop
end

// a real method
function method( param )
return "method " + param + self.prop
end
end

inst = MyClass()

inst.prop = "new value" // obviously legal

inst.imethod = { param =>
return "changed "+ param + self.prop } // still legal

inst.method = { param =>
return "changed "+ param + self.prop } // now legal, but would become illegal.

MyClass.method = { param => reutrn "A new method!" } // now illegal, and this is the new part we want to have.

// Also, we want to do MyClass.addMethod and MyClass.removeMethod


Making illegal the second last statement we achieve two interesting results.
1) the vast majority of classes have few properties and many methods. Storing the methods in the owning class would further reduce the footprint of each instance, by a great deal.
2) classes could be changed at runtime; adding new methods would be immediately reflected on all the existing instances.
Adding new properties would be possible, but we may chose two ways of dealing with that:
2.1) ignore new properties on old instances, and apply them only on new instances.
2.2) mark the "generation" of the class and apply the changes to the instances in a lazy fashion, when they are accessed. As an old instance with a different generation is accessed, it is brought up to date inserting the newly added properties with their default value.

I'd lean for 2.1, because 2.2 would introduce extra ops at each access that are unneeded 99.9% of the time. But, 2.2 would be more consistent, eliminating an unnatural differentiation between the ability of alter the methods and the properties.

Of course, this ability would apply to CoreClasses and to HyperClasses (using the definitions we previously introduced); as UserClasses are actually instructions for Falcon to access user data, applying this on a UserClass may either
1) raise an exception or
2) create a HyperClass and a synthetic CoreClass, and substituting the UserClass with this new HyperClass.

I'd lean for 1, considering user-provided classes nearly "final"; also, in case of absolute need, a code like that:

class Changeable from AnUserClass
end

would take care of the problem.


]]> Falcon http://www.niccolai.cc/index.php?itemid=364 Tue, 11 May 2010 03:41:05 -0700 http://www.niccolai.cc/index.php?itemid=363 The true skeptic answers: "You shouldn't. That's the point."
]]> General http://www.niccolai.cc/index.php?itemid=363 Wed, 14 Apr 2010 09:43:49 -0700 http://www.niccolai.cc/index.php?itemid=361
This should fix the problem and allow interface-based classing to work.

The system is based on 3 classes: the dear old CoreClass implementing pure language-level classes, a base abstract class for manipulation of foreign data (UserClass) and a class glueing the two, called HyperClass. A new CoreClass can be derived from any count of base CoreClass parents; it knows that its opaque "object" is actually an array of items parallel to its property table (and there's a good news about property tables too). The CoreClass is meant to be final (or nearly so).

UserClass doesn't provide any default way to access its properties and makes no assumption on the nature of the opaque data used as object to be manipulated.

The HyperClass is created when linking a CoreClass with a UserClass-derived entity. As the new model doesn't require anymore a VM to be there to link a final class, nor the class structure declaration to be unmodifiable, the CoreClass itself can perform its own link (up to the constructor call). If all its parents are CoreClasses, it will return itself modified so that it has the union of properties provided by the parents (using the current logic). If one or more parents are not CoreClasses (if they are user or hyper classes), it creates an HyperClass that will take its place.

The Hyperclass knows its opaque structure to be an HyperObject, that is, an array of opaque pointers where the element 0 MAY be occupied by an item array storing data coming from the CoreClasses, while the others are the opaque pointers known and manipulated by each non-CoreClass parent.

The HyperClass handles its properties differently from CoreClasses: it holds a list of HyperProperties each indicating the owning class (after link resolution), the position of the owning class in the HyperObject array (0 if the parent is a CoreClass) and, in case the property is coming from the CoreClass hierarcy, the position to access the property.

In this way, if willing to access a property provided by a UserClass (of which Falcon knows nothing about the internal object manipulation logic), it will just hand down to the right class the request to get that property on an opaque data of the type that the UserClass is expecting to manipulate.

In case of explicit subclass access (i.e. HyperClass.BaseClass.prop), the process is even simpler. If the BaseClass is a CoreClass, we simply ask for the default value of that property (as defined by our standard); if it's a UserClass, we simply hand down the request for that property to the UserClass, feeding it with its own data (Note to me: a flag should indicate if we're taking the default property via the baseclass access).

The HyperClass fits also the interface object picture.
Interfaces are inherited exactly like objects. When forming an HyperClass, if a subclass provides an interface object (i.e. the sequence interface for hooking into for/in, or the array subscript interface), the winning interface gets wrapped into a HyperInterface for the same task, which records that interface and the position in the HyperObject that must be passed to that interface if invoked.

This makes possible to turn all the basic structures into UserClasses, with the ability to be even derived. The special callback hooks used for operator overload can force language-based CoreClasses to push in the hierarcy a standard InterfaceObject, whose action is that of calling the required callback. This allows, for example to override the language-defined action for an Array (declared as a UserClass) providing a __getIndex callback on a language level Array subclass (implemented as a CoreClass at module level, and becoming a HyperClass during the link step).

... cool, huh?


]]> Falcon http://www.niccolai.cc/index.php?itemid=361 Thu, 8 Apr 2010 12:29:23 -0700 http://www.niccolai.cc/index.php?itemid=359
The CoreClass has the meaning to describe what Falcon can do with the data you pass. Rather than storing the knowledge of how to handle the object in the CoreObject hierarcy, we can think of the object as a totally opaque entity, and store all the knowledge about it in the CoreClass.

This allows embedders and modules to provide totally opaque data (their data) and separate it from the code that Falcon should use to handle it.

The way to associate CoreClasses with the opaque data they should handle is still under investigation. One option is that of just storing the class and its opaque data in the item, but then we must make sure that a method creation (obj.mth) has a way to refer the class. Shouldn't be too hard in the new model we're developing, as the methods may now have a back-reference to the classes from which they come from.

Another option may that of having a pool of pre-allocated small buffers where the opaque-data / handler-class pair can be stored, and then store that pointer in the items. This has the advantage that we're sure that the opaque data can never be disconnected from the class, but it requires extra allocation, memory management and dereferences.

The current coupling of methods and objects on which they operate solves a problem similar to this, and has been proven one of our most solid assets since first alpha release; so, keeping the pair class/opaque-object or method(class)/opaque-object directly in the item structure seems a very smooth and viable solution.
]]> Falcon http://www.niccolai.cc/index.php?itemid=359 Thu, 8 Apr 2010 08:52:31 -0700 http://www.niccolai.cc/index.php?itemid=357
Interface objects are pure abstract class which the final object can expose to Falcon engine. For example, implementing the "dictionary" interface means to expose a Dictionary* object (which is actualy a virtual table pointer) that must be returned implementing something like getDictionary() class. For example:


class MyDict: public CoreObject
{
MyDict():
m_idict( this )
{}

...
virtual DictionaryInterface* getDictionaryInterface() { return &m_idict; }
...

private:

class DictForMyDict: public DictionaryInterface
{
... reimplement the abstract methods from DictionaryInterface
}
m_idict;
};


And of course, the default for get*Interface() function would be that of returning 0, to let the users know that the required interface is not available.

Problems of this model are mainly two. First, adding an interface type requires to break binary compatibility and also a full recompilation of all the modules. Second, but that's a minor issue, the interface require initialization with "this" during constructor, and that raises a warning on many compilers; also, it suggests storing the "this" pointer in the base class, which makes the Interface base class not fully abstract.

Finally, it would be highly desirable to provide the ability to "expose an interface" even to user-provided classes (i.e. its own application classes) without the need to build a wrapper coreobject.

I am figuring out how to solve this problems.

]]> General http://www.niccolai.cc/index.php?itemid=357 Thu, 25 Mar 2010 14:46:23 -0700 http://www.niccolai.cc/index.php?itemid=355 Falcon version 0.9.6.4. So I took a breath and had a look around and from high above, so that I can plan a good roadmap for the next version.

Also, I notice that my blog is pretty sparse on Falcon. Despite it absorbing a vast part of my everyday life, I rearely write about it in the blog; I prefer to "do" rather than to "argue". Yet, today a couple of questions about some arguments in the Newsgroup have fired the considerations I usually keep for myself, or for the few people on our chat channel.

I immediately thougth that writing some ideas, doubt, solutions down here is much better than keeping them for myself, so I'll be using my blog to keep track of what is going around my mind about Falcon much more regularly from now on.

The achievements I want to obtain in the next version are the final stabilization of the Embedding/module writing API, together with the new Item model and the new compiler/moduler/linker triplet. If it seems ambitious, it must be considered that those elements are tightly interrelated, and cannot exist without each other. So the fix order must be:

Deep item/garbage model -> Item framework -> Syntactic tree -> Module/VM/Runtime -> Compiler

Also, some iterative process will be required. A redesign of the inheritance resolution pattern will require to do a first VM/Link passage, and then continue again into the Deep/item garbage model.

More tomorrow.

]]> General http://www.niccolai.cc/index.php?itemid=355 Thu, 11 Mar 2010 14:26:15 -0800 http://www.niccolai.cc/index.php?itemid=347
Original article (in Italian).

Not the user that leaked the video. Which would be terrible enough. But the providers. In this case, Google itself.

Not even the Iranian government, not even the Myanmar government arrived to this point. They prosecuted the publishing of the ideas, but not the media through which those ideas was published.

An immediate, formal and firm protest of the world internet community is absolutely in order, to avoid that this happens also in your country.

The fact that this happened in Italy, a country where free speech is formally granted by our Constitution and ensured by a rich body of ordinary laws, is a warn and admonishment for all the "free" and "democratic" countries in the world. This can happen even in your country, and even if your country consider itself a Home for free speech.

Fight back now, or it will be too late.

Please, send a mail to the President of the Italian Republic, which has the power to lessen the effectiveness of this sentence in our legal system:

Republic President's webmail.

If other governments think they can do that because Italy did that, it will be a dark day for us all. Stop this from happening.
]]> General http://www.niccolai.cc/index.php?itemid=347 Wed, 24 Feb 2010 02:37:07 -0800