Performance issues on Windows, suggests a MSVC build

classic Classic list List threaded Threaded
67 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Performance issues on Windows, suggests a MSVC build

Ole Jacob Hagen
Hi,

I am using Octave for all my scientific work.
But I have also faced some problems regarding performance in file loading.

I have data files, that are 500 - 1000 MB in size, with 133 columns of data.

I am loading a log file (500 MB) and then creating up to 10 plots of them.
Here is the performance:

* Linux: File loading + plotting: 3 minutes

* Windows XP(MinGw): File loading + plotting: 30-40 minutes.

File loading operation eg data = load('myoversizedlogfile.txt') is using 80-90% of total time. 

Can a pure MSVC build increase performance of data files with that size, or is Octave purely meant for people who has never created a proper log file? <jokingly> ;-)

I've read some discussion whether to support a MSVC build, or at least keep it compilable.
But the VC runtime library license  was conflicting with GPL....as I understood it.

Why does other GPL software on Windows ships VC run time library with their GPL'ed software?

------------------------------------------------------------------------------------------------------------------------------------------
From GPL FAQ: http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL :

I'm writing a Windows application with Microsoft Visual C++ (or Visual Basic) and I will be releasing it under the GPL. Is dynamically linking my program with the Visual C++ (or Visual Basic) run-time library permitted under the GPL?

The GPL permits this because that run-time library normally accompanies the compiler or interpreter you are using. The run-time libraries here are “System Libraries” as GPLv3 defines them, and as such they are not considered part of the Corresponding Source. GPLv2 has a similar exception in section 3.

That doesn't mean it is a good idea to write the program so that it only runs on Windows. Doing so results in a program that is free software but “trapped” by Windows.

------------------------------------------------------------------------------------------------------------------------------------------

Since Octave is supported on all platforms, it is therefore not "trapped" by any Operating System, is it?


Cheers,

Ole





Reply | Threaded
Open this post in threaded view
|

Re: Performance issues on Windows, suggests a MSVC build

Michael Goffioul
On Wed, Jun 22, 2011 at 11:47 AM, Ole Jacob Hagen
<[hidden email]> wrote:

> * Linux: File loading + plotting: 3 minutes
>
> * Windows XP(MinGw): File loading + plotting: 30-40 minutes.
>
> File loading operation eg data = load('myoversizedlogfile.txt') is using
> 80-90% of total time.
>
> Can a pure MSVC build increase performance of data files with that size, or
> is Octave purely meant for people who has never created a proper log file?
> <jokingly> ;-)

I may be wrong, but I don't think using MSVC will make a big difference.
Basically, MinGW is using the same runtime libs as VC++ [1].
Do you use the same hardware in Linux and Windows cases?

> I've read some discussion whether to support a MSVC build, or at least keep
> it compilable.
> But the VC runtime library license  was conflicting with GPL....as I
> understood it.
>
> Why does other GPL software on Windows ships VC run time library with their
> GPL'ed software?

At the time the issue was raised, the GPL FAQ entry you mention didn't exist
and the situation was unclear. One CLN/GiNaC developer claimed I was violating
GPL by distributing MSVC-compiled binaries, as the VC++ runtime libs didn't
qualify as system libs. The situation has been now clarified. However it only
concerns the linking issue. Shipping VC++ runtime libs is another story and
the MS license most probably prevents you from doing it (at least when not using
a commercial version of VC++).

In the end, that episode, plus the constant "get yourself a better
compiler" answer
I got when reporting compilation issues with MSVC, just removed all
the fun I had
in providing MSVC binaries for octave. So I dropped the whole stuff
and continued
to support MSVC just for myself.

> Since Octave is supported on all platforms, it is therefore not "trapped" by
> any Operating System, is it?

Octave is a GNU project, and as such, is dedicated to be compiled with GNU
compiler and run on a GNU operating system. It may run on other platforms and
be compiled with other compilers, but this is not a target.

Michael.

[1] This is not entirely true, as from MSVC9 (aka Visual Studio 2008), the VC++
runtime libs are not linked anymore to MSVCRT.DLL, which is used by MinGW.
Maybe one day, MS will stop shipping and linking to MSVCRT.DLL, such that
it won't qualify as a system lib anymore. That can be funny...
Reply | Threaded
Open this post in threaded view
|

Re: Performance issues on Windows, suggests a MSVC build

bpabbott
Administrator
On Jun 22, 2011, at 8:17 AM, Michael Goffioul wrote:

> In the end, that episode, plus the constant "get yourself a better
> compiler" answer I got when reporting compilation issues with
> MSVC, just removed all the fun I had in providing MSVC
> binaries for octave. So I dropped the whole stuff and continued
> to support MSVC just for myself.

Very unfortunate. I also find judgmental busy-bodies to be annoying, and demotivating.

I expect that Octave has more to gain from Windows and MacOS users than there are liabilities, and am troubled by the decreased support for Windows and rumored changes to development on MacOS (clang and such) which may make using gcc more difficult.

Ben
Reply | Threaded
Open this post in threaded view
|

Re: Performance issues on Windows, suggests a MSVC build

Jordi Gutiérrez Hermoso-2
In reply to this post by Michael Goffioul
On 22 June 2011 07:17, Michael Goffioul <[hidden email]> wrote:
> On Wed, Jun 22, 2011 at 11:47 AM, Ole Jacob Hagen
> <[hidden email]> wrote:
>> * Linux: File loading + plotting: 3 minutes
>>
>> * Windows XP(MinGw): File loading + plotting: 30-40 minutes.
>>
>> File loading operation eg data = load('myoversizedlogfile.txt') is
>> using 80-90% of total time.

Does your log file have information about its size near the top that
Octave can use? That can speed things up, because otherwise Octave
does two passes through your whole file in order to read it.
Optimising the load() function for text data has been a longtime goal
of mine. Perhaps I will try again now.

>> I've read some discussion whether to support a MSVC build, or at
>> least keep it compilable. But the VC runtime library license  was
>> conflicting with GPL....as I understood it.
>>
>> Why does other GPL software on Windows ships VC run time library
>> with their GPL'ed software?
>
> At the time the issue was raised, the GPL FAQ entry you mention
> didn't exist and the situation was unclear. One CLN/GiNaC developer
> claimed I was violating GPL by distributing MSVC-compiled binaries,
> as the VC++ runtime libs didn't qualify as system libs. The
> situation has been now clarified. However it only concerns the
> linking issue. Shipping VC++ runtime libs is another story and the
> MS license most probably prevents you from doing it (at least when
> not using a commercial version of VC++).

I don't understand this. Are you suggesting that any binary compiled
with VC++ would need to distribute the VC++ runtime and this is
forbidden by VC++'s license?

> In the end, that episode, plus the constant "get yourself a better
> compiler" answer I got when reporting compilation issues with MSVC,
> just removed all the fun I had in providing MSVC binaries for
> octave. So I dropped the whole stuff and continued to support MSVC
> just for myself.

Since you're still compiling with MSVC, what issues are you running
into? We stick fairly close to the ISO C++ standard in general, don't
we? Are we relying too much on GNU extensions that gcc uses?

- Jordi G. H.
Reply | Threaded
Open this post in threaded view
|

Re: Performance issues on Windows, suggests a MSVC build

Jordi Gutiérrez Hermoso-2
2011/6/22 Jordi Gutiérrez Hermoso <[hidden email]>:

> On Wed, Jun 22, 2011 at 11:47 AM, Ole Jacob Hagen
> <[hidden email]> wrote:
>> * Linux: File loading + plotting: 3 minutes
>>
>> * Windows XP(MinGw): File loading + plotting: 30-40 minutes.
>>
>> File loading operation eg data = load('myoversizedlogfile.txt') is
> using 80-90% of total time.
>
> Does your log file have information about its size near the top that
> Octave can use?

Another thought: have you verified that your system isn't thrashing on
Windows? It may be unrelated to the Octave build but to memory layout
and segmentation in each operating system.

- Jordi G. H.
Reply | Threaded
Open this post in threaded view
|

Re: Performance issues on Windows, suggests a MSVC build

John W. Eaton
Administrator
In reply to this post by Jordi Gutiérrez Hermoso-2
On 22-Jun-2011, Jordi Gutiérrez Hermoso wrote:

| On 22 June 2011 07:17, Michael Goffioul <[hidden email]> wrote:
| > On Wed, Jun 22, 2011 at 11:47 AM, Ole Jacob Hagen
| > <[hidden email]> wrote:
| >
| >> I've read some discussion whether to support a MSVC build, or at
| >> least keep it compilable. But the VC runtime library license  was
| >> conflicting with GPL....as I understood it.
| >>
| >> Why does other GPL software on Windows ships VC run time library
| >> with their GPL'ed software?
| >
| > At the time the issue was raised, the GPL FAQ entry you mention
| > didn't exist and the situation was unclear. One CLN/GiNaC developer
| > claimed I was violating GPL by distributing MSVC-compiled binaries,
| > as the VC++ runtime libs didn't qualify as system libs. The
| > situation has been now clarified. However it only concerns the
| > linking issue. Shipping VC++ runtime libs is another story and the
| > MS license most probably prevents you from doing it (at least when
| > not using a commercial version of VC++).
|
| I don't understand this. Are you suggesting that any binary compiled
| with VC++ would need to distribute the VC++ runtime and this is
| forbidden by VC++'s license?

The GPL FAQ entry that was quoted in the original message asked about
dynamically linking with the MSVC runtime and apparently that is OK.
As far as I know, that has always been the case.  The issue we were
faced with was whether it was OK to distribute the MSVC libraries along
with the Octave binary for Windows.

At the time this issue came up (January 2007) Octave was licensed
under the terms of the GPLv2, which includes the following clause in
Section 3, which is the section covering distributing executable
programs and which says you must distribute source (or make an offer
to distribute, etc.) and that

  The source code for a work means the preferred form of the work for
  making modifications to it. For an executable work, complete source
  code means all the source code for all modules it contains, plus any
  associated interface definition files, plus the scripts used to
  control compilation and installation of the executable. However, as
  a special exception, the source code distributed need not include
  anything that is normally distributed (in either source or binary
  form) with the major components (compiler, kernel, and so on) of the
  operating system on which the executable runs, unless that component
  itself accompanies the executable.

It's that very last part that was important for us because we were
distributing the MSVC library along with the executable.  I read this
to mean that since the MSVC library accompanied the executable, we
would need to be able to distribute source for it as well.  There was
an email discussion about this here:

  https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2007-January/005435.html

There were also some later discussions about this with some opinions
from the FSF licensing gurus.  For example, read the threads that
start with these messages:

  https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2009-May/015923.html
  https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2009-May/016071.html

jwe
Reply | Threaded
Open this post in threaded view
|

Re: Performance issues on Windows, suggests a MSVC build

John W. Eaton
Administrator
In reply to this post by bpabbott
On 22-Jun-2011, Ben Abbott wrote:

| I expect that Octave has more to gain from Windows and MacOS users
| than there are liabilities,

Can you explain a bit more what you mean?  How do you see more users
being helpful?  I'd say it depends on the users we attract.  Are they
supporting us with funds or code or something, or do they just want
support for free?  If the former, then I say great, but if the latter,
then I don't see how we gain much.

| and am troubled by the decreased support for Windows

We have many Windows users, but not much in the way of Windows
developers.  How can we change this?  If the Windows users want
something to improve, then they need to provide some resources for
that, either by volunteering to do the work, or paying someone to do
the work.  Working on Windows systems makes me want to gag, but I'd be
willing to do it in exchange for $$.

| and rumored changes to development on MacOS (clang and
| such) which may make using gcc monre difficult.

I'm not sure I understand the issues, but Octave is not tied to a
particular compiler.  What prevents either using GCC when it is not
the system compiler (I've done that many times on many different types
of systems in the past) or building Octave with clang?

jwe

Reply | Threaded
Open this post in threaded view
|

Performance issues on Windows, suggests a MSVC build

John W. Eaton
Administrator
In reply to this post by Ole Jacob Hagen
On 22-Jun-2011, Ole Jacob Hagen wrote:

| I am using Octave for all my scientific work.
| But I have also faced some problems regarding performance in file loading.
|
| I have data files, that are 500 - 1000 MB in size, with 133 columns of data.
|
| I am loading a log file (500 MB) and then creating up to 10 plots of them.
| Here is the performance:
|
| * Linux: File loading + plotting: 3 minutes
|
| * Windows XP(MinGw): File loading + plotting: 30-40 minutes.
|
| File loading operation eg data = load('myoversizedlogfile.txt') is using 80-90%
| of total time. 
|
| Can a pure MSVC build increase performance of data files with that size,

Thinking that the problem must be MinGW and that everything would be
fixed if using MSVC seems like jumping to conclusions to me.

As someone else asked, is this on the same hardware?

Even 3 minutes to load a 1GB file seems like a long time to me.  It's
pretty well known that loading text files in Octave is not very
efficient.  It would be great if someone could do some work to
optimize it.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: Performance issues on Windows, suggests a MSVC build

Michael Goffioul
In reply to this post by Jordi Gutiérrez Hermoso-2
2011/6/22 Jordi Gutiérrez Hermoso <[hidden email]>:
> I don't understand this. Are you suggesting that any binary compiled
> with VC++ would need to distribute the VC++ runtime and this is
> forbidden by VC++'s license?

No, you can get VC++ runtime libs for free from the MS download site.

> Since you're still compiling with MSVC, what issues are you running
> into?

Most issues are template-related. Jaroslav has template-ified significant
parts of the code (and I don't question that, that's an impressive job),
but unfortunately this broke compilation under MSVC, because of its
lack of support for the more advanced techniques that were used.
I'm not going to repeat the issues here, you should be able to find
them by searching through the mailing list.

> We stick fairly close to the ISO C++ standard in general, don't
> we? Are we relying too much on GNU extensions that gcc uses?

I didn't say that. The problem is on the MSVC side. But GCC has
a much faster release cycle than MSVC (~ 3 years) and it's also
probably more ISO C++ compliant.

Michael.
Reply | Threaded
Open this post in threaded view
|

Re: Performance issues on Windows, suggests a MSVC build

Michael Goffioul
In reply to this post by John W. Eaton
2011/6/22 John W. Eaton <[hidden email]>:
> The GPL FAQ entry that was quoted in the original message asked about
> dynamically linking with the MSVC runtime and apparently that is OK.
> As far as I know, that has always been the case.  The issue we were
> faced with was whether it was OK to distribute the MSVC libraries along
> with the Octave binary for Windows.

No John, the guy went one step further, claiming that even linking against
the runtime libs was violating the GPL. I only got the FSF clarification
in 2009.

For reference, look here:
http://www.ginac.de/pipermail/cln-list/2009-April/thread.html

But it doesn't matter anymore now.

Michael.
Reply | Threaded
Open this post in threaded view
|

Re: Performance issues on Windows, suggests a MSVC build

Michael Goffioul
On Wed, Jun 22, 2011 at 5:59 PM, Michael Goffioul
<[hidden email]> wrote:

> 2011/6/22 John W. Eaton <[hidden email]>:
>> The GPL FAQ entry that was quoted in the original message asked about
>> dynamically linking with the MSVC runtime and apparently that is OK.
>> As far as I know, that has always been the case.  The issue we were
>> faced with was whether it was OK to distribute the MSVC libraries along
>> with the Octave binary for Windows.
>
> No John, the guy went one step further, claiming that even linking against
> the runtime libs was violating the GPL. I only got the FSF clarification
> in 2009.
>
> For reference, look here:
> http://www.ginac.de/pipermail/cln-list/2009-April/thread.html

And I think that what p....ed me off the most is the fact that the
whole story started because I pointed the GiNaC developers to
errors in their ise of STL code and was proposing a patch.
Nice reward...

Michael.
Reply | Threaded
Open this post in threaded view
|

Re: Performance issues on Windows, suggests a MSVC build

John W. Eaton
Administrator
In reply to this post by Michael Goffioul
On 22-Jun-2011, Michael Goffioul wrote:

| 2011/6/22 John W. Eaton <[hidden email]>:
| > The GPL FAQ entry that was quoted in the original message asked about
| > dynamically linking with the MSVC runtime and apparently that is OK.
| > As far as I know, that has always been the case.  The issue we were
| > faced with was whether it was OK to distribute the MSVC libraries along
| > with the Octave binary for Windows.
|
| No John, the guy went one step further, claiming that even linking against
| the runtime libs was violating the GPL. I only got the FSF clarification
| in 2009.
|
| For reference, look here:
| http://www.ginac.de/pipermail/cln-list/2009-April/thread.html

I don't see where Bruno claimed that simply linking with the MSVC runtime
library was a problem, only that distributing them in the same binary
installer is not allowed by the GPL.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: Performance issues on Windows, suggests a MSVC build

bpabbott
Administrator
In reply to this post by John W. Eaton
On Jun 22, 2011, at 12:24 PM, John W. Eaton wrote:

> On 22-Jun-2011, Ben Abbott wrote:
>
> | I expect that Octave has more to gain from Windows and MacOS users
> | than there are liabilities,
>
> Can you explain a bit more what you mean?  How do you see more users
> being helpful?  I'd say it depends on the users we attract.  Are they
> supporting us with funds or code or something, or do they just want
> support for free?  If the former, then I say great, but if the latter,
> then I don't see how we gain much.

My thought is that more users are better than less. I appreciate the trouble and frustration related to those who expect active support for fee ... very annoying crowd for me.

> | and am troubled by the decreased support for Windows
>
> We have many Windows users, but not much in the way of Windows
> developers.  How can we change this?  If the Windows users want
> something to improve, then they need to provide some resources for
> that, either by volunteering to do the work, or paying someone to do
> the work.  Working on Windows systems makes me want to gag, but I'd be
> willing to do it in exchange for $$.

Agreed. Windows looks like a large opportunity, but I don't have any ideas how to tap into it.

> | and rumored changes to development on MacOS (clang and
> | such) which may make using gcc monre difficult.
>
> I'm not sure I understand the issues, but Octave is not tied to a
> particular compiler.  What prevents either using GCC when it is not
> the system compiler (I've done that many times on many different types
> of systems in the past) or building Octave with clang?

My concern is that MacOS may end up like Windows. Meaning that OS's libraries and development tools aren't particularly useful. The result may be a smaller number of Octave developers on MacOS, and an apparent (or real) increase in those who expect support for free.

Personally, I'm expecting to move to Linux full time once I'm able to use gadgets like iPods, iPhone, iPads & such without the need to lock them to a computer.

In any event, perhaps my concerns are pointless, since I have no constructive ideas for improving the situation.

Ben
Reply | Threaded
Open this post in threaded view
|

Re: Performance issues on Windows, suggests a MSVC build

Michael Goffioul
In reply to this post by John W. Eaton
On Wed, Jun 22, 2011 at 6:13 PM, John W. Eaton <[hidden email]> wrote:
> I don't see where Bruno claimed that simply linking with the MSVC runtime
> library was a problem, only that distributing them in the same binary
> installer is not allowed by the GPL.

Indeed, you're right. My apologies.
Doesn't change much to the end result, though.

Michael.
Reply | Threaded
Open this post in threaded view
|

Re: Performance issues on Windows, suggests a MSVC build

John W. Eaton
Administrator
On 22-Jun-2011, Michael Goffioul wrote:

| Indeed, you're right. My apologies.
| Doesn't change much to the end result, though.

OK, but from reading the FAQ entry, we are apparently allowed to
distribute Octave compiled with MSVC and linked with MSVC runtime
libraries.  We just can't distribute the runtime library along with
Octave.  As I recall, you objected to that on technical grounds
because it would be somewhat silly and inconvenient, and many (if not
most) users would probably encounter problems.  I might also object on
the grounds that it is an instance of telling the user to perform the
link to a proprietary library, and for other cases we argue that doing
that is no way to sidestep the terms of the GPL, so it will be
confusing if we allow it in this case but not others.  The difference
is that the MSVC runtime library is considered a "System Component"
and so gets special treatment, but it will likely still cause some
confusion.  And for me, there is also the issue of wanting to promote
free software, not proprietary software.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Performance issues on Windows, suggests a MSVC build

forkandwait
In reply to this post by bpabbott
Ben Abbott <bpabbott <at> mac.com> writes:

> My thought is that more users are better than less. I appreciate the trouble
and frustration related to
> those who expect active support for fee ... very annoying crowd for me.

When you say "expect active support for free" what do you mean?  Is this asking
silly questions on the newsgroup?  Nothing particularly wrong with that, since
you can just (1) blow them off or (2) give them a lecture about how to behave in
a FOSS environment and (3) sort of reasonable questions build a knowledge base.  

If you want to get them to pay for asking silly questions, then formalize the
system (put your credit card number here, get an ID number there, and that gives
you 10 stupid questions per year, etc).

> > We have many Windows users, but not much in the way of Windows
> > developers.  How can we change this?  If the Windows users want
> > something to improve, then they need to provide some resources for
> > that, either by volunteering to do the work, or paying someone to do
> > the work.  Working on Windows systems makes me want to gag, but I'd be
> > willing to do it in exchange for $$.

Couple of thoughts --

(1) I bet there is a "conversion rate" at which a user becomes a contributor for
open source software.  My guess is 1/1000 per year (probably an over-hopeful
number really), though I have no data whatsoever.  If I am right, this is why it
is important to get a lot of windows users to just use first, so that the 1/1000
who can actually develop will start pitching in.  Otherwise, this 1/1000 will
never hear of you at all.  

(2) As I have said before, if I could find a link that would take my office VISA
card and spit out an invoice, a supported-user-id-number, and the latest binary
for $100.00, I would happily make that happen.  But until there is an easy path
for spending said $$, I can't do it.  And likely there is no single windows user
who is big enough to fund your time completely, so you have to make it easy to
fund it in incremental payments like this.

(Disclaimer: I have neither the time nor the ability nor the inclination to
develop Octave for Windows.  I would be interested in working on a "business
plan" for the above ideas if there is interest.)

Reply | Threaded
Open this post in threaded view
|

Re: Performance issues on Windows, suggests a MSVC build

Ole Jacob Hagen
In reply to this post by Michael Goffioul
Hi,

Michael; Is it possible to get a MSVC build of the newest Octave + Octave-forge packages?
Or at least the setup and all that...Then I can compile it myself. ;-)

Regarding performance on function load.
 
Hardware were not significantly different. The log files were just column based data sets, with sampling time 100 Hz and logged for 1 hours.
I am working in the modelling and simulation industry (read: Serious Games).

The limit however was above  approx 1.1 GB for the 32 bit version. Windows didn't manage to load that large files, but Linux did.
I suspect some wrapper functionality in MinGW could cause the slow-down from 2-3 minutes on Linux to 30 minutes on Windows-XP.. All systems were 32 bit.

I can test loading afterwards, just to see. ;-) When I got half an hour to spare...;-)

Best regards,

Ole



Reply | Threaded
Open this post in threaded view
|

Re: Performance issues on Windows, suggests a MSVC build

bpabbott
Administrator
In reply to this post by forkandwait
On Jun 22, 2011, at 3:53 PM, fork wrote:

> Ben Abbott <bpabbott <at> mac.com> writes:
>
>> My thought is that more users are better than less. I appreciate the trouble
>> and frustration related to those who expect active support for fee ... very
>> annoying crowd for me.
>
> When you say "expect active support for free" what do you mean?  Is this asking
> silly questions on the newsgroup?

Nothing like that. I was thinking of those who make demands, as if the
development community is waiting with baited breath for them to call us into
action. It doesn't happen very often, but when it does, it is becomes less than
motivating to offer help.

On the positive side, I noticed a windows user has just asked a question about
building Octave using VC 2008.

We certainly could use more windows developers here.

Ben
Reply | Threaded
Open this post in threaded view
|

Re: Performance issues on Windows, suggests a MSVC build

John W. Eaton
Administrator
In reply to this post by forkandwait
On 22-Jun-2011, fork wrote:

| (1) I bet there is a "conversion rate" at which a user becomes a
| contributor for open source software.  My guess is 1/1000 per year
| (probably an over-hopeful number really),
| whatsoever.  If I am right, this is why it is important to get a lot
| of windows users to just use first, so that the 1/1000 who can
| actually develop will start pitching in.  Otherwise, this 1/1000
| will never hear of you at all.

So we (who are not very interested or knowledgeable about Windows)
have to develop and distribute a simple to install Windows binary so
that we can get contributors to help us with Windows?  Don't we
already have that with the 3.2.4 release that is on source forge?
That's been downloaded more than 300,000 times since March 2010.  So
shouldn't we have something like 300 Windows developers by now?

I remain unconvinced that there are many people out there who are
competent Windows programmers who are also interested in developing
free numerical software.  My guess would be that most everyone who is
interested in developing free software as a volunteer has abandoned
Windows.  I'm OK with being wrong about this, but we already have a
Windows binary that should be sufficient to get competent programmers
started and it has been downloaded a fairly large number of times, yet
I'm still waiting to see the Windows programmers contributing.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: Performance issues on Windows, suggests a MSVC build

forkandwait
John W. Eaton <jwe <at> octave.org> writes:

>
> On 22-Jun-2011, fork wrote:
>
> | (1) I bet there is a "conversion rate" at which a user becomes a
> | contributor for open source software.  My guess is 1/1000 per year
> | (probably an over-hopeful number really),
> | whatsoever.  If I am right, this is why it is important to get a lot
> | of windows users to just use first, so that the 1/1000 who can
> | actually develop will start pitching in.  Otherwise, this 1/1000
> | will never hear of you at all.
>
> So we (who are not very interested or knowledgeable about Windows)
> have to develop and distribute a simple to install Windows binary so
> that we can get contributors to help us with Windows?

Yes (I say as an interested but ignorant party).  I think the bigger problem is
that the build process on windows is not maintained directly and is a mess.
Personal experience:  If I could jump in and make incremental changes to the
windows version and build system, I would, just as I would help fund development
incrementally if I could.  However, my guess is that there is about 80 hours
between now and my first compile, and I don't have that time or expertise, just
like I don't have thousands of dollars to pay for you or someone smarter than me
to hack at an unpleasant task for the 40 hours it needs.

>  Don't we
> already have that with the 3.2.4 release that is on source forge?

We have a binary that was hacked together once in an unreproducable environment
(I mean that with nothing but respect for the people who put it together, just
in terms of continuous improvement and introspection).  It also smells of
neglect given the recent 3.4.2rc1, which will turn people off.

> That's been downloaded more than 300,000 times since March 2010.

Wow.

> So
> shouldn't we have something like 300 Windows developers by now?

Ok, let me modify my conversion rate to 1/500,000 ;)  We are just about to get
the first one -- I can feel it!

> I remain unconvinced that there are many people out there who are
> competent Windows programmers who are also interested in developing
> free numerical software.  My guess would be that most everyone who is
> interested in developing free software as a volunteer has abandoned
> Windows.  I'm OK with being wrong about this, but we already have a
> Windows binary that should be sufficient to get competent programmers
> started and it has been downloaded a fairly large number of times, yet
> I'm still waiting to see the Windows programmers contributing.

I think there may be a lot of folks like me:  I would never volunteer to do
anything on windows ever unless there were a payoff, (yuck!), but I work for pay
in a windows environment and would like to make that is un-painful as possible
(and run the same simulation code on all three big OS'es).  If I could
contribute incrementally to effect that, I would, but the stable build system
isn't there yet.
 
Let me stress that one can't make incremental improvements to the windows
version as it stands, which may be a block to others besides myself.

I wish I had a solution, really, that didn't involve other people working really
hard on something I don't understand.  Sorry....

> jwe

1234