control classes and interfaces

We can hold our business logic on separate classes. As example we will use a bank loan application, which is supposed to bring us the proper load for certain kind of customers of a bank. So, we need to define an interface pf the loan component.

interface Loan {
    void setUserData(User bankUser);
    void setCustomerData(Customer cus, Account acc);
    LoanResults getLoanResults();
}

This simple interface should be implemented by a variety of Loan types, from consumer ones to mortgage ones, since this variety of loans have different evaluation and estimation logic.

Now we need to define a way to instantiate the proper Loan implementation. The proper Loan implementation request is on the hands of the control layer, since the Loan interface is the abstraction layer itself. So, if we have to need the same methods for every Loan that we request, we just use a Factory Pattern returning the interface Loan, instead of his real implementation.

the abstraction layer

The abstraction layer is implemented on the Loan interface and its returning implementation based on the factory pattern. So we need to implement the factory outside of the package that holds that set of interfaces and implementations. The factory also hold the logic that decides which Loan implementation will be returned, based on the user data, customer data and account data. So we need a call similar to this one:

Loan loanRequest = LoanFactory.getInstance(data);
LoanResults requestResults = loanRequest.getLoanResults();

So, the factory and the loan interface holds the abstraction layer, separating the decoupling the business logic from its real implementation and generating more cohesion. What does the loan request form in the application about those components? The answer is quiet simple: nothing. We will use another pattern to hold input data and pass it through the abstraction layer from the presentation layer. Here is when we are doing dependency injection.

the presentation layer

The presentation layer, which in this case holds a simple LoanRequestForm will never know which concrete class will be used to deliver the LoanResults, so we have to define an instance of another pattern, an Adapter. The adapter should transform the input data from the LoanRequestForm to some kind of Data Transfer Object, to be passed to the factory as CustomerData.

class LoanRequestForm {
    protected Customer cus;
    protected User usr;
    protected Account acc;
    protected LoanRequestFormAdapter adapter = new LoanRequestFormAdapter();
    protected Loan loanRequest;

    LoanResults getLoanResults() {
        try {
            loanRequest = LoanFactory.getInstance(adapter.transform(this));
            LoanResults requestResults = loanRequest.getLoanResults();
            return requestResults;
        } catch (InvalidDataException ex) {
            log.error(ex);
        }
    }
}

Here we are injecting a dependency for the LoanRequestForm and also we acquiring abstraction through the LoanFactory, transforming its input using the LoanRequestFormAdapter to transform the form data into a DTO (Data Transfer Object). The business logic is completely separated from the its User Interface and the abstraction layer. So we are fitting the model with PAC pattern and the IoC DI pattern at once.

The transformation between the form and the factory is a must. The factory can not depend on the form and the form can not depend on the factory. The adapter plays an important role here, since it’s separating layers and transforming the application into an n-tier architected application, so we have more control over changes and possible enhancements on the model. Also it will bring us possible automated processes, since the factory do not needs the form to operate over the loan. So you build another application that just handles the user data and generate loan bids automatically to the customers based on the same logic, then we are reusing the properly the code.

conclusion

We can glue the PAC pattern with IoC DI pattern, so we have more reliable and flexible GUI implementations, then we can work in our platforms without worries about how to generate reusable code if we follow well designed and well applied patterns. Also we can use frameworks, but it depends on the application size and how do need to work on it. For an application with just two active forms, we do not need large scale architectures.

Copyright © 2010 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2010. | Permalink | No comment
Post tags:

• Correctness:

  Software correctness can be established using many techniques and tools, from static analysis, runtime checkers and formal verification. So we have enough tools to determine whether or not the software is correct. Also we can search for the proper algorithm, previously verified and tested to being used in our software.

• Robustness:

  We must try to create small and efficient code, regarding correctness and documenting it, so can create hardened code based on common standards to allow reliable modifications while we are maintaining the code. Jon Postel‘s law says: "Be conservative in what you do; be liberal in what you accept from others". This also reduces the amount of bugs that you can find on your applications.

• Efficiency:

  Efficient code has lower times and reduced cyclomatic complexity. For example we must prefer a construct that is O(1) instead of one that is O(n), if it is available, and we must prefer a construct that has a cyclomatic complexity of 78 rather than other with 129: "simplicity is divine".

• Portability:

  The code must be portable. To create portable code we must simply omit the usage of language/platform specific features. There many standards that we can follow to create portable code and there also are compiler options to help us in that task. For example, GCC supports pedantic compiling flags to regard the strictness of some standards, try compiling your C code with: -Wall -Wextra -Wshadow -pedantic -std=c99, or your C++ code with: -Wall -Wextra -Wshadow -pedantic -std=c++98. Also there is a compiler with the portability issue in mind, the TENDRA compiler, it comes with a static analysis tool too.

• Expressiveness:

  We must create legible code, this principle holds well known coding standards, naming conventions and similar scopes on how do we write the code, to let others read your code and understand it with a faster lookup to the documentation. Also documenting the code is a must. I’m sure that you can follow some standard on coding.

• Flexibility:

  We must try to use abstraction in our code, instead of concrete system calls. For example we have dirent on UNIX and WIN32_FIND_DATA on Windows, both structures are completely different and most Win32 API calls aren’t based on any known standard, so we need to create or use some kind of abstraction to access the system calls, like the Façade design pattern, to allow us to omit direct calls and create more flexible code, and easy to maintain.

• Modularity:

  It’s fully recommended that we must think on terms of OOP. For C programmers the book "Object-oriented programming with ANSI-C" possibly is a must read. Modularity bring us the robustness needed to operate on terms of cohesion, like any desired architecture, we want to implement cohesion instead of attachment, so we can create reusable code and modules.

• Discoverability:

  legible and modular code bring us a good discoverability, so we can establish good basis on well known standard APIs, like POSIX, C++0x and many others. This regards the intuitive approach of building portable code, so we can guess about how is called the function or class that we need to use in our problem.

• Transparency:

  In conjunction with modularity, transparency can bring us the proper cohesion between our software components. The proper abstraction layer between the application tiers allow us to create individual components that work together without attachment and with the proper cohesion. So the maintainability of the application becomes higher and easy.

And here comes some questions: How can we measure all those points?; How can we become more strict and bring more reliable applications?. We must follow some steps to reach optimal software development process. The first one is to define the application architecture, so we can handle common problems with the proper architectural patterns. Then we must fit those architectural patterns with the proper design patterns. One time defined the application architecture we must design our components following that architecture. If we are using Agile Methodologies, we need a well defined architecture too, so we can follow a common paradigm on how to solve the problem that the application is solving.

Using third party frameworks or third party libraries is not a bad practice, but we must be constantly following its roadmap, looking the direction that the library or framework is following, so we can handle properly an incoming and imminent update. How to handle that issue?, using abstractions and modularity, which also reduces the amount of bugs. Here some patterns plays an important role in our quality goals, for example the façade, factory and dependency inyection patterns would help us on that task.

conclusion

The more rigorous we are, we can get more reliable software. But sometimes we don’t have enough time or simply we don’t need to be too rigurous, for example we can not apply formal verification to enterprise applications, because usually those applications have millions of lines of code, instead possibly we can deliver just one module at time that has been verified formally. Instead we can use metrics analyzers, static analyzers and runtime checkers to bring us a better approach on how the code is working. You can learn code hardening techniques and debugging techniques to ensure your code too, which will bring you a better code if you get well taught on those topics.

Copyright © 2010 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2010. | Permalink | No comment
Post tags:

As result, we got a nice architecture design, very applicable to most problems present on the platform. Also, I was capable to answer many questions about the enterprise application. Many of those answers were made based on reverse engineering the source code, tracking every step and tracing component execution. Each member was capable to read some books that we recommended with the Project Manager and understand the third party software, like Google Web Toolkit and Apache FOP. The Project Manager was a good leader guiding the team to the right direction on what to read and how self taught those technologies, while I was doing the proper research, then we got a good team response, and being considered as a good provider.

The key on success was nobody was afraid to ask about the enterprise application, so each member of the team was capable to understand how to interact with those layers that were not accessible as source code — like a black box — and that everyone on the team was responsible of learning the techonologies related to the team work: "read that book", "read that blog article", "take a look on this specification" and some other phrases were common on that team, so everyone was capable to understand their own task.

Most questions were channeled directly to the project manager, then I he was capable to answer, the problem was solved on the fly. In other case, the problem was delivered to me as software architect. Also, team members were capable to ask me directly. Also, most questions were made on SCRUM sessions, and few ones were asked outside of those SCRUM sessions. Few books on Software Architecture, JavaEE Design Patterns, Design Patterns and Architectural Patterns, bring us a wide perspective on how to solve most problems for the kind of components that we were developing. So, most problems were found on the black-box-like enterprise application, since we were having few referrals.

Even if one software engineer was considered — before joining the team — as an NNPP or bad programmer, on the team we got a good result. I agree with Phillip G. Armour in his article "In Prise of Bad Programmers", where he treat this problem as an advantage to make stronger teams:

Sometimes the teams are not made up of all superheroes and when the team asserts itself to overcome some limitation, even with its own personnel, it can become better than it would have been without limitations.

All team members were capable to learn about the enterprise application without the pressure of of not having someone supporting them and fear to commit bugs into the VCS. The were constantly improving their skills, by different reasons, but everyone was learning. As spotted Pete Godlife on his article "Live to love Learning":

Your motivation might be to keep yourself fresh, to sharpen your existing skills or simply to satisfy your natural curiosity. Or the reason might be more mercenary: to strengthen your employability, or allow you to move into a programming field you are more interested in.

conclusion

On every new application which requires new components or maintenance, we need to research it, we must invest time looking on how it works, how affects any change and how we can contribute to improve its construction. Analysis capability is learned along the time and acquired by studying applications and code, you can not request a 100% successful development to someone that do not have the proper guide on a large enterprise application, you need someone doing research on it, doing reverse engineering if it is not documented and let the people learn from that member that have the advantage, even if the application looks like this one — which fortunately isn’t the case in this post.

Copyright © 2010 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2010. | Permalink | One comment
Post tags:

pyxser

pyxser have about one year of development, some months doing research, and other months doing development or coding the Python Module.

And the SVN log show an average hour for commits between 22:00 and 23:00

r125 | damowe | 2010-02-10 16:15:49 -0300 (Wed, 10 Feb 2010) | 2 lines
r124 | damowe | 2010-02-10 15:52:31 -0300 (Wed, 10 Feb 2010) | 2 lines
r123 | damowe | 2010-02-10 13:30:15 -0300 (Wed, 10 Feb 2010) | 10 lines
r122 | damowe | 2010-02-02 08:47:07 -0300 (Tue, 02 Feb 2010) | 3 lines
r121 | damowe | 2009-12-26 21:52:49 -0300 (Sat, 26 Dec 2009) | 2 lines
r118 | damowe | 2009-12-26 21:40:33 -0300 (Sat, 26 Dec 2009) | 2 lines
r117 | damowe | 2009-12-25 15:20:30 -0300 (Fri, 25 Dec 2009) | 4 lines
r116 | damowe | 2009-12-22 20:09:25 -0300 (Tue, 22 Dec 2009) | 5 lines
r115 | damowe | 2009-12-21 19:47:50 -0300 (Mon, 21 Dec 2009) | 2 lines
r114 | damowe | 2009-12-20 01:38:45 -0300 (Sun, 20 Dec 2009) | 7 lines
r112 | damowe | 2009-12-03 09:48:41 -0300 (Thu, 03 Dec 2009) | 6 lines
r110 | damowe | 2009-11-30 14:52:10 -0300 (Mon, 30 Nov 2009) | 2 lines
r109 | damowe | 2009-11-30 14:46:43 -0300 (Mon, 30 Nov 2009) | 9 lines
r107 | damowe | 2009-08-23 11:43:52 -0400 (Sun, 23 Aug 2009) | 2 lines
r102 | damowe | 2009-08-23 11:29:07 -0400 (Sun, 23 Aug 2009) | 2 lines
r99 | damowe | 2009-08-23 11:12:20 -0400 (Sun, 23 Aug 2009) | 6 lines
r98 | damowe | 2009-08-08 15:15:07 -0400 (Sat, 08 Aug 2009) | 3 lines
r93 | damowe | 2009-07-28 21:59:10 -0400 (Tue, 28 Jul 2009) | 2 lines
r90 | damowe | 2009-07-27 22:22:55 -0400 (Mon, 27 Jul 2009) | 2 lines
r89 | damowe | 2009-07-27 22:21:50 -0400 (Mon, 27 Jul 2009) | 5 lines
r88 | damowe | 2009-07-26 22:27:23 -0400 (Sun, 26 Jul 2009) | 4 lines
r87 | damowe | 2009-07-20 16:02:27 -0400 (Mon, 20 Jul 2009) | 5 lines
r86 | damowe | 2009-07-17 22:24:53 -0400 (Fri, 17 Jul 2009) | 4 lines
r84 | damowe | 2009-05-09 23:19:49 -0400 (Sat, 09 May 2009) | 2 lines
r83 | damowe | 2009-05-09 22:31:00 -0400 (Sat, 09 May 2009) | 7 lines
r82 | damowe | 2009-05-09 11:00:44 -0400 (Sat, 09 May 2009) | 3 lines
r81 | damowe | 2009-05-08 21:31:56 -0400 (Fri, 08 May 2009) | 2 lines
r80 | damowe | 2009-04-28 00:32:53 -0400 (Tue, 28 Apr 2009) | 3 lines
r78 | damowe | 2009-04-26 19:21:16 -0400 (Sun, 26 Apr 2009) | 2 lines
r77 | damowe | 2009-04-26 19:13:26 -0400 (Sun, 26 Apr 2009) | 2 lines
r76 | damowe | 2009-04-26 17:34:09 -0400 (Sun, 26 Apr 2009) | 4 lines
r75 | damowe | 2009-04-25 19:31:45 -0400 (Sat, 25 Apr 2009) | 3 lines
r74 | damowe | 2009-04-24 20:49:40 -0400 (Fri, 24 Apr 2009) | 3 lines
r73 | damowe | 2009-04-23 23:06:46 -0400 (Thu, 23 Apr 2009) | 4 lines
r72 | damowe | 2009-04-22 08:28:31 -0400 (Wed, 22 Apr 2009) | 3 lines
r71 | damowe | 2009-04-22 00:52:12 -0400 (Wed, 22 Apr 2009) | 2 lines
r70 | damowe | 2009-04-22 00:28:48 -0400 (Wed, 22 Apr 2009) | 3 lines
r69 | damowe | 2009-04-21 23:09:09 -0400 (Tue, 21 Apr 2009) | 2 lines
r68 | damowe | 2009-04-21 16:41:11 -0400 (Tue, 21 Apr 2009) | 3 lines
r65 | damowe | 2009-04-19 01:24:34 -0400 (Sun, 19 Apr 2009) | 2 lines
r64 | damowe | 2009-04-19 01:22:15 -0400 (Sun, 19 Apr 2009) | 2 lines
r63 | damowe | 2009-04-19 01:17:29 -0400 (Sun, 19 Apr 2009) | 2 lines
r62 | damowe | 2009-04-19 01:10:33 -0400 (Sun, 19 Apr 2009) | 2 lines
r61 | damowe | 2009-04-19 00:01:47 -0400 (Sun, 19 Apr 2009) | 3 lines
r59 | damowe | 2009-04-18 22:57:01 -0400 (Sat, 18 Apr 2009) | 2 lines
r58 | damowe | 2009-04-18 22:30:30 -0400 (Sat, 18 Apr 2009) | 3 lines
r57 | damowe | 2009-04-18 04:26:58 -0400 (Sat, 18 Apr 2009) | 2 lines
r56 | damowe | 2009-04-18 03:28:56 -0400 (Sat, 18 Apr 2009) | 3 lines
r55 | damowe | 2009-04-15 23:38:34 -0400 (Wed, 15 Apr 2009) | 2 lines
r54 | damowe | 2009-04-15 23:10:32 -0400 (Wed, 15 Apr 2009) | 2 lines
r53 | damowe | 2009-04-15 22:46:15 -0400 (Wed, 15 Apr 2009) | 3 lines
r52 | damowe | 2009-04-10 18:30:22 -0400 (Fri, 10 Apr 2009) | 2 lines
r49 | damowe | 2009-04-10 00:17:25 -0400 (Fri, 10 Apr 2009) | 2 lines
r47 | damowe | 2009-04-08 23:43:50 -0400 (Wed, 08 Apr 2009) | 4 lines
r46 | damowe | 2009-04-08 14:29:42 -0400 (Wed, 08 Apr 2009) | 4 lines
r45 | damowe | 2009-04-08 01:31:22 -0400 (Wed, 08 Apr 2009) | 2 lines
r44 | damowe | 2009-04-08 01:30:18 -0400 (Wed, 08 Apr 2009) | 2 lines
r43 | damowe | 2009-04-08 01:28:36 -0400 (Wed, 08 Apr 2009) | 3 lines
r42 | damowe | 2009-04-06 21:58:57 -0400 (Mon, 06 Apr 2009) | 2 lines
r41 | damowe | 2009-04-06 21:46:19 -0400 (Mon, 06 Apr 2009) | 2 lines
r40 | damowe | 2009-04-06 21:36:55 -0400 (Mon, 06 Apr 2009) | 3 lines
r39 | damowe | 2009-04-05 22:25:50 -0400 (Sun, 05 Apr 2009) | 2 lines
r38 | damowe | 2009-04-05 22:19:10 -0400 (Sun, 05 Apr 2009) | 4 lines
r37 | damowe | 2009-04-04 20:18:15 -0400 (Sat, 04 Apr 2009) | 3 lines
r36 | damowe | 2009-03-31 23:49:23 -0400 (Tue, 31 Mar 2009) | 5 lines
r33 | damowe | 2009-03-28 12:13:41 -0400 (Sat, 28 Mar 2009) | 2 lines
r30 | damowe | 2009-03-26 22:17:10 -0400 (Thu, 26 Mar 2009) | 3 lines
r29 | damowe | 2009-03-26 21:59:57 -0400 (Thu, 26 Mar 2009) | 5 lines
r28 | damowe | 2009-03-26 21:17:10 -0400 (Thu, 26 Mar 2009) | 2 lines
r27 | damowe | 2009-03-25 23:26:30 -0400 (Wed, 25 Mar 2009) | 3 lines
r26 | damowe | 2009-03-25 22:58:16 -0400 (Wed, 25 Mar 2009) | 5 lines
r25 | damowe | 2009-03-25 22:03:16 -0400 (Wed, 25 Mar 2009) | 2 lines
r24 | damowe | 2009-03-25 21:00:44 -0400 (Wed, 25 Mar 2009) | 4 lines
r23 | damowe | 2009-03-25 20:48:26 -0400 (Wed, 25 Mar 2009) | 3 lines
r22 | damowe | 2009-03-25 20:34:30 -0400 (Wed, 25 Mar 2009) | 2 lines
r21 | damowe | 2009-03-25 20:15:58 -0400 (Wed, 25 Mar 2009) | 2 lines
r20 | damowe | 2009-03-24 20:47:42 -0400 (Tue, 24 Mar 2009) | 2 lines
r19 | damowe | 2009-03-23 23:41:47 -0400 (Mon, 23 Mar 2009) | 5 lines
r18 | damowe | 2009-03-23 21:03:13 -0400 (Mon, 23 Mar 2009) | 3 lines
r17 | damowe | 2009-03-23 20:16:58 -0400 (Mon, 23 Mar 2009) | 2 lines
r16 | damowe | 2009-03-19 22:57:46 -0400 (Thu, 19 Mar 2009) | 2 lines
r15 | damowe | 2009-03-19 22:30:56 -0400 (Thu, 19 Mar 2009) | 5 lines
r14 | damowe | 2009-03-19 20:37:13 -0400 (Thu, 19 Mar 2009) | 2 lines
r13 | damowe | 2009-03-19 00:37:39 -0400 (Thu, 19 Mar 2009) | 3 lines
r12 | damowe | 2009-03-19 00:11:23 -0400 (Thu, 19 Mar 2009) | 3 lines
r11 | damowe | 2009-03-18 23:47:08 -0400 (Wed, 18 Mar 2009) | 3 lines
r10 | damowe | 2009-03-17 22:25:47 -0400 (Tue, 17 Mar 2009) | 2 lines
r9 | damowe | 2009-03-17 22:23:21 -0400 (Tue, 17 Mar 2009) | 2 lines
r8 | damowe | 2009-03-17 22:16:37 -0400 (Tue, 17 Mar 2009) | 2 lines
r7 | damowe | 2009-03-17 00:55:43 -0400 (Tue, 17 Mar 2009) | 2 lines
r6 | damowe | 2009-03-16 23:33:31 -0400 (Mon, 16 Mar 2009) | 2 lines
r5 | damowe | 2009-03-15 17:21:57 -0400 (Sun, 15 Mar 2009) | 2 lines
r4 | damowe | 2009-03-15 17:07:39 -0400 (Sun, 15 Mar 2009) | 2 lines
r1 | damowe | 2009-03-15 15:35:31 -0400 (Sun, 15 Mar 2009) | 2 lines

The project has 6,198 lines of code… a good effort and a good product. During the day I must work on those projects which bring me money, at night and as hobbits I work on my FOSS projects. I have a little time to work on them.

caffeine

caffeine or C Application Framework has 14,177 lines of code, and it is evaluated as one project with three humans working on it, but it is really one, me.

And the SVN log show an average hour for commits between 22:00 and 23:00

r125 | damowe | 2009-09-30 14:45:06 -0400 (Wed, 30 Sep 2009) | 6 lines
r124 | damowe | 2009-09-26 18:49:31 -0400 (Sat, 26 Sep 2009) | 2 lines
r123 | damowe | 2009-09-26 17:46:26 -0400 (Sat, 26 Sep 2009) | 5 lines
r122 | damowe | 2009-09-26 13:14:50 -0400 (Sat, 26 Sep 2009) | 2 lines
r121 | damowe | 2009-09-26 12:25:19 -0400 (Sat, 26 Sep 2009) | 4 lines
r120 | damowe | 2009-09-22 05:18:11 -0400 (Tue, 22 Sep 2009) | 8 lines
r119 | damowe | 2009-09-19 23:27:06 -0400 (Sat, 19 Sep 2009) | 5 lines
r118 | damowe | 2009-09-19 19:06:50 -0400 (Sat, 19 Sep 2009) | 8 lines
r117 | damowe | 2009-09-01 22:18:54 -0400 (Tue, 01 Sep 2009) | 5 lines
r116 | damowe | 2008-10-27 07:40:14 -0300 (Mon, 27 Oct 2008) | 2 lines
r115 | damowe | 2008-10-27 07:38:30 -0300 (Mon, 27 Oct 2008) | 2 lines
r114 | damowe | 2008-10-27 07:35:09 -0300 (Mon, 27 Oct 2008) | 3 lines
r113 | damowe | 2008-10-25 13:01:20 -0300 (Sat, 25 Oct 2008) | 2 lines
r112 | damowe | 2008-06-10 21:10:30 -0400 (Tue, 10 Jun 2008) | 3 lines
r111 | damowe | 2008-06-06 20:05:39 -0400 (Fri, 06 Jun 2008) | 5 lines
r110 | damowe | 2008-05-08 21:12:50 -0400 (Thu, 08 May 2008) | 2 lines
r109 | damowe | 2008-05-06 23:53:10 -0400 (Tue, 06 May 2008) | 2 lines
r108 | damowe | 2008-05-05 23:37:42 -0400 (Mon, 05 May 2008) | 2 lines
r107 | damowe | 2008-04-27 02:08:49 -0400 (Sun, 27 Apr 2008) | 2 lines
r106 | damowe | 2008-04-26 11:59:49 -0400 (Sat, 26 Apr 2008) | 4 lines
r105 | damowe | 2008-04-22 23:06:33 -0400 (Tue, 22 Apr 2008) | 3 lines
r104 | damowe | 2008-04-21 21:13:06 -0400 (Mon, 21 Apr 2008) | 4 lines
r103 | damowe | 2008-02-10 13:16:32 -0300 (Sun, 10 Feb 2008) | 3 lines
r102 | damowe | 2008-02-10 10:22:34 -0300 (Sun, 10 Feb 2008) | 2 lines
r101 | damowe | 2008-02-10 10:08:35 -0300 (Sun, 10 Feb 2008) | 2 lines
r100 | damowe | 2008-01-06 12:07:57 -0300 (Sun, 06 Jan 2008) | 4 lines
r99 | damowe | 2008-01-05 20:03:27 -0300 (Sat, 05 Jan 2008) | 4 lines
r98 | damowe | 2008-01-01 17:29:14 -0300 (Tue, 01 Jan 2008) | 3 lines
r97 | damowe | 2007-12-31 15:47:20 -0300 (Mon, 31 Dec 2007) | 2 lines
r96 | damowe | 2007-12-30 12:15:46 -0300 (Sun, 30 Dec 2007) | 2 lines
r95 | damowe | 2007-12-30 12:06:41 -0300 (Sun, 30 Dec 2007) | 3 lines
r94 | damowe | 2007-12-30 07:59:58 -0300 (Sun, 30 Dec 2007) | 2 lines
r93 | damowe | 2007-12-25 10:37:15 -0300 (Tue, 25 Dec 2007) | 3 lines
r92 | damowe | 2007-12-22 09:57:27 -0300 (Sat, 22 Dec 2007) | 2 lines
r91 | damowe | 2007-12-22 09:56:15 -0300 (Sat, 22 Dec 2007) | 4 lines
r90 | damowe | 2007-12-22 07:26:39 -0300 (Sat, 22 Dec 2007) | 3 lines
r89 | damowe | 2007-12-16 22:21:51 -0300 (Sun, 16 Dec 2007) | 4 lines
r88 | damowe | 2007-12-03 21:35:27 -0300 (Mon, 03 Dec 2007) | 2 lines
r87 | damowe | 2007-12-01 23:56:53 -0300 (Sat, 01 Dec 2007) | 3 lines
r86 | damowe | 2007-12-01 23:44:02 -0300 (Sat, 01 Dec 2007) | 2 lines
r85 | damowe | 2007-11-11 09:06:24 -0300 (Sun, 11 Nov 2007) | 4 lines
r84 | damowe | 2007-11-10 21:43:36 -0300 (Sat, 10 Nov 2007) | 2 lines
r83 | damowe | 2007-11-10 21:25:58 -0300 (Sat, 10 Nov 2007) | 2 lines
r82 | damowe | 2007-10-07 11:39:55 -0400 (Sun, 07 Oct 2007) | 3 lines
r81 | damowe | 2007-10-07 08:32:09 -0400 (Sun, 07 Oct 2007) | 3 lines
r80 | damowe | 2007-09-30 21:53:52 -0400 (Sun, 30 Sep 2007) | 3 lines
r79 | damowe | 2007-09-19 18:27:20 -0400 (Wed, 19 Sep 2007) | 2 lines
r78 | damowe | 2007-09-18 00:34:21 -0400 (Tue, 18 Sep 2007) | 2 lines
r77 | damowe | 2007-09-17 17:10:57 -0400 (Mon, 17 Sep 2007) | 3 lines
r76 | damowe | 2007-09-15 17:27:45 -0400 (Sat, 15 Sep 2007) | 2 lines
r75 | damowe | 2007-09-08 11:19:19 -0400 (Sat, 08 Sep 2007) | 2 lines
r74 | damowe | 2007-09-02 12:11:38 -0400 (Sun, 02 Sep 2007) | 2 lines
r73 | damowe | 2007-09-02 10:57:54 -0400 (Sun, 02 Sep 2007) | 2 lines
r72 | damowe | 2007-09-02 10:55:09 -0400 (Sun, 02 Sep 2007) | 2 lines
r71 | damowe | 2007-09-02 09:38:43 -0400 (Sun, 02 Sep 2007) | 5 lines
r70 | damowe | 2007-09-02 02:13:20 -0400 (Sun, 02 Sep 2007) | 4 lines
r69 | damowe | 2007-08-31 20:05:06 -0400 (Fri, 31 Aug 2007) | 3 lines
r68 | damowe | 2007-08-26 13:34:53 -0400 (Sun, 26 Aug 2007) | 2 lines
r67 | damowe | 2007-08-26 13:15:04 -0400 (Sun, 26 Aug 2007) | 3 lines
r66 | damowe | 2007-08-26 10:10:19 -0400 (Sun, 26 Aug 2007) | 3 lines
r65 | damowe | 2007-08-25 19:00:10 -0400 (Sat, 25 Aug 2007) | 3 lines
r64 | damowe | 2007-08-19 00:26:00 -0400 (Sun, 19 Aug 2007) | 3 lines
r63 | damowe | 2007-08-18 10:36:16 -0400 (Sat, 18 Aug 2007) | 3 lines
r62 | damowe | 2007-08-15 17:23:28 -0400 (Wed, 15 Aug 2007) | 2 lines
r61 | damowe | 2007-08-13 07:48:31 -0400 (Mon, 13 Aug 2007) | 3 lines
r60 | damowe | 2007-08-12 17:06:08 -0400 (Sun, 12 Aug 2007) | 2 lines
r59 | damowe | 2007-08-12 16:33:09 -0400 (Sun, 12 Aug 2007) | 3 lines
r58 | damowe | 2007-08-12 13:39:59 -0400 (Sun, 12 Aug 2007) | 2 lines
r57 | damowe | 2007-08-12 01:26:32 -0400 (Sun, 12 Aug 2007) | 2 lines
r56 | damowe | 2007-08-11 13:26:10 -0400 (Sat, 11 Aug 2007) | 2 lines
r55 | damowe | 2007-08-11 13:21:17 -0400 (Sat, 11 Aug 2007) | 3 lines
r54 | damowe | 2007-08-06 21:58:22 -0400 (Mon, 06 Aug 2007) | 2 lines
r53 | damowe | 2007-08-04 23:03:06 -0400 (Sat, 04 Aug 2007) | 3 lines
r52 | damowe | 2007-08-04 22:39:10 -0400 (Sat, 04 Aug 2007) | 3 lines
r51 | damowe | 2007-08-04 17:28:45 -0400 (Sat, 04 Aug 2007) | 2 lines
r50 | damowe | 2007-08-04 16:54:48 -0400 (Sat, 04 Aug 2007) | 2 lines
r49 | damowe | 2007-07-29 09:15:12 -0400 (Sun, 29 Jul 2007) | 2 lines
r48 | damowe | 2007-07-28 17:38:23 -0400 (Sat, 28 Jul 2007) | 2 lines
r47 | damowe | 2007-07-16 23:45:16 -0400 (Mon, 16 Jul 2007) | 3 lines
r46 | damowe | 2007-07-16 16:47:06 -0400 (Mon, 16 Jul 2007) | 3 lines
r45 | damowe | 2007-07-15 20:03:51 -0400 (Sun, 15 Jul 2007) | 3 lines
r44 | damowe | 2007-07-15 12:10:35 -0400 (Sun, 15 Jul 2007) | 3 lines
r43 | damowe | 2007-07-02 17:30:56 -0400 (Mon, 02 Jul 2007) | 2 lines
r42 | damowe | 2007-07-02 10:46:27 -0400 (Mon, 02 Jul 2007) | 3 lines
r41 | damowe | 2007-06-30 16:23:19 -0400 (Sat, 30 Jun 2007) | 2 lines
r40 | damowe | 2007-06-23 21:08:20 -0400 (Sat, 23 Jun 2007) | 3 lines
r39 | damowe | 2007-06-23 10:37:22 -0400 (Sat, 23 Jun 2007) | 2 lines
r38 | damowe | 2007-06-23 10:33:24 -0400 (Sat, 23 Jun 2007) | 2 lines
r37 | damowe | 2007-06-22 23:10:58 -0400 (Fri, 22 Jun 2007) | 3 lines
r36 | damowe | 2007-06-20 21:57:34 -0400 (Wed, 20 Jun 2007) | 3 lines
r35 | damowe | 2007-06-18 21:22:26 -0400 (Mon, 18 Jun 2007) | 3 lines
r34 | damowe | 2007-06-17 21:33:13 -0400 (Sun, 17 Jun 2007) | 2 lines
r33 | damowe | 2007-06-17 21:31:58 -0400 (Sun, 17 Jun 2007) | 2 lines
r32 | damowe | 2007-06-17 18:48:40 -0400 (Sun, 17 Jun 2007) | 3 lines
r31 | damowe | 2007-06-17 12:03:32 -0400 (Sun, 17 Jun 2007) | 3 lines
r30 | damowe | 2007-06-17 11:50:15 -0400 (Sun, 17 Jun 2007) | 2 lines
r29 | damowe | 2007-06-16 21:48:05 -0400 (Sat, 16 Jun 2007) | 2 lines
r28 | damowe | 2007-06-16 21:43:38 -0400 (Sat, 16 Jun 2007) | 3 lines
r27 | damowe | 2007-06-09 18:25:07 -0400 (Sat, 09 Jun 2007) | 2 lines
r26 | damowe | 2007-06-09 18:05:07 -0400 (Sat, 09 Jun 2007) | 2 lines
r25 | damowe | 2007-06-09 18:03:56 -0400 (Sat, 09 Jun 2007) | 3 lines
r24 | damowe | 2007-06-03 20:45:25 -0400 (Sun, 03 Jun 2007) | 3 lines
r23 | damowe | 2007-06-03 19:08:34 -0400 (Sun, 03 Jun 2007) | 2 lines
r22 | damowe | 2007-06-03 19:07:35 -0400 (Sun, 03 Jun 2007) | 2 lines
r21 | damowe | 2007-05-21 10:48:01 -0400 (Mon, 21 May 2007) | 2 lines
r20 | damowe | 2007-05-20 22:00:12 -0400 (Sun, 20 May 2007) | 2 lines
r19 | damowe | 2007-05-20 21:45:38 -0400 (Sun, 20 May 2007) | 6 lines
r18 | damowe | 2007-05-20 10:57:12 -0400 (Sun, 20 May 2007) | 2 lines
r17 | damowe | 2007-05-19 22:22:24 -0400 (Sat, 19 May 2007) | 5 lines
r16 | damowe | 2007-05-18 21:41:36 -0400 (Fri, 18 May 2007) | 2 lines
r15 | damowe | 2007-05-14 23:02:09 -0400 (Mon, 14 May 2007) | 3 lines
r14 | damowe | 2007-05-13 12:03:47 -0400 (Sun, 13 May 2007) | 2 lines
r13 | damowe | 2007-05-13 01:01:13 -0400 (Sun, 13 May 2007) | 2 lines
r12 | damowe | 2007-05-12 22:48:18 -0400 (Sat, 12 May 2007) | 2 lines
r11 | damowe | 2007-05-12 22:41:14 -0400 (Sat, 12 May 2007) | 3 lines
r10 | damowe | 2007-05-07 08:57:33 -0400 (Mon, 07 May 2007) | 2 lines
r9 | damowe | 2007-05-03 08:37:04 -0400 (Thu, 03 May 2007) | 3 lines
r8 | damowe | 2007-05-02 20:50:25 -0400 (Wed, 02 May 2007) | 3 lines
r7 | damowe | 2007-05-01 17:43:00 -0400 (Tue, 01 May 2007) | 2 lines
r6 | damowe | 2007-05-01 09:31:08 -0400 (Tue, 01 May 2007) | 2 lines
r5 | damowe | 2007-05-01 09:24:07 -0400 (Tue, 01 May 2007) | 1 line
r4 | damowe | 2007-05-01 09:08:02 -0400 (Tue, 01 May 2007) | 2 lines
r3 | damowe | 2007-05-01 09:05:41 -0400 (Tue, 01 May 2007) | 2 lines
r2 | damowe | 2007-05-01 09:04:51 -0400 (Tue, 01 May 2007) | 2 lines
r1 | damowe | 2007-05-01 09:04:22 -0400 (Tue, 01 May 2007) | 2 lines

Both projects requires effort and research, and both project are not simple ones to handle, since they are written in C, a language difficult to learn and handle… I hope that I can continue the foss development that I’ve started, but seems that I have some health problems now

Copyright © 2010 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2010. | Permalink | No comment
Post tags:

1.4.2r (2010.02.10):

        Daniel Molina Wegener <dmw at coder dot cl>
        * pyxser_collections.c: Added constraint checks for NULL
        pointers removing nested statements.
        * pyxser.c: Removed nested statements.
        * pyxser_tools.c: Added constratints checks for NULL pointers,
        removed nested statements and added strict checking for lists
        since it was crashing with an ambigous list definition that
        can not be handled by PyList_Check().
        * test-utf8.py: Added tests to determine if it continue
        crashing with module serialization.

        Thanks to pyxser users for their feedback.

I want to bring special thanks to Dariusz Suchojad for his feedback. I’ve fixed some type checking bugs and minor ones. Now pyxser is capable to do module serialization, but not in concrete one, still is not capable to distribute modules, so it is capable to create a simple module representation as XML, under the pyxser serialization model.

I hope that it will help you on your programming tasks.

Copyright © 2010 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2010. | Permalink | No comment
Post tags:

the subject matters

Sure, a good subject can be used to index properly your emails. For example try to use some kind of convention, do not throw the subject as a previously known conversation. For many years I’ve been using my own convention on electronic mail subjects for my projects. Generally I use the form: "Client, Project, Real Subject" or "Project, Real Subject". So you can easily find your messages related to each project just by looking on the subject. The proper subject is a good introduction to the email that you will write or read.

the format matters

Plain text (text/plain), wrapped on column 76 or 64 — it depends on your taste — with well formed paragraphs and using the proper mime encoding for localization — on Usenet and some mailing lists is useful to use US-ASCII as encoding. Many companies are using HTML formatted mail with those gif images as company logos attached, and sometimes a huge disclaimer as email footer, and many replying on top of the previous message. Well, your fancy looks ugly here. I use Kontact, hence I use Kmail and a great feature of Kmail is the fact that it do not opens HTML formatted mails immediately, it regards my preference and ask me if I want to open it. Do you remember the I love you virus which was spreading through electronic mail?. Fancy colors and pictures leave your mail looking as SPAM, overfilled with propaganda, and those huge disclaimers for me are a disrespect to me, since it is like to send a real mail, and mail service opens the envelope and attach another document into it.

A possible solution is to standardize the proper E-Mail header for those bring that information without modifying the content of the original message:

• X-Company-Logo, should contain an URL to the company logo. I hope that it should reside under HTTPS protocol.
• X-Disclaimer, should contain an URL to the company disclaimer of the electronic mail.
• X-Sender-Identity, should contain an URL to the sender contact information, possibly a vCard or a plain text signature.

Sending that information — since most SMTP email is authenticated — can be easyly inserted on the electronic mail and it will become a part of the envelope, not the original message.

labeling for indexing

Many mail clients are using labels to create additional indexes on the electronic mail, but seems that is not standardized. Here an additional mail header should be useful — I hope that most companies will agree. X-Labels should be used to add labels to the electronic mail, it can be delimited with the ;; string. So, it will become standardized for most clients, including on sending mail, so the mail client can receive them and ask the user if he wants to add the label.

conclusions

Read some mailing lists or Usenet newsgroups to get introduced on how to write and read electronic mail. Read the RFC 1855 to get the real rules on formal electronic mail. Stop sending that fancy electronic mail, it has no sense, your company will not be more respected by sending those mails, for many people it has the opposed effect.

Copyright © 2010 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2010. | Permalink | No comment
Post tags:

overview

First we need a concrete class implementing the parser, but it needs an abstraction layer and also something which provides the proper parsing states to its internals. Finally we need to expose those extracted tokens outside of this component — the meta-parser.

Clearly the abstraction is made in top of a single template, the control is given from the ParserService class and the presentation is provided through the Token interface with the proper implementations.

substring automaton

Another interesting point is how specific string parsing is implemented. The system uses an FSM, which implements a simple automaton:

So, parsing the left hand token implies parsing the value token and then it states the right hand token, to complete the cycle reaching again the stored value token . This is used to extract substrings. Where every token is configurable with a proprietary language. Finally, the full parser specific implementation is made on top of state machines which are used according the proper configuration representation using thitd party classes and structures, so is possible to extract the required tokens from the input source.

Also, each configuration and parser instances are designed for concurrency. The project will be running on with parallel tasks inside a mutithreaded — and possibly multiprocess — service daemon. Driven by my client schedule, I can not implement wait free algorithms, so I will be using standard operating system provided locks — and more easy to handle algorithms.

in deep with abstractions

Although the PAC pattern is designed for user interfaces, the usage of this pattern to communicate components and generate strong abstraction layers helps a lot on design and maintainability issues. Indeed, this patterns guarantee a reward while we are coding some design patterns. In this case, for example the MetaParser and the ParserService are both an instance of Adapters, where a transformation is made from one layer to other. While MetaParser is a strong abstraction layer for the given implementations.

Finally ParserService provide us the proper way to handle different parsing tasks, so we can determine inside it which abstraction to use though the proper MetaParser instance.

conclusion

The PAC pattern can be used to implement component communications and proper abstraction between application layers, among the usage on user interfaces. Does it falls in other architectural pattern? Anyone knows?.

Copyright © 2010 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2010. | Permalink | No comment
Post tags:

1. "request well specified requirements"

   Request well specified requirements. Even if you are using one of those dynamic methodologies. Never let your boss to set ambiguous requirements, this will be your hell and nightmare, and request a formal requirement in the proper email and documentation. I do not mean a word document with tons of lines, I’m talking about requirement clarifications, where you are responsible to request the proper clarifications if you are looking something ambiguous. Also your boss is responsible to write well specified requirements, both technically and functionally. There are well known gay bosses who send ambiguous requirements and usually they are changing those requirements every day… Yeah! the same ones who are delivering your application with the initial deadline even when they are taking new ones! If the client do not have the proper knowledge about software, the client do no have the proper knowledge to evaluate deadlines, the same happens with your boss.

2. "formalize your progress"

   Formalize your work progress, by using mails, the proper VCS comments, and source code documentation, even is that is required by your boss or not. You need to register properly your work progress, and you must create the proper sub-milestones for each project milestone which is assigned to you.

3. "forget that job without a technically skilled boss"

   Do not work on company where your boss is not capable to define properly what he wants and even on a company where the boss is not capable to catch the client requirements. A boss must be capable to charge every new requirement to the client, if your boss do not do that, your boss is giving away your time and your life. If your job requires you out of workday, your job sucks, and even your boss, since he/she is not capable to handle new requirements and make the proper charge. Also, a good manager knows that you need the proper time to do all those tasks listed bellow

4. "clean code"

   Clean code, legible code and well indented code will allow more developers to handle it. If work on a company where real teamwork matters, everyone will be capable to support your development if you are busy in other task. Clean code is that one which has few ugly modification — most of them regarding software performance — and follows well known coding standards, such as naming conventions, indentation rules and documenting techniques. Regard a 7 bit US-ASCII encoding, and never use accents — simply because some editors, compilers, and coding tools do not support other encodings and most software is compatible with 7 bit US-ASCII encoding. For localization use external packages, such as property files in Java, gettext files with C and C++, and related tools.

   You always must have in mind that your code will be taken into the most ancient platform and the most newbie coder — just someone what happens to some environments when you setup UTF-8 encoding on the project and you add a non UTF-8 file in it, and the headache that you get when you are not conscious about WTF is happening. Your boss will be entirely happy with the lost time…

5. "commented code"

   Well documented code is not that one which holds poetry inside it. Useful and descriptive comments are those ones which allows the developer to understand which logic is contained in your functions. Also you must comment every modification separately, for example if you change a b * Math.pow(2.0, a); operation by a << b to get more performance, comment it!

   There are well known commenting techniques. Take a look on known documents, such as manual pages to have wide perspective on how to comment the code — manual pages have the best documentation structure that I’ve ever seen. I think that toy documentation, like javadoc, really sucks, since it is poorly redacted and non descriptive. Do you really know someone who is able to develop an entire Java application just by looking at the javadoc without looking for examples? The same happens with C# and .NET documentation.

6. "use annotations to track your project"

   Classical annotation, on your VCS or code comments will help you to track pending tasks, enhancements that may be done and will allow you to pass messages to other developers. There are classical ones TODO: and XXX: for example. You can use TODO for all your "To Do" tasks in each file and "XXX" for precisely document modifications and enhancements that may be done on the code. This will ensure that pending tasks will never be lost in some ugly word document on an erased mail which tries to poorly describe a required task. Also you can support those tasks by using Issue Tracking and Bug Tracking systems, but are like those ugly lost documents and you can not explain in detail with the code itself which task is required where

7. "check for null pointers"

   Before using an object, check if it is null, otherwise use an error catching mechanism. This rule do not needs more explanations, and is a well known issue and spotted the right title: The Billion Dollar Mistake.

8. "do not trust user input".

   I do not trust the user input, never. I’m always trying to validate the user input, since the common user is doing mistakes using applications. The user input and generally the input in your functions require certain validation, from the data type to expected values, such as range or length. Validation in Web Applications should be made in both sides too, the Web Browser — using JavaScript and HTML attributes — and the server side. The most important one is the server side validation and it is a must. On other kind of applications, user input must be validated too.

9. "apply debugging".

   Do not stay comfortable with the code working. Debug your applications, tracing each step. Remember that you can modify variable values in your code inside your debugger, so you can do more code hardening tests. Learn about your debugger the better as you can. Read books on debugging techniques: "Debugging" and "Code Complete", for example. I’m conscious about the fact that every language and every debugger works different, but debugging techniques are always sharing common tasks and checks.

10. "apply static analysis".

    Apply static analysis to ensure that your code is clean and using better practices. Indeed, those kind of tools will help you to discover more bugs. Some of them can do code path checking and Boolean evaluation checking. If the language that you are using do not have support from static analysis tools, it really sucks. There are well known tools for doing static analysis and source code checking, and also are well known bugs discovered along the time with those tools. You must combine debugging and static analysis together.

If you do not work on a company where you do not have the proper time to do each of those tasks listed above, your job sucks. Surely you are delivering bad code, sometimes with those invisible bugs that appears when you are not expecting them. Falling one time and another on the same bugs and the same project that may not be released at time.

Copyright © 2010 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2010. | Permalink | No comment
Post tags:

"…premature optimization is the root of all evil".
— Donald Knuth

I agree with the fact that we must do our source code level optimizations when we have finshed the construction stage or it is almost complete. I was searching articles and papers about optimizing C source code to be applied on my programs and libraries. I’ve collected some of those optimizations. But you must not confuse algorithm optimization, source code optimization and compiler optimization, since the first one refers to algorithm design and the second one just refers to the algorithm implementation, and both are sharing just few common approaches to formal reductions.

Usually the source code optimization just applies well known formal reductions. We will not treat those formalities in this article. Instead we will take a look on some examples that I’ve collected, allowing a common reasoning about how to optimize the source code. Most ideas for source code optimizations comes from η-conversions using λ equivalences, allowing for example reductions from . Also, some optimizations without an apparent η-conversion, since most is done at low level, as those which are taken by the compiler and translated to less assembler instructions, such as function inlining and parameter reduction. Most η-conversions which implies η-reductions, and are called strength reductions. But we have also the opposed side, where we are — instead of doing reductions — populating our programs with more lines of code, including repeated code, such as the loop unrolling optimization.

inline code

C supports both macros and inlining functions. Both features are reaching the same effect, when the code is compiled, all inlined instructions are placed when we call the macro or the inline function. For example, a typical approach, is a max(a, b) function or a MAX(a, b) macro.

/* the slowest expression, compiling and running */
int
max(int a, int b)
{
	if (a > b)
		return a;
	else
		return b;
}

/* normal expression with inlining */
inline int
max(int a, int b)
{
	return ((a > b) ? a : b);
}

/* the faster expression using macros */
#define MAX(a, b)			((a > b) ? a : b)

The inline and the macro definitions both are similar. The macro places every occurrence of MAX(var1, var2) expressions with the ((var1 > var2) ? var1 : var2) expression. The inline does the same, and places every occurrence of max(var1, var2) with the result of the expression ((var1 > var2) ? var1 : var2). So, the macro usage is oriented to replace entire blocks of code, instead of inline functions which are oriented to replace calls and skip the assembler call instruction and its derivates. We may look examples of the call opcode in typical system calls on operating systems, such as FreeBSD system calls.

parameter reduction

Reducing parameters implies less assembler instructions. C calling convention typically push parameters into the stack, which implies that for each parameter a push opcode call is made. For example you can group function arguments — if they are use subsequently by a group of functions — under struct forms. Think a little, each push instruction in his family takes 2 clocks, varying to 18 clocks on x86 architecture — depending on vendor and model. For 8 arguments, it will take from 16 to 36 clocks, against 2 to 18 clocks with one argument. This approach on argument reduction may be applied to those functions which are not inlined.

/* slower version */
int
my_function(int arg1, int arg2, int arg3, int arg4)
{
	/* do something... */
}

/* faster version */
struct myargs
{
	int arg1; int arg2; int arg3; int arg4;
};

int
my_function(struct myargs *args)
{
	/* do something... */
}

practical reductions

We do reduction when we remove unnecessary steps in our functions. We can do most reductions just by thinking a little on the code, and also there are some well known reductions which can be used as optimizations.

removing else

/* with else, smaller code, but slower one */
inline int
test(int a)
{
	return a > 0 ? 1 : 0;
}

/* without else, large code but faster one */
inline int
test(int a)
{
	if (a > 0)
		return 1;
	/* implied else */
	return 0;
}

On this optimization, we are removing jmp and jxx family of instructions, where most of them takes near to 7 clocks on x86 architecture and also the required instruction to setup the proper context for the following instruction in the program sequence. This is like the spartan programming style, where most code is minimized through reductions and similar programming tasks.

bitwise operations

Bitwise operations are cheaper than other operations. For example, curiously, a shift operation and plus operations have less clocks than multiplication and division operations. The happens to logical evaluations. In other post, I’ve wrote about logical minimizations. A complement to what I’ve said, is the fact that mul instruction takes from 10 to 40 clocks and div instruction takes from 15 to 40 clocks on x86 architecture, against add, sub, shr, shl and similar instruction that are taking from 2 to 7 clocks. Remember that the number clocks used by some instruction is vendor and model dependent. For example if we do:

/* we take a call to the math.h function pow() */
n = y * pow(2.0, x);

/* we can replace it by */
n = y << x;

In other words, the x << y operation is equivalent to . You can find other math equivalences too. From this basic approach, we can reach other types of optimizations through the proper maths. You can take a look on the bit wizardry page from Jörg Arndt if you want to seek for more bitwise operations and reductions.

reversing counter loops

Usually we do one step loops for fixed set of counters. The following example shows a reduction which can be used every time we can do a reverse loop.

/* for loop coded usually */
for (c = 0; c < MAX_C_VALUE; c++) {
	/* do something... */
}

/* for reversed loop */
for (c = MAX_C_VALUE; c--; /* we do not do nothing here */ ) {
	/* do something... */
}

table lookups

A table lookup is the technique where we create an array and kind related structures to lookup for data, usually previously calculated data or simply, we are looking for concrete data that we want to use.

/* we can have a switch statement */
ourtype_t *varn = NULL;
switch (var1) {
case 0:
	varn = value1; break;
case 1:
	varn = value2; break;
case 2:
	varn = value3; break;
default:
	varn = value1;
}

/* or have an if/else statement */
if (var1 == 0)
	varn = value1;
else if (var1 == 1)
	varn = value2;
else if (var2 == 2)
	varn = value3;
else
	varn = value1;

/* so we can simply replace those values using arrays */
ourtype_t mapsvalues[] = { value1, value2, value3 };
varn = mapsvalues[var1];

Also we usually can setup reductions by creating table lookups and state machines, so we can create the proper map between certain variable data and certain function. State machines are a powerful abstraction which allows us to code different states inside data structures.

We can have predefined values in our table lookup tasks. Then we are using lazy evaluation. Every time we have a constant value which is requested and not calculated each time we work with it, we are doing lazy evaluation.

register keyword

/* using the register keyword should help creating faster code */
register int counter;

reduce data access computation

If we have deep constructed data structures (struct in C), every time we access most deep nodes, we are using pointer arithmetics, which implies basic math operations to access certain parts of our structures. Here we can do tow tasks: alias creation and usage and padding adjustment. Alias usage, means that we must use an internal pointer to access directly a structure member, so we omit pointer calculation each time we access it. Padding adjustment, is just about to create the proper data structure member order.

/* structure without the proper padding */
struct my_struct {
	char *a;
	void *b;
	int c;
	double n;
	char *x;
};

/* the same structure with the proper padding */
struct my_struct {
	double n;
	int c;
	char *a;
	char *x;
	void *b;
};

Also the data access computation is reduced on assembler level code, not the C code. Here we have an implied η-reduction and invisible one. For deeply and nested data structures, we have the same issue. We should have as rule that the structure size must have an ideal size of , with as the structure size and as the padding adjustemnt to power of two.

/* some structs with nested members */
struct a {
	int m1;
};

struct b {
	int m2;
	struct a *m3;
}

struct c {
	int m4;
	struct b *m5;
}

/* the non cheaper version to access its members */
struct c *x = some_function_returning_c();
x->m5->m3->m1 = some_other_function();
if (x->m5->m3->m1 != 0) {
	another_function(x->m5->m3->m1);
}

/* the cheaper version to access its members
   using aliases */
struct c *x = some_function_returning_c();
struct b *p;
b = x->m5->m3;
b->m1 = some_other_function();
if (b->m1 != 0) {
	another_function(b->m1);
}

loop unrolling

Each step on a loop repeats some instructions. For example if we have a fixed size array, where we must treat each element with certain function, we can use unrolled loops.

/* normal iteration over fixed size array */
for (i = 0; i < 100; i++) {
	call_some_function(my_array[i]);
}

/* applied loop unrolling and reverse loop */
for (i = 100; i--;) {
	call_some_function(my_array[i]);
	call_some_function(my_array[--i]);
	call_some_function(my_array[--i]);
	call_some_function(my_array[--i]);
	call_some_function(my_array[--i]);
}

Note that here we have a fixed size array. In other case is hard to know the array size. Also we can use our compiler optimization to unroll each loop, if our compiler has the proper option. For example GCC supports automatic loop unrolling by using the -funroll-loops flag.

loop jamming

Reusing blocks of code inside loops matters.

/* here we have two loops for something that can
   be done one loop */
for (i = 0; i < 100; i++) {
	some_function_a(my_array[i]);
}
for (i = 0; i < 100; i += 10) {
	some_function_b(my_array[i]);
}

/* here we have two loops for something that can
   be done one loop */
for (i = 0; i < 100; i++) {
	some_function_a(my_array[i]);
	if ((i % 10) == 0) {
		some_function_b(my_array[i]);
	}
}

On the example above we have the proper loop doing the same tasks with less operations, so we have reduced the steps of that loop from to — note that is just symbolic and not strict.

bit padding matters

It depends on the architecture. Processing data types shorter or larger than the register size do not have a cheaper cost than using them. For example if we use char or short, we are not using a complete register, which is more hard to handle than register length variables, such as int and long.

references

• Michael E. Lee, "Optimization of Computer Programs in C", Ontek Corporation.
• Adrian Barnetts, "C optimisation tutorial".
• Paul Hsieh, "Programming Optimization".
• Koushik Ghosh, Writing Efficient C and C Code Optimization, The Code Project.
• Optimizing C and C++ Code. EventHelix.
• Cris H. Pappas and William H. Murray, "386 Microprocessor Handbook", McGraw Hill.

Copyright © 2009 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2009. | Permalink | One comment
Post tags:

In Java, thread synchronization made using the synchronized keyword can create a heavy — with a high number of threads — overhead in two main cases, the first one is when it is used on classes and the second one when it is used in methods. Then we must think a way to create small locks, mainly if we are using design patterns like singletons.

/* BAD CASE 1, throws NullPointerException */
class BadMutexBaseClass {
	private static BadMutexBaseClass singletonInstance;
	public static BadMutexBaseClass getInstance(void) {
		synchronized (singletonInstance) {
			if (singletonInstance == null) {
				singletonInstance = new BadMutexBaseClass();
			}
			return singletonInstance;
		}
	}
}

/* BAD CASE 2, heavy overhead */
class BadMutexBaseClass {
	private static BadMutexBaseClass singletonInstance;
	public synchronized static BadMutexBaseClass getInstance(void) {
		if (singletonInstance == null) {
			singletonInstance = new BadMutexBaseClass();
		}
		return singletonInstance;
	}
}

Both cases are wrong, we must use mutex object, without touching the singleton member and allowing the program to access the singleton atomically. We can use a basic Object instance to create the proper mutex.

/* MUTEX BASED CASE */
class MutexBaseClass {
	private static Object mutex = new Object();
	private static MutexBaseClass singletonInstance;
	public static MutexBaseClass getInstance(void) {
		synchronized (mutex) { /* critical section */
			if (singletonInstance == null) {
				singletonInstance = new MutexBaseClass();
			}
			return singletonInstance;
		}
	}
}

By creating a dummy object, we can use it as mutex in our program. With a more low level perspective, this technique is similar to the one used with pthread_mutex_lock(P) techniques while we are programming with threads in C. An interesting point is the fact that non-blocking algorithms are faster than locking ones. The mutex technique is a blocking technique. Non-blocking techniques, such as lock-free and obstruction-free, can allow the user to implement faster — but more complex — code.

GCC has built-in atomic operations to allow the creation of such code, like CAS operations, allowing the use of lock-free techniques. For example in the code bellow — which is using the __sync_bool_compare_and_swap atomic operation — we can see that the CAS or Compare and Swap operation is made around the number of transactions with old value and old value plus one.

do {
	old = vproc_shmem->vp_shmem_transaction_cnt;

	if (unlikely(old < 0)) {
		if (vproc_shmem->vp_shmem_flags & VPROC_SHMEM_EXITING) {
			_exit(0);
		} else {
			__crashreporter_info__ = "Unbalanced: vproc_transaction_begin()";
		}
		abort();
	}
} while( !__sync_bool_compare_and_swap(&vproc_shmem->vp_shmem_transaction_cnt, old, old + 1) );

I hope that Java will include kind that atomic operations to allow the use of non-blocking algorithms and more faster code and since I agree with the fact that we are entering the multi-core era…

Copyright © 2009 Daniel Molina Wegener
Atribución-No Comercial-Sin Derivadas 2.0 Chile

© Daniel Molina Wegener for coder . cl, 2009. | Permalink | No comment
Post tags: