Roy Schestowitz <newsgroups@xxxxxxxxxxxxxxx> writes:
> __/ [ Linonut ] on Monday 18 September 2006 21:50 \__
>
>> SAS ported JMP to Linux in 2003, and now they've ported it to 64-bit
>> Linux. SAS seems proud to link to this article, which appear in the
>> September 2006 Linux Journal:
>>
>> http://www.jmp.com/about/news/linux_journal/index.shtml
>>
>> "With JMP's new multithreaded architecture running on a 64-bit dual
>> processor, experimental designs that once took several days to
>> compute can now be calculated in minutes. And, problems that were
>> impossible only last year can now be handled in minutes with 64-bit
>> Linux JMP."
>>
>> I like this part particularly:
>>
>> "Nelson observed that porting JMP to 64 bits went smoothly. "The only
>> issue was locating the few places where our code made assumptions
>> about 32-bit word and pointer sizes", says Nelson. "There were no
>> surprises from the tools used for the port, either. Much of the ease
>> in porting is due to the long heritage on 64-bit UNIX platforms of
>> the open-source tools we used."
>>
>> "The GNU Compiler Collection, gdb, Emacs and the rest of the
>> toolchain performed as expected on the x86_64 architecture", says
>> Nelson."
>>
>> Good on ya, GNU! Nice of ya to cooperate with a proprietary software
>> outfit.
>
> Opinion: proprietary scientific software is still non-'scientific' in its
> spirit. It often makes the user depend on very expensive licenses in order
> to do some analysis or run some simple code. It also hides the way it
Things cost in the real world.
> operates; black boxes are means of discouraging education through
> curiosity.
Nope. Having the source code might just lead a student astray from the
*reason* they are using that package.
Its a black box for a reason.
> That, for example, is why projects like Octave emerge, which mimic the
> behaviour of MATLAB and other scientific computing packages/languages.
No. Its because people want something for free.
>
> Still, it's nice to see that JMP JUMPS into the next generation of computing
> with Linux _and_ 64-bit architectures. Meanwhile, on the other side, some
> software runs on bug-ridden platforms that only operate properly with a
> 32-bit instruction set. It can make a tremendous difference in the context
> of scientific computing where runtimes can extend to hours, days, even
> months (without user intervention). Stability and efficiency become
> important factors. It is no surprise that many rendering farms, for example,
> have moved (and are still moving) to Linux.
Do you have benchmarks to show which apps are currently greatly improved
on 64 bits?
Do these "month long" calculations not bookmark or log as they go?
As usual, you're making things up and therefore are falsely advocating
Linux. Try telling the truth for a change and more people will believe
you.
--
We come to bury DOS, not to praise it.
(Paul Vojta, vojta@xxxxxxxxxxxxxxxxx, paraphrasing a quote of Shakespeare)
|
|
