Re: Question about Maxim and multi core processors


Feb 4 9:54 AM

 


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

#48357 Feb 4 9:54 AM

Hi



I have a question about Maxim when used with multi core processors: will it take full advantage of the four cores of a Windows 7 64 bit machine with an i3 processor, or will it use just some of them?



Thanks for your help



Alfredo



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

#48365 Feb 5 8:12 AM

Good Morning Alfredo;



I asked this question to Defraction Limited some months back.

There response was, MaximDL v5.xx would work properly on an i7-950 (64 bit-8 thread) platform just fine, but MaximDL would not utilize the additional processors. MDL is not optimized for x64. MDL will work on both the x32 or x64 platforms. In your root directory of your Windows 7 x64 computer are two directorys for programs; "Program Files" (for x64 programs) and "Program Files (x86)" (for x32 programs).



On the other hand, I have the x64 version of PhotoShop and its performance is enhanced with the multiple processors. Also the latest version of PixInsight is also optimized for multiple processors. Both of these x64 optimized programs are noticable faster than there 32 bit counter parts.



Hopefully, DL will become x64 enabled in there next major release, whenever that will be.



clear skies; Phillip Marshall

--- In MaxImDL@yahoogroups.com, Alfredo Beltr..n albeltrang73@...> wrote:

>

> Hi

>

> I have a question about Maxim when used with multi core processors: will it take full advantage of the four cores of a Windows 7 64 bit machine with an i3 processor, or will it use just some of them?

>

> Thanks for your help

>

> Alfredo

>



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

#48367 Feb 5 9:38 AM

There are really two different questions here, I think. First, Maxim will not use multiple processors AFAIK under any circumstances. I also think that it will not take advantage of a 64bit processor (in the sense of using full memory and 64 bit arithmetic) as well. Changing either restriction would lead to better performance, I would think. If you know differently, please comment.







Rgrds-Ross







From: MaxImDL@yahoogroups.com [mailto:MaxImDL@yahoogroups.com] On Behalf Of Alfredo Beltr.n

Sent: Sunday, February 05, 2012 8:53 AM

To: MaxImDL@yahoogroups.com

Subject: Re: [MaxImDL] Re: Question about Maxim and multi core processors











Thank you Phillip I thought that would be the answer.



Best regards



Alfredo



El 5/02/2012, a las 11:12, "PhillipM" pmarshall7@... mailto:pmarshall7%40cox.net> > escribi.:

> Good Morning Alfredo;

>

> I asked this question to Defraction Limited some months back.

> There response was, MaximDL v5.xx would work properly on an i7-950 (64 bit-8 thread) platform just fine, but MaximDL would not utilize the additional processors. MDL is not optimized for x64. MDL will work on both the x32 or x64 platforms. In your root directory of your Windows 7 x64 computer are two directorys for programs; "Program Files" (for x64 programs) and "Program Files (x86)" (for x32 programs).

>

> On the other hand, I have the x64 version of PhotoShop and its performance is enhanced with the multiple processors. Also the latest version of PixInsight is also optimized for multiple processors. Both of these x64 optimized programs are noticable faster than there 32 bit counter parts.

>

> Hopefully, DL will become x64 enabled in there next major release, whenever that will be.

>

> clear skies; Phillip Marshall

>

> --- In MaxImDL@yahoogroups.com mailto:MaxImDL%40yahoogroups.com> , Alfredo Beltr..n albeltrang73@...> wrote:

> >

> > Hi

> >

> > I have a question about Maxim when used with multi core processors: will it take full advantage of the four cores of a Windows 7 64 bit machine with an i3 processor, or will it use just some of them?

> >

> > Thanks for your help

> >

> > Alfredo

> >

>

>



[Non-text portions of this message have been removed]











[Non-text portions of this message have been removed]



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

#48368 Feb 5 12:43 PM

--- In MaxImDL@yahoogroups.com, Ross Salinger rgsalinger@...> wrote: >

> First, Maxim will not use multiple processors AFAIK under any circumstances.



Maxim might be using multiple processors without knowing it. What Maxim is not using is the Microsoft Parallel Programming Library first shipped with Visual Studio 2005. The Parallel Programming Library requires major rewrite of all image processing algorithms in Maxim. To be fair to Maxim, most developers (%99.99) have no clue about parallel programming. Parallel programming is quite different from mufti-threaded programming that Maxim might already be doing.



-Adam



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

#48369 Feb 5 2:15 PM

Well, I run this little monitor piece of software showing all 6 of my

processors and I never see maxim use more than one of them.







From: MaxImDL@yahoogroups.com [mailto:MaxImDL@yahoogroups.com] On Behalf Of

malanalan

Sent: Sunday, February 05, 2012 12:44 PM

To: MaxImDL@yahoogroups.com

Subject: [MaxImDL] Re: Question about Maxim and multi core processors















--- In MaxImDL@yahoogroups.com mailto:MaxImDL%40yahoogroups.com> , Ross

Salinger rgsalinger@...> wrote: >

> First, Maxim will not use multiple processors AFAIK under any

circumstances.



Maxim might be using multiple processors without knowing it. What Maxim is

not using is the Microsoft Parallel Programming Library first shipped with

Visual Studio 2005. The Parallel Programming Library requires major rewrite

of all image processing algorithms in Maxim. To be fair to Maxim, most

developers (%99.99) have no clue about parallel programming. Parallel

programming is quite different from mufti-threaded programming that Maxim

might already be doing.



-Adam











[Non-text portions of this message have been removed]







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

#48370 Feb 5 2:55 PM

Ross, I think you may have a misunderstanding in the difference between multi-threading, multi-processing, and parallel programming. With out going into the differences between multi-processor/ multi-core and hyper threading let me see If I can explain multi-processing deals witht he ability to execute units of work. the more processors you have the more units of work you can execute at one time.en.wikipedia.org/wiki/Multiprocessing muti-threading - in an application threads are the units of execution that actually do the work these thread are what are scheduled by the Operatign System to on individual processors. Multi-threading is the practice of using multiple threads to accomplish individual tasks. This has to be done explicitly by the programmer.en.wikipedia.org/wiki/Thread_(computer_science)#Multithreading parallel programing is a programming model that is build ont he concept that large problem sets that can be broken into speperate calculations that can run in parallel. This requires a special library to deal with the complexities.

en.wikipedia.org/wiki/Parallel_programming So in order for Maxim to take advantage of multiple processors it must be written as a multi threaded program. Multi-threading is a complex process that often introduces more risk than benifits gained. I would be willing to bet based on the evidence of workign in Maxim (program stops respondign when you execute a task such as image stacking until it is done) that it is not written to take advantage of multiple processors. ChrisTo: MaxImDL@yahoogroups.com

From: rgsalinger@...

Date: Sun, 5 Feb 2012 14:15:37 -0800

Subject: RE: [MaxImDL] Re: Question about Maxim and multi core processors

























































Well, I run this little monitor piece of software showing all 6 of my



processors and I never see maxim use more than one of them.







From: MaxImDL@yahoogroups.com [mailto:MaxImDL@yahoogroups.com] On Behalf Of



malanalan



Sent: Sunday, February 05, 2012 12:44 PM



To: MaxImDL@yahoogroups.com



Subject: [MaxImDL] Re: Question about Maxim and multi core processors







--- In MaxImDL@yahoogroups.com mailto:MaxImDL%40yahoogroups.com> , Ross



Salinger rgsalinger@...> wrote:

>



> First, Maxim will not use multiple processors AFAIK under any



circumstances.







Maxim might be using multiple processors without knowing it. What Maxim is



not using is the Microsoft Parallel Programming Library first shipped with



Visual Studio 2005. The Parallel Programming Library requires major rewrite



of all image processing algorithms in Maxim. To be fair to Maxim, most



developers (%99.99) have no clue about parallel programming. Parallel



programming is quite different from mufti-threaded programming that Maxim



might already be doing.







-Adam







[Non-text portions of this message have been removed]





































[Non-text portions of this message have been removed]



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

#48371 Feb 5 9:00 PM

Thanks, but I think that you're just agreeing with me. Maxim uses only one

processor, correct?

BTW I wrote my first program in 1961.

Rgrds-Ross



-----Original Message-----

From: MaxImDL@yahoogroups.com [mailto:MaxImDL@yahoogroups.com] On Behalf Of

Chris Norman

Sent: Sunday, February 05, 2012 2:55 PM

To: maximdl@yahoogroups.com

Subject: RE: [MaxImDL] Re: Question about Maxim and multi core processors





Ross, I think you may have a misunderstanding in the difference between

multi-threading, multi-processing, and parallel programming. With out going

into the differences between multi-processor/ multi-core and hyper threading

let me see If I can explain multi-processing deals witht he ability to

execute units of work. the more processors you have the more units of work

you can execute at one time.en.wikipedia.org/wiki/Multiprocessing

muti-threading - in an application threads are the units of execution that

actually do the work these thread are what are scheduled by the Operatign

System to on individual processors. Multi-threading is the practice of using

multiple threads to accomplish individual tasks. This has to be done

explicitly by the

programmer.en.wikipedia.org/wiki/Thread_(computer_science)#Multithrea

ding parallel programing is a programming model that is build ont he concept

that large problem sets that can be broken into speperate calculations that

can run in parallel. This requires a special library to deal with the

complexities.

en.wikipedia.org/wiki/Parallel_programming So in order for Maxim to

take advantage of multiple processors it must be written as a multi threaded

program. Multi-threading is a complex process that often introduces more

risk than benifits gained. I would be willing to bet based on the evidence

of workign in Maxim (program stops respondign when you execute a task such

as image stacking until it is done) that it is not written to take advantage

of multiple processors. ChrisTo: MaxImDL@yahoogroups.com

From: rgsalinger@...

Date: Sun, 5 Feb 2012 14:15:37 -0800

Subject: RE: [MaxImDL] Re: Question about Maxim and multi core processors

























































Well, I run this little monitor piece of software showing all 6 of my



processors and I never see maxim use more than one of them.







From: MaxImDL@yahoogroups.com [mailto:MaxImDL@yahoogroups.com] On Behalf Of



malanalan



Sent: Sunday, February 05, 2012 12:44 PM



To: MaxImDL@yahoogroups.com



Subject: [MaxImDL] Re: Question about Maxim and multi core processors







--- In MaxImDL@yahoogroups.com mailto:MaxImDL%40yahoogroups.com> , Ross



Salinger rgsalinger@...> wrote:

>



> First, Maxim will not use multiple processors AFAIK under any



circumstances.







Maxim might be using multiple processors without knowing it. What Maxim is



not using is the Microsoft Parallel Programming Library first shipped with



Visual Studio 2005. The Parallel Programming Library requires major rewrite



of all image processing algorithms in Maxim. To be fair to Maxim, most



developers (%99.99) have no clue about parallel programming. Parallel



programming is quite different from mufti-threaded programming that Maxim



might already be doing.







-Adam







[Non-text portions of this message have been removed]





































[Non-text portions of this message have been removed]







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



Yahoo! Groups Links







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

#48380 Feb 7 8:35 AM

On 2012-02-05 12:38 PM, Ross Salinger wrote: > There are really two different questions here, I think. First, Maxim will

> not use multiple processors AFAIK under any circumstances.



That is not correct; at this point threading is used in some areas and not

others. You can expect more functions to incorporate threading in upcoming

releases. We are doing this gradually to avoid introducing bugs.

> I also think that it will not take advantage of a 64bit processor (in the

> sense of using full memory and 64 bit arithmetic) as well.



You are correct, we currently do not have a 64-bit version of the program. That

is a more major transition and will take a bit more time.



(A bit of history... one of the major events that instigated the original

launch of MaxIm DL was the 16-bit to 32-bit transition, circa 1995, which

really made home computer image processing practical for the first time.

MaxIm DL development started in 1996 and V1.0 launched in 1997.)



Doug



--



Doug George

dgeorge@...



Diffraction Limited

Makers of Cyanogen Imaging Products

www.cyanogen.com/



100 Craig Henry Dr., Suite 202

Ottawa, Ontario,

Canada, K2G 5W3



Phone: (613) 225-2732

Fax: (613) 225-9688



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

#48393 Feb 8 2:42 AM

On 2012-02-05 12:38 PM, Ross Salinger wrote:

>> There are really two different questions here, I think. First, Maxim will

>> not use multiple processors AFAIK under any circumstances.

> That is not correct; at this point threading is used in some areas and not

> others. You can expect more functions to incorporate threading in upcoming

> releases. We are doing this gradually to avoid introducing bugs.

>

>> I also think that it will not take advantage of a 64bit processor (in the

>> sense of using full memory and 64 bit arithmetic) as well.

> You are correct, we currently do not have a 64-bit version of the program. That

> is a more major transition and will take a bit more time.

>

> (A bit of history... one of the major events that instigated the original

> launch of MaxIm DL was the 16-bit to 32-bit transition, circa 1995, which

> really made home computer image processing practical for the first time.

> MaxIm DL development started in 1996 and V1.0 launched in 1997.)

>

> Doug

It is worth pointing out to people who perhaps "don't realise this",

that on most modern processors, if you are only using a few threads, the

chip will effectively 'overclock' itself on the used cores. On an I7 for

example, you better performance in terms of the number of performed

MFlops/second, on a program running one thread than you do with five

threads!. The fastest benchmarks come at about 3 to 4 threads, giving up

to about 30% better maths performance than the single thread. However

not the huge jump that might be expected. The Phenom, scales more

linearly here.

A lot of Maxim's image processing is bottle-necked by memory, rather

than processor speed. I got nearly a 10% boost in overall performance on

deconvolution, by substituting DDR3 2133 memory, for 1866...

So there may not be quite the massive gains from multi-threading that

some people may expect. Though there should be plenty to make it well

worthwhile 'long term'.



_However_, what I really would like to see in the short term, is the

user interface boxes all running threaded separately from the

processing/IO. It is really annoying that you can't select, drag, etc.,

the interface boxes while the code is in the middle of doing something.



Also, have you considered the possibility of performing some of the

functions 'elsewhere'?. One of the features of the later graphic drivers

on newer systems, is the ability to use the massive parallel processing

available on modern video cards to perform image processing. I had cause

a few months ago to require an FFT at high speed on a large data set,

and using the graphic card to do this outperformed the main processor by

several times. Over 100 parallel threads....



The jump to 64bit, is potentially marvelous for large image processing

(exactly what it is needed for), _but_ you have to remember that 64 bit

processing comes at a cost of having to manipulate larger data tables in

the OS etc.. If you put a 64bit and a 32bit OS on exactly the same

modern hardware, and then run something like a basic processing

operation dealing with images that are small enough that the memory size

limits don't apply. Don't be surprised if the 32bit version is actually

faster.



Best Wishes



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

#48395 Feb 8 3:26 AM

I also asked about threading here last year.



tech.groups.yahoo.com/group/MaxImDL/message/48036



robin

--- In MaxImDL@yahoogroups.com, "PhillipM" pmarshall7@...> wrote:

>

> Good Morning Alfredo;

>

> I asked this question to Defraction Limited some months back.

> There response was, MaximDL v5.xx would work properly on an i7-950 (64 bit-8 thread) platform just fine, but MaximDL would not utilize the additional processors. MDL is not optimized for x64. MDL will work on both the x32 or x64 platforms. In your root directory of your Windows 7 x64 computer are two directorys for programs; "Program Files" (for x64 programs) and "Program Files (x86)" (for x32 programs).

>

> On the other hand, I have the x64 version of PhotoShop and its performance is enhanced with the multiple processors. Also the latest version of PixInsight is also optimized for multiple processors. Both of these x64 optimized programs are noticable faster than there 32 bit counter parts.

>

> Hopefully, DL will become x64 enabled in there next major release, whenever that will be.

>

> clear skies; Phillip Marshall

>

> --- In MaxImDL@yahoogroups.com, Alfredo Beltr..n albeltrang73@> wrote:

> >

> > Hi

> >

> > I have a question about Maxim when used with multi core processors: will it take full advantage of the four cores of a Windows 7 64 bit machine with an i3 processor, or will it use just some of them?

> >

> > Thanks for your help

> >

> > Alfredo

> >

>







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

#48396 Feb 8 4:31 AM

Multi threading is a long established technique. It's particularly

effective for image processing since you typically cut up the image in

bands and dole out each band to a core. Synchronisation is simple

because each pieces of images are owned by their own thread removing the

need for synchronisation of multiple threads. Yes the boundary between

each band and merging the resulting image adds a bit of complexity and

does need synchronisation but you make up for it with the time you gain

processing the rest of the bands at warp speed. It's also true that you

will run into memory contention. But it's either that or having memory

idle with just one core! And remember that you have local CPU cache to

alleviate the memory contention problem. In a typical 3x3 convolution,

most of the pixel values are already in cache thanks to the work you did

for the previous pixel so you aren't out to core memory as much as you

think. Computing has been, for the last 40 years, at making your piece

of the problem working hard (CPU, memory, disk) upto being slowed by the

other subsystems. This is no different.



GPU offloading would be great. However writing for GPUs is actually

quite specialised work and last I checked GPU programming wasn't unified

across the platform (meaning the NVIDIA, ATI or Intel GPUs all need

dedicated work). It would be great and should a NASA contract appear but

I wouldn't doubt that it would get done. But I would not be surprised

that it's not economical to do otherwise. Remember though that you have

8 cores in your machine but just 1 GPU so keeping all the cores busy

will probably start to catch up with the GPU.



Multithreaded GUI though is more complex. The X toolkit doesn't allow

for it and if I remember properly neither does Win32. You can work

around this by having all the UI updates go through the single thread

but picking up it's info from other threads. That's one area were

multi-threading is righfully considered messy. OS/2 did and it allowed

for wonderfully responsive GUIs thanks to the dedicated thread for it's

event loop but they was a bitch to code right seeing that all menus and

GUI events had to be available under all conditions. It's just harder to

do and it's spreaded throught the application 's architecture.



I really doubt 64 bit would be much of a factor. Yes, 64bit pointers vs

32bit ints get confused on poorly written code and 64 bit pointers take

more room, mostly for nothing, causing a bit of a penalty with the cache

due to slightly lower locality of reference due to the same data taking

more space. Mind you the bulk of the images themselves would be

represented the exact same way so I doubt that you would see much of a

problem in the end. Today's machines have the oomph to handle 64 bit

apps and OS and better that than being stuck in 32 bit land shuffling

things to disk back and forth to have enough room.

On 2/8/2012 5:42 AM, R J Hamlett wrote:

>

>

> A lot of Maxim's image processing is bottle-necked by memory, rather

> than processor speed. I got nearly a 10% boost in overall performance on

> deconvolution, by substituting DDR3 2133 memory, for 1866...

> So there may not be quite the massive gains from multi-threading that

> some people may expect. Though there should be plenty to make it well

> worthwhile 'long term'.

>

> _However_, what I really would like to see in the short term, is the

> user interface boxes all running threaded separately from the

> processing/IO. It is really annoying that you can't select, drag, etc.,

> the interface boxes while the code is in the middle of doing something.

>

> Also, have you considered the possibility of performing some of the

> functions 'elsewhere'?. One of the features of the later graphic drivers

> on newer systems, is the ability to use the massive parallel processing

> available on modern video cards to perform image processing. I had cause

> a few months ago to require an FFT at high speed on a large data set,

> and using the graphic card to do this outperformed the main processor by

> several times. Over 100 parallel threads....

>

> The jump to 64bit, is potentially marvelous for large image processing

> (exactly what it is needed for), _but_ you have to remember that 64 bit

> processing comes at a cost of having to manipulate larger data tables in

> the OS etc.. If you put a 64bit and a 32bit OS on exactly the same

> modern hardware, and then run something like a basic processing

> operation dealing with images that are small enough that the memory size

> limits don't apply. Don't be surprised if the 32bit version is actually

> faster.

>

> Best Wishes

>

>







[Non-text portions of this message have been removed]



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

#48397 Feb 8 4:51 AM

Patrice - well said. Multi-threading is a great way to break up

compute intensive processes. At work, we have applications with a

thread for user interface, one for each special device that needs to

be handled (asynchronously), and then some computing problems are

chunked off to separate threads. Crunching a big image could be split

up per processor; alternatively, batch processing of images could be

passed to separate threads. e.g. have 4 images you want to adjust ?

Do them one per core simultaneously. Cuts memory contention some, and

puts the cores to work.

There's a standard toolkit for parallel computing using GPUs now -

its called OpenCL, and been around for about 3 years.

en.wikipedia.org/wiki/OpenCL

Its supported by AMD (ATI), nVidia, and other vendors like IBM.

If you remember BOINC and Seti@home, there are some algorithms coded to use it.

Nifty n-body simulation video:

www.youtube.com/watch?v=r1sN1ELJfNo

However, nobody said its easy and readily supportable, but its

coming. We're seeing companies use this type of technology in new ways.

Cheers

Colin





At 07:31 AM 2012-02-08, Patrice Scattolin wrote: >Multi threading is a long established technique. It's particularly

>effective for image processing since you typically cut up the image in

>bands and dole out each band to a core. Synchronisation is simple

>because each pieces of images are owned by their own thread removing the

>need for synchronisation of multiple threads. Yes the boundary between

>each band and merging the resulting image adds a bit of complexity and

>does need synchronisation but you make up for it with the time you gain

>processing the rest of the bands at warp speed. It's also true that you

>will run into memory contention. But it's either that or having memory

>idle with just one core! And remember that you have local CPU cache to

>alleviate the memory contention problem. In a typical 3x3 convolution,

>most of the pixel values are already in cache thanks to the work you did

>for the previous pixel so you aren't out to core memory as much as you

>think. Computing has been, for the last 40 years, at making your piece

>of the problem working hard (CPU, memory, disk) upto being slowed by the

>other subsystems. This is no different.

>

>GPU offloading would be great. However writing for GPUs is actually

>quite specialised work and last I checked GPU programming wasn't unified

>across the platform (meaning the NVIDIA, ATI or Intel GPUs all need

>dedicated work). It would be great and should a NASA contract appear but

>I wouldn't doubt that it would get done. But I would not be surprised

>that it's not economical to do otherwise. Remember though that you have

>8 cores in your machine but just 1 GPU so keeping all the cores busy

>will probably start to catch up with the GPU.

>

>Multithreaded GUI though is more complex. The X toolkit doesn't allow

>for it and if I remember properly neither does Win32. You can work

>around this by having all the UI updates go through the single thread

>but picking up it's info from other threads. That's one area were

>multi-threading is righfully considered messy. OS/2 did and it allowed

>for wonderfully responsive GUIs thanks to the dedicated thread for it's

>event loop but they was a bitch to code right seeing that all menus and

>GUI events had to be available under all conditions. It's just harder to

>do and it's spreaded throught the application 's architecture.

>

>I really doubt 64 bit would be much of a factor. Yes, 64bit pointers vs

>32bit ints get confused on poorly written code and 64 bit pointers take

>more room, mostly for nothing, causing a bit of a penalty with the cache

>due to slightly lower locality of reference due to the same data taking

>more space. Mind you the bulk of the images themselves would be

>represented the exact same way so I doubt that you would see much of a

>problem in the end. Today's machines have the oomph to handle 64 bit

>apps and OS and better that than being stuck in 32 bit land shuffling

>things to disk back and forth to have enough room.

>

>On 2/8/2012 5:42 AM, R J Hamlett wrote:

> >

> >

> > A lot of Maxim's image processing is bottle-necked by memory, rather

> > than processor speed. I got nearly a 10% boost in overall performance on

> > deconvolution, by substituting DDR3 2133 memory, for 1866...

> > So there may not be quite the massive gains from multi-threading that

> > some people may expect. Though there should be plenty to make it well

> > worthwhile 'long term'.

> >

> > _However_, what I really would like to see in the short term, is the

> > user interface boxes all running threaded separately from the

> > processing/IO. It is really annoying that you can't select, drag, etc.,

> > the interface boxes while the code is in the middle of doing something.

> >

> > Also, have you considered the possibility of performing some of the

> > functions 'elsewhere'?. One of the features of the later graphic drivers

> > on newer systems, is the ability to use the massive parallel processing

> > available on modern video cards to perform image processing. I had cause

> > a few months ago to require an FFT at high speed on a large data set,

> > and using the graphic card to do this outperformed the main processor by

> > several times. Over 100 parallel threads....

> >

> > The jump to 64bit, is potentially marvelous for large image processing

> > (exactly what it is needed for), _but_ you have to remember that 64 bit

> > processing comes at a cost of having to manipulate larger data tables in

> > the OS etc.. If you put a 64bit and a 32bit OS on exactly the same

> > modern hardware, and then run something like a basic processing

> > operation dealing with images that are small enough that the memory size

> > limits don't apply. Don't be surprised if the 32bit version is actually

> > faster.

> >

> > Best Wishes

> >

> >

>

>

>

>[Non-text portions of this message have been removed]

>

>

>

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

>

>Yahoo! Groups Links

>

>

>







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

#48402 Feb 8 9:53 PM

--- In MaxImDL@yahoogroups.com, Colin Haig telescope@...> wrote: >



> However, nobody said its easy and readily supportable, but its

> coming. We're seeing companies use this type of technology in new ways.



Parallel programming was already available in the 80's. Back then I was using Parallel extensions to Fortran on VAX/VMS. The 64 bit OS's and CPUs were already available in the early 90's. Some things come very late to the PC world.



-Adam



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

#48404 Feb 8 10:38 PM

Actually I used a Burroughs 5500 in 1967.

With virtual memory.

--- In MaxImDL@yahoogroups.com, "malanalan" malanalan@...> wrote:

>

>

>

> --- In MaxImDL@yahoogroups.com, Colin Haig telescope@> wrote:

> >

>

> > However, nobody said its easy and readily supportable, but its

> > coming. We're seeing companies use this type of technology in new ways.

>

> Parallel programming was already available in the 80's. Back then I was using Parallel extensions to Fortran on VAX/VMS. The 64 bit OS's and CPUs were already available in the early 90's. Some things come very late to the PC world.

>

> -Adam

>



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

#48407 Feb 9 5:47 AM

It had 2 cores, and used Algol for it's OS.

--- In MaxImDL@yahoogroups.com, "lawrence_d_lopez" lawlopez3@...> wrote:

>

> Actually I used a Burroughs 5500 in 1967.

> With virtual memory.

>

> --- In MaxImDL@yahoogroups.com, "malanalan" malanalan@> wrote:

> >

> >

> >

> > --- In MaxImDL@yahoogroups.com, Colin Haig telescope@> wrote:

> > >

> >

> > > However, nobody said its easy and readily supportable, but its

> > > coming. We're seeing companies use this type of technology in new ways.

> >

> > Parallel programming was already available in the 80's. Back then I was using Parallel extensions to Fortran on VAX/VMS. The 64 bit OS's and CPUs were already available in the early 90's. Some things come very late to the PC world.

> >

> > -Adam

> >

>



Contact Us
This Site's Privacy Policy
Google's privacy policies

S
e
n
i
o
r
T
u
b
e
.
o
r
g