They're very much still around: I have a Tadpole SPARC, a 750 MHz Ultra IIi
that my wife bought me for a christmas
present 2.5 years ago, for roughly $US 3,200.00.
More in $CDN (;-))
It runs Solaris 9 and Frame, which is the most important
thing, as that's my publisher's typesetter.
Secondarily it runs all the Sun stuff I use
at work.
I'm just waiting for a Solaris 10
keyboard driver and I'll update my
second boot partition to 10.
It also plays terminal to my Dell Linux
box which runs Win4Lin and that Last
Remaining Windows Program*, Canadian.
QuickTax (;-))
In a test using samba, branch prediction only
saved me a few cycles deciding that the branch
around the if-statement or debug macro was
going to be taken, but the delay was
indeed from filling
the i-cache line for the target, which
took many many MANY cycles.
A conventional data prefetcher didn't buy me anything (:-))
A typical debug macro or multi-line if
will tale me to the next i-cache line with more than
80% probability.
The reason Sun did the CMT chips
was the horrible
speed mismatch between CPU and memory.
It dispatches another thread
when the current thread has to wait
for a cache load. The number of
decoders/registers was set by observing
the cache stall behavior of real programs.
I'm inclined to disagree, as it's merely
annoying to turn a single-process
single-threaded program into a multi-instance
program.
I agree that it rapidly gets hard.
Typically it's where you don't keep it brutally
simple that causes problems: locks, race
conditions, deadly embrace and all their
friends come out to play (;-)).
Better languages make it at least possible
to write "clever" code, as the monitors
in Java ("protected" classes) provide a
discipline that can be used for
simple locking schemes. Far better than
C or (horrors!) PL/1 processes. But
if you get tricky in Java, it's like getting
tricky in any language. Caveat Emptor!
CMT is a good approach for dealing
with the speed mismatch between
CPUs and memory, our current Big Problem
I'll misquote Fred Weigel and suggest
that the next problem is branching:
Samba code seems to generate 5 instructions
between branches, so suspending the
process and running something else
intil the branch target is in I-cache
seems like A Good Thing (;-)).
Methinks Samba would really enjoy
a CMT processor.
Last year I as at a big commercial shop,
looking at performance of a bunch of
billing-like programs, and noticed:
Some older C, C++ and embedded-SQL
programs are written without consideration
of parallelization: they're single-process
single-thread.
If the customer is large, the majority
of the single-process single-thread programs have
been rewritten to allow one to run multiple
instances, so they can use more than one
CPU.
The latter can scale on multi-processors,
and mostly do. Much of our performance
work centered on finding out how many
processes to run, and whether to group
them all on one processor board to get
short memory access times. Plus fixing
obvious things, like O(n^2) algorithms.
in my personal opinion, the consideration for
older programs are as follows:
Can you change the start-up of
single-process single-thread programs to
split up the input data and run multiple
instances.
Are there any bad algorithms in use,
such as singly-linked lists for large data
stores. This has nothing whatsoever to do
with CMT on first glance, but turns out
to be a limit on the performance you're
using multiple instances to achieve!
Is there data shared between the instances,
because if so, you will have to add locking,
which is slowish on large multiprocessors,
and arguably faster on CMT processors with very
good memory locality.
So: adding CMT makes it a good idea to
parallelize older programs, O(n^2) algorithms
in CMT or multi-CPU programs are every bit as bad as in uniprocessor
programs, and introducing locking is bad, but
locking on CMT needs to be measured against
regular multiprocessors to see if it's going
to be better (my speculation) or worse.
A company that used to build some of the best
instruments and some lovely workstations slowly
winds down to the xxx-on-intel junkyard.
It's even disappointing to an employee
of the competition: I **liked** competing
with H-P, they always kept me on my toes.
--dave
Re:When four corners is too much
on
Drafting GPL3
·
· Score: 1
Dancin_Santa writes:
I'm not sure what they plan to get out of (3). The GPL is the General Public License. It may be drafted by the FSF, but it is intended for broad usage by many different people.
I fear the FSF is conflating themselves
and the whole free software movement in this
clause. This is probably unwise. [Disclaimer: RMS speaks for many of us,
specifically including myself, much of the
time...]
If the general public license
becomes too specific to a particular set of
circumstances, it becomes less general
and less useful to the broader community.
The existing GPL could use a bit of polishing,
but shouldn't change much. A different
license should be written for, for example,
programs "distributed" as services.
Subject: Copying levy versus the proposed copyright bill
I'm writing again about proposed changes in copyright law, strongly urged by our American neighbors and the record publishing industry.
I was pleased to hear your opinion on the US-like misuse of protection measures, and wonder if we're going to follow our previous policy of using copying levies instead of prohibitions on copying CDs we legally own.
The record industry seems to confuse this with indiscriminate file sharing, and is urging amendments that would make innocent copiers as liable as persons who illegally publish other's works on the internet.
I urge you to support our successful policy of copying levies on CDs, DVDs and extend the levies to removable disks ("pen drives") and other iPod-like devices), instead of reducing the consumer's right to copy their own property under the copyright act.
If it is being "market tested", then
the folks who are the testers should object.
Companies/OSs using Samba include
IBM AIX
/Debian
Red Hat
SHI Irix
Mandriva
Novell and SuSE
H-P
Sun (Solaris and Cobalt)
American Megatrends' StorTrends NAS
Applianceware Optifacio
EmergeCore Networks
FreeBSD Systems
and others. Are any of these on the
list of "testers"?
Countries with the highest piracy rates were Vietnam, Ukraine, China, Zimbabwe and Indonesia while United States, New Zealand, Austria, Sweden and the United Kingdom had the lowest.
And which countries have been on the 'net longest?
Dvorak Writes: So over the past week O'Gara tracked down and photographed PJ's home and PJ's mother's home and posted pics in her column[...]
Oh, brother. In the olden days, O'Gara would have been given a medal for generating readership.
Hmmn, in the olden days of the 1950 through perhaps 1980 she'd have been drummed out of the profession as morally unfit.
This century I hope she's charged. I certainly
would (here in Canada it's an indictable offence. I have no idea about NJ).
ZephyrXero writes:
don't develop open source code with a closed source language.
Remember the bad old days when the brand-new language "C" was owned by Bell Labs, and they claimed anything
you wrote in C belonged to Bell?
Remember how long that was true? As measured in
picoseconds?
There are no closed source languages. That's
an urban legend. You can try to booby-trap a language, like MS tried to do to Java, but that won't work, either. You may recollect that MS failed in that effort, expensively(!).
It's almost impossible to encumber open source
software by using proprietary tools. That's a self-serving tale told by the proprietary vendors, and false.
It will happen when one comes up against
differences of licensing, most notably
when working with GPL, less so with
LGPL and rarely with BSD, which is
often not restrictive enough.
If you're an author and may
ever work with third-party libraries,
plug-ins or, in the future, web
services, multiply license your
work and make sure LGPL is in
the list.
Most of my work has
been GPL or BSD, but in retrospect
I'd have better with a medium-severity
license like the Lesser/Library GPL. Read
RMS's article about why not to use the
LGPL, and understand the trade-off you're
making.
Seumas writes: Driving is a privilege and not a right.
Quite the contrary, one has the right to the quiet enjoyment of one's property. Everyone has a right to use a public road,
and it can only be taken away if
you are using a motor vehicle, and
a court of competent jurisdiction takes your right away for cause, or
You have not met the age or competence standard for using a motor vehicle, an inherently dangerous thing.
"Driving is a privilege and not a right" is an urban legend. If it wasn't a right, the cop could cancel
your license on the spot.
Sun announced plans to acquire Tarantella, Inc., a leading provider of secure application access software based in Santa Cruz, CA. [...] Sun plans to use Tarantella technology to provide customers with a higher level of secure mobile access to data and applications.
As part of the agreement, Sun will acquire the Secure Global Desktop family of products, which enables organizations to access and manage information, data, and applications across virtually all devices, networks, and platforms [...]
The software employs a flexible and secure three-tier architecture deployed on Solaris OS or Linux. Secure Global Desktop enables applications to be displayed using native protocols without the need for specialized software - a Web browser and Java technology is all that's necessary on the client device or application server.[...]
Most importantly, the software will enable you to present a variety of applications on Sun Ray thin clients -- including those written to Microsoft Windows.
... there was an ADL-based toolset, called if memory serves, JavaSpec, which
made api testing hard but doable. As
opposed to "let's not but say we did". I admit I
used a hacked-up subset, but for large-scale
problems being able to generate tests and
test data sets via a tool was A Good Thing.
... but standard, sufficiently so that it can be "gamed" (:-))
The paper you're looking for is Wong, Brian, "Comparing MVS and UNIX Workload Characteristics"
Int. CMG Conference, 1998, in which (if memory serves) he looks at the comparability of MVS and
Unix programs, and derives a series of
comparisons which very approximately correlate with TP performance in a benchmark like TPC.
If you have any good, representative test that load a whole system, then in my opinion, you have a good predictor of average performance. (Tautology, eh?) If you have such a test, though, people will learn how to
get the best posible numbers from it. Average together
all the various X MHz Pentium III TPC-C results,
don't trust any single one (:-))
It runs Solaris 9 and Frame, which is the most important thing, as that's my publisher's typesetter. Secondarily it runs all the Sun stuff I use at work.
I'm just waiting for a Solaris 10 keyboard driver and I'll update my second boot partition to 10. It also plays terminal to my Dell Linux box which runs Win4Lin and that Last Remaining Windows Program*, Canadian. QuickTax (;-))
--dave/ 10/win4lin.html
* See http://www.linuxdevcenter.com/pub/a/linux/2004/06
I just burned a set of JDS 3 update CDs.
Microsoft-added GUI??? Euggh,
why when they have Looking Glass?
That means the Gnome, Java-for-desktop-apps and Open Office efforts will keep on, and they'll switch kernels on the desktop offering.
A conventional data prefetcher didn't buy me anything (:-))
A typical debug macro or multi-line if will tale me to the next i-cache line with more than 80% probability.
--dave
It dispatches another thread when the current thread has to wait for a cache load. The number of decoders/registers was set by observing the cache stall behavior of real programs.
--dave
I agree that it rapidly gets hard. Typically it's where you don't keep it brutally simple that causes problems: locks, race conditions, deadly embrace and all their friends come out to play (;-)).
Better languages make it at least possible to write "clever" code, as the monitors in Java ("protected" classes) provide a discipline that can be used for simple locking schemes. Far better than C or (horrors!) PL/1 processes. But if you get tricky in Java, it's like getting tricky in any language. Caveat Emptor!
--dave
I'll misquote Fred Weigel and suggest that the next problem is branching: Samba code seems to generate 5 instructions between branches, so suspending the process and running something else intil the branch target is in I-cache seems like A Good Thing (;-)).
Methinks Samba would really enjoy a CMT processor.
--dave
The latter can scale on multi-processors, and mostly do. Much of our performance work centered on finding out how many processes to run, and whether to group them all on one processor board to get short memory access times. Plus fixing obvious things, like O(n^2) algorithms.
in my personal opinion, the consideration for older programs are as follows:
So: adding CMT makes it a good idea to parallelize older programs, O(n^2) algorithms in CMT or multi-CPU programs are every bit as bad as in uniprocessor programs, and introducing locking is bad, but locking on CMT needs to be measured against regular multiprocessors to see if it's going to be better (my speculation) or worse.
--dave
It's even disappointing to an employee of the competition: I **liked** competing with H-P, they always kept me on my toes.
--dave
I fear the FSF is conflating themselves and the whole free software movement in this clause. This is probably unwise. [Disclaimer: RMS speaks for many of us, specifically including myself, much of the time...]
If the general public license becomes too specific to a particular set of circumstances, it becomes less general and less useful to the broader community. The existing GPL could use a bit of polishing, but shouldn't change much. A different license should be written for, for example, programs "distributed" as services.
-dave
My letter to the Hon. Jim Peterson, ny MP:
Subject: Copying levy versus the proposed copyright bill
I'm writing again about proposed changes in copyright law,
strongly urged by our American neighbors and the record
publishing industry.
I was pleased to hear your opinion on the US-like
misuse of protection measures, and wonder if we're
going to follow our previous policy of using copying levies
instead of prohibitions on copying CDs we legally
own.
The record industry seems to confuse this with
indiscriminate file sharing, and is urging amendments
that would make innocent copiers as liable as persons
who illegally publish other's works on the internet.
I urge you to support our successful policy of
copying levies on CDs, DVDs and extend the
levies to removable disks ("pen drives") and other
iPod-like devices), instead of reducing the
consumer's right to copy their own property under
the copyright act.
--dave
Companies/OSs using Samba include
IBM AIX
/Debian
Red Hat
SHI Irix
Mandriva
Novell and SuSE
H-P
Sun (Solaris and Cobalt)
American Megatrends' StorTrends NAS
Applianceware Optifacio
EmergeCore Networks
FreeBSD Systems
and others. Are any of these on the list of "testers"?
--dave
I hope the quality is good: I've used it in
the past and it needed some work.
--dave
And which countries have been on the 'net longest?
--dave
Hmmn, in the olden days of the 1950 through perhaps 1980 she'd have been drummed out of the profession as morally unfit.
This century I hope she's charged. I certainly would (here in Canada it's an indictable offence. I have no idea about NJ).
--dave
Remember the bad old days when the brand-new language "C" was owned by Bell Labs, and they claimed anything you wrote in C belonged to Bell?
Remember how long that was true? As measured in picoseconds?
There are no closed source languages. That's an urban legend. You can try to booby-trap a language, like MS tried to do to Java, but that won't work, either. You may recollect that MS failed in that effort, expensively(!).
It's almost impossible to encumber open source software by using proprietary tools. That's a self-serving tale told by the proprietary vendors, and false.
If you're an author and may ever work with third-party libraries, plug-ins or, in the future, web services, multiply license your work and make sure LGPL is in the list.
Most of my work has been GPL or BSD, but in retrospect I'd have better with a medium-severity license like the Lesser/Library GPL. Read RMS's article about why not to use the LGPL, and understand the trade-off you're making.
--dave
Quite the contrary, one has the right to the quiet enjoyment of one's property. Everyone has a right to use a public road, and it can only be taken away if
- you are using a motor vehicle, and
- a court of competent jurisdiction takes your right away for cause, or
- You have not met the age or competence standard for using a motor vehicle, an inherently dangerous thing.
"Driving is a privilege and not a right" is an urban legend. If it wasn't a right, the cop could cancel your license on the spot.--dave
Sun announced plans to acquire Tarantella, Inc., a leading provider of secure application access software based in Santa Cruz, CA. [...] Sun plans to use Tarantella technology to provide customers with a higher level of secure mobile access to data and applications.
As part of the agreement, Sun will acquire the Secure Global Desktop family of products, which enables organizations to access and manage information, data, and applications across virtually all devices, networks, and platforms [...]
The software employs a flexible and secure three-tier architecture deployed on Solaris OS or Linux. Secure Global Desktop enables applications to be displayed using native protocols without the need for specialized software - a Web browser and Java technology is all that's necessary on the client device or application server.[...]
Most importantly, the software will enable you to present a variety of applications on Sun Ray thin clients -- including those written to Microsoft Windows.
Jonathan Schwartz comments at Acquistions Accelerate Microsoft Interoperability
Tarentella is here
Even worth learning ADL (:-))
--dave
The paper you're looking for is Wong, Brian, "Comparing MVS and UNIX Workload Characteristics" Int. CMG Conference, 1998, in which (if memory serves) he looks at the comparability of MVS and Unix programs, and derives a series of comparisons which very approximately correlate with TP performance in a benchmark like TPC.
A paper that's available to CMG members is his Developing a General-Purpose OLTP Sizing Tool, which builds on the subject.
If you have any good, representative test that load a whole system, then in my opinion, you have a good predictor of average performance. (Tautology, eh?) If you have such a test, though, people will learn how to get the best posible numbers from it. Average together all the various X MHz Pentium III TPC-C results, don't trust any single one (:-))
--dave
--dave
Don't bothe reading any newspaper article with "may" in the title, or whose title is a question.... which also seems appropriate here (:-))
--dave