linux/windows development scenario

[John Eric Hanson]

My company is considering a development path in which we develop code on 32
bit Windows machines to run remotely on 64 bit Linux machines.

What could go wrong?

[Ruediger Knoerig]

Re: linux/windows development scenario

John Eric Hanson wrote:
[color=blue]
> My company is considering a development path in which we develop code on
> 32 bit Windows machines to run remotely on 64 bit Linux machines.
>
> What could go wrong?[/color]
If you use a good X terminal for windows - not much.

[Phlip]

Re: linux/windows development scenario

John Eric Hanson wrote:
[color=blue]
> My company is considering a development path in which we develop code on[/color]
32[color=blue]
> bit Windows machines to run remotely on 64 bit Linux machines.
>
> What could go wrong?[/color]

I'd go Cygwin -> X terminals -> Ruby -> Tk

Why C++?

If the answer is speed, I'd write C++-style Ruby, and then profile to see
which modules are the bottlenecks. Then I'd re-write them to use lazy or
early evaluation, extra data stashes, different algorithms, etc.

Then, after exhausting a search for different algorithms, I'd convert the
fastest ones from Ruby into C++ objects bound to Ruby.

But if you don't need speed, you don't need any of that.

--
Phlip

http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces

[Alf P. Steinbach]

Re: linux/windows development scenario

On Fri, 13 Feb 2004 16:01:34 GMT, "John Eric Hanson" <eric@newyorklo gic.com> wrote:
[color=blue]
>My company is considering a development path in which we develop code on 32
>bit Windows machines to run remotely on 64 bit Linux machines.
>
>What could go wrong?[/color]

Everything, but mostly you will always break the deadlines and deliver an
inferior product. Best advice is to fire the management. But, difficult.

Btw., you're way off-topic in comp.lang.c++.

This answer crossposted to comp.programmin g with follow-up to comp.programmin g.

[John Eric Hanson]

Re: linux/windows development scenario

The code is already written in C++ and is run in both Windows and Linux.
Speed is important.

Going forward we are considering continuing development in Windows, but
running on remote, 64 bit Linux machines. The program when run in
'production mode' (on large datasets) may exceed the 1 to 2MB of RAM
available on the development machines as well so complete testing need to be
done remotely. We don't expect any issues from scaling up though as data
subsets are analogous to the whole.

We do have a large number of 32 bit NT, XP and Linux machines that will
continue to be running lower priority code, both existing and new, so the
scenario is one in which there may be possible drawbacks in migrating the
development platform to 64 bit as well. I'm simply trying to evaluate which
scenario is likely to be more problematic: Windows development in a 32 bit
environment for deployment on 64 bit Linux system or Windows development in
a 64 bit environment for deployment on both 32 and 64 bit, Windows and Linux
environments.

Thanks again,

Eric


"Phlip" <phlip_cpp@yaho o.com> wrote in message
news:6F6Xb.2092 5$4B7.7838@news svr16.news.prod igy.com...[color=blue]
> John Eric Hanson wrote:
>[color=green]
> > My company is considering a development path in which we develop code on[/color]
> 32[color=green]
> > bit Windows machines to run remotely on 64 bit Linux machines.
> >
> > What could go wrong?[/color]
>
> I'd go Cygwin -> X terminals -> Ruby -> Tk
>
> Why C++?
>
> If the answer is speed, I'd write C++-style Ruby, and then profile to see
> which modules are the bottlenecks. Then I'd re-write them to use lazy or
> early evaluation, extra data stashes, different algorithms, etc.
>
> Then, after exhausting a search for different algorithms, I'd convert the
> fastest ones from Ruby into C++ objects bound to Ruby.
>
> But if you don't need speed, you don't need any of that.
>
> --
> Phlip
> http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces
>
>[/color]

[Chris Mantoulidis]

Re: linux/windows development scenario

"John Eric Hanson" <eric@newyorklo gic.com> wrote in message news:<yx6Xb.565 19$n62.31136@tw ister.nyroc.rr. com>...[color=blue]
> My company is considering a development path in which we develop code on 32
> bit Windows machines to run remotely on 64 bit Linux machines.
>
> What could go wrong?[/color]

I don't know what could go wrong but there may be some slight bugs;
they can as well not be :)

BTW: Why do you want to have a 64bit Linux? What's wrong with the good
ol'32bit?

[Ian]

Re: linux/windows development scenario

John Eric Hanson wrote:[color=blue]
> My company is considering a development path in which we develop code on 32
> bit Windows machines to run remotely on 64 bit Linux machines.
>
> What could go wrong?
>[/color]
A windows virus :)

Why not just develop on Linux?

Ian

[John Eric Hanson]

Re: linux/windows development scenario


"Chris Mantoulidis" <cmad_x@yahoo.c om> wrote in message
news:a8587dd9.0 402131144.37272 1e4@posting.goo gle.com...[color=blue]
> "John Eric Hanson" <eric@newyorklo gic.com> wrote in message[/color]
news:<yx6Xb.565 19$n62.31136@tw ister.nyroc.rr. com>...[color=blue][color=green]
> > My company is considering a development path in which we develop code on[/color][/color]
32[color=blue][color=green]
> > bit Windows machines to run remotely on 64 bit Linux machines.
> >
> > What could go wrong?[/color]
>
> I don't know what could go wrong but there may be some slight bugs;
> they can as well not be :)
>
> BTW: Why do you want to have a 64bit Linux? What's wrong with the good
> ol'32bit?[/color]

The general consensus among us is that we'd experience performance gains in
both operations on doubles and in having more RAM easily accessible. We
will verify this in practice first, but the short of it is we are expecting
some performance gains with the 64 bit chips.

Our current concern is in ameliorating any possible issues that might be
involved in the development environment. Particularly as they involve the
platform and tools we currently use (Visual C++ on XP machines).

[Chris Mantoulidis]

Re: linux/windows development scenario

> The general consensus among us is that we'd experience performance gains in[color=blue]
> both operations on doubles and in having more RAM easily accessible. We
> will verify this in practice first, but the short of it is we are expecting
> some performance gains with the 64 bit chips.[/color]

Yeah there will be some extra performance...
[color=blue]
> Our current concern is in ameliorating any possible issues that might be
> involved in the development environment. Particularly as they involve the
> platform and tools we currently use (Visual C++ on XP machines).[/color]

Let me get this straight. From what you've said till now, you are
writting C++ on 32 bit Windows that you want to run under 64bit Linux?
If you want to make a program just for Linux, then MAKE it in Linux as
well. But if you want to use that code for Win32 and Linux 32bit as
well and Linux 64 bit, here's a suggestion:

Make the program in Windows, compile it and you got your Win32 program
Copy the code to Linux (32bit) make the appropriate changes (e.g. some
API calls) and compile it and you got your Linux 32bit code.
For a 64bit code, you'd want a 64bit compiler. I don't know if there
are any, so you better search. If you find one do what you did
earlier.

However, the 64bit code MAY have some bugs if you run it on a 32bit
PC. So I suggest you don't do that. 32bit code runs fine on 64bit PCs.

It's your call though ;)

BTW: This is kind of off topic in comp.lang.c++ . You'd be better off
in some other newsgroup (e.g. linux newsgroup or w/e else)

cmad

[Bob Hairgrove]

Re: linux/windows development scenario

On 13 Feb 2004 22:52:58 -0800, cmad_x@yahoo.co m (Chris Mantoulidis)
wrote:
[color=blue]
>For a 64bit code, you'd want a 64bit compiler. I don't know if there
>are any, so you better search. If you find one do what you did
>earlier.[/color]

The Intel compiler, AFAIK, can generate either 32 bit or 64 bit code.
Also, there are Windows and Linux versions of this compiler, so I
think it would be a logical choice.

I'm assuming that the program will need to run on 64-bit Intel
machines ...


--
Bob Hairgrove
NoSpamPlease@Ho me.com