Software Freedom Day is celebrated in over 100 countries worldwide; Linux User Groups in cities all over the UK organise their own initiatives, but this is the first year that the Rugby LUG has held the event.

"The idea of Software Freedom Day is to educate the public about the many benefits of using high-quality, free open source software that is available. Many people may be using Free Software already, without even realising it." says Nick Morrott, from the group. "By increasing awareness of Free Software, our vision is to empower everybody to be able to freely connect, create and share in a digital world that is participatory, transparent, and sustainable."

At the free event, there were representatives from the Free and Open Source software community, as well as from local ICT companies who specialise in FOSS for the home, education and business.

A specialised session for members of the education sector took place prior to the main event, where they could discuss their needs on a one-to-one basis with the specialists.

Volunteers had set up a range of PCs, laptops and projectors so that visitors could experience first-hand the huge range of free software available. A wide range of software suitable for the home, education and business were on-hand, suitable for common tasks such as photo and video editing, multimedia, office and productivity, and games. Visitors could try out these free and open applications on both Microsoft and Linux platforms and benefit from informal and free advice, with the opportunity to arrange further follow-up sessions if required. Many took away information on the solutions as well as "Software Freedom Day" T-shirts, free CD's and memory sticks loaded with software.

The event was a great success, bringing in over 100 visitors, from individuals wanting to know how FOSS can be applied to their home computers, to representatives from larger organisations, charities and local government.

Rugby LUG hopes to organise a similar event next year. For more details, please see the group's website: http://www.rugby.lug.org.uk. or contact us at info@credativ.co.uk

Rugby, UK - 6 June 2011

credativ Ltd, the UK branch of the largest independent provider of Open Source consultancy in Europe, today announced that it is partnering with OpenERP in a move aimed at increasing OpenERP’s share of the UK enterprise resource planning market (ERP).

Chris Halls, MD, credativ UK, comments on the partnership: “OpenERP provides a flexible, robust and cost-effective alternative to proprietary systems such as SAP, JD Edwards EnterpriseOne and Sage, and is especially attractive to SMEs that may have previously found the cost of ERP systems prohibitive.”

“credativ has already introduced OpenERP to UK SMEs and enterprises in the manufacturing, ecommerce and logistics industries. credativ’s customers using OpenERP have already realised business benefits including cost savings, streamlined processes, improved visibility and simplified reporting.”

OpenERP's comprehensive suite of modular applications caters for all major business processes including: CRM, project management, warehouse management, manufacturing, financial management and human resources.

credativ has been providing open source training and consultancy to public and private sector clients since 1999. The credativ team has extensive experience of working with OpenERP; recent implementation work includes delivering customisations for warehousing, accounting, VAT, reporting and Magento e-commerce integration.

Halls continues: “Our partnership with OpenERP underlines our commitment to improving the system’s functionality. We want to highlight open source ERP as an alternative to less flexible proprietary platforms, and believe that this new partnership will bring our experience, size and range of services to organisations who are considering OpenERP.

OpenERP’s modular design allows organisations to introduce or replace existing ERP systems at their own pace without the burden of ongoing licensing costs. We see our partnership with OpenERP as an opportunity to encourage more organisations to make the move to open source.

credativ's unique support offering is available from operating systems to business applications - at scale. Our international OSSC (Open Source Support Centre) provides support and consultancy not only for OpenERP but for all major open source applications and distributions.”

Committed to actively participating in the Open Source community, members of credativ’s 40+ developer team regularly contribute to projects with recent input into OpenERP bug fixes, banking functionality and VAT reporting modules.

About credativ:

Founded in 1999, credativ is an independent consulting and services company which operates from Germany, the U.K., Canada, and the U.S. With a large team of experts in open source software, credativ offers a vast knowledge base that can be tapped into at any time by its clients. The company focuses on the service and support of open source software with a comprehensive range of services, including open source consulting, architectural and technical advice, open source software development, open source training, and personalised support. credativ is “Your One-Stop Shop for Open Source SupportTM”.

In a recent post, I discussed PL/R performance related to seismic timeseries data stored as an array of floats that are all recorded during some seismic event at a constant sampling rate. The problem was that when dealing with, say, 14000 arrays of floats, each having on the order of 16000 elements, passing the data to and from PL/R proved slower than hoped.

My ultimate solution was to show how a significant performance improvement could be achieved by importing the arrays into Postgres tables directly as raw R objects, and then operating on those objects later using PL/R. The problem with this approach is that in some, if not most, cases, you may want to access that same data from other procedural languages or hand off the arrays to some client other than R. In this case the raw R object does not meet your needs.

So I thought about it a bit and researched the source code on the Postgres and R sides of PL/R, and concluded that for certain special cases it was possible to dramatically improve speed by skipping the one-at-a-time element conversion as arrays are processed going between PostgreSQL and R. Specifically, the in-memory storage of the array data is binary compatible in the following circumstances:

1. pgsql -> R
• Argument is integer or double precision array
• Element data type is pass-by-value for given Postgres version and architecture
• No NULL elements
• Array is one dimensional
2. R -> pgsql
• Integer vector returned with integer array return type
• Real vector returned with double precision array return type
• No NA elements
• One dimensional vector

Pass-by-value is most likely true for double precision (float8) if PostgreSQL is at least version 8.4 and was built with a 64 bit system architecture. If these conditions are met, PL/R now simply copies en masse the in-memory array data from the PostgreSQL array data structure to the R vector data structure. This avoids all the overhead associated with iterating over the array element by element. Although I am not a fan of special case code such as this, the use case is important (if you are crunching numbers, they are likely stored as double precision elements), and the performance benefit is huge. Here is the timing difference with the patched PL/R versus the unpatched PL/R:

DROP TABLE IF EXISTS test_ts;
CREATE TABLE test_ts
(
  dataid bigint NOT NULL,
  data double precision[],
  CONSTRAINT pk_data PRIMARY KEY (dataid)
);

CREATE OR REPLACE FUNCTION load_test(int) RETURNS text AS $$
 DECLARE
  i    int;
 BEGIN
  FOR i IN 1..$1 LOOP
   --16789 double precision elements in the data array
   INSERT INTO test_ts (dataid, data) VALUES (i, '{-0.0205086770285039,...}');
  END LOOP;
  RETURN 'OK';
 END;
$$ LANGUAGE plpgsql;

CREATE OR REPLACE FUNCTION
filt_r_nothing(ts double precision[])
RETURNS double precision[] AS $$
  return(ts);
$$ LANGUAGE 'plr' IMMUTABLE;

CREATE OR REPLACE FUNCTION
filt_r_avg(ts double precision[])
RETURNS double precision AS $$
  return(mean(ts));
$$ LANGUAGE 'plr' IMMUTABLE;

-- INSERT 14000 rows of 16789 element arrays
SELECT load_test(14000);

-- unpatched code
UPDATE test_ts SET data = filt_r_nothing(data);
UPDATE 14000
Time: 1224087.064 ms

-- patched code
UPDATE test_ts SET data = filt_r_nothing(data);
UPDATE 14000
Time: 225591.429 ms

-- unpatched code
contrib_regression=# select filt_r_avg(data) from test_ts;
    filt_r_avg     
-------------------
 0.656530643017027
 0.656530643017027
[...]
(14000 rows)
Time: 441573.619 ms

-- patched code
contrib_regression=# select filt_r_avg(data) from test_ts;
    filt_r_avg     
-------------------
 0.656530643017027
 0.656530643017027
[...]
(14000 rows)
Time: 6541.039 ms

-- unpatched code
select array_upper(filt_r_nothing(data),1) from test_ts;
 array_upper 
-------------
       16879
       16879
[...]
(14000 rows)
Time: 1108651.349 ms

-- patched code
select array_upper(filt_r_nothing(data),1) from test_ts;
 array_upper 
-------------
       16879
       16879
[...]
(14000 rows)
Time: 23101.602 ms

So to summarize:

Test	Case	Time (ms)	Improvement
UPDATE NOOP	Unpatched	1224087.064	--
UPDATE NOOP	Patched	225591.429	82%
SELECT AVG	Unpatched	441573.619	--
SELECT AVG	Patched	6541.039	98%
SELECT NOOP	Unpatched	1108651.349	--
SELECT NOOP	Patched	23101.602	98%

Pretty substantial improvement in these particular, but I think common, use cases. The UPDATE test sees less overall benefit because the time to write out the changes would be significant and the same regardless of array handling in PL/R. The difference between SELECT NOOP and SELECT AVG is driven by the fact that the latter returns a scalar result, while the former returns the entire array. The reason SELECT NOOP does array_upper() on the returned array, is that otherwise all that array data (something like 4 GB) gets materialized in memory by psql, which of course greatly slows things further and is not what we are trying to test.

Please give the changes a try and provide feedback before I release another PL/R version. You can grab the new code from github and sign up for the PL/R mailing list to post your results or report any questions/problems. And of course visit the PL/R homepage and PL/R wiki for more general information about PL/R -- particularly to watch for these changes in the next official release. Finally, don't hesitate to contact me directly if the other choices don't suit you for some reason.