I understand that psyco significantly increases memory use. Is that for
code or data? More specifically, if I've got a memory intensive
application (it might use 100's of Mbytes of data), should I expect
memory use to go up significantly under psyco?
Also, for that memory intensive application, how should I expect Python
memory use to compare with C++? I'm really only interested in data; the
memory needed to store the code is almost certainly insignificant in
either case.
The data is a large number of small objects, interconnected in various
data structures, not just one huge block of raw data.
I know all of the above is very vague, but I'm just trying to get a
rough idea if a Python implementation is feasable (or at least
plausable). If a C++ version takes 300 Mbytes and a Python version
takes 1 Gig, that's probably not going to work. Are there any rules of
thumb I could use to get a first-order estimate?
On Mon, 21 Jun 2004 20:25:21 +0000, patrick conroy wrote:
> C++ == Neander
> Python == Normite.
>
> No, that's not right.
> Java == Normite
> COBOL == Neander
>
> Nope...
> Grrr...
Assembler == Neander
--
"If you have an apple and I have an apple and we exchange apples
then you and I will still each have one apple.
But if you have an idea and I have one idea and we exchange these
ideas,then each of us will have two ideas" George B. Shaw
"Dave Hinz" <[email protected]> wrote in message news:[email protected]...
> On Tue, 22 Jun 2004 11:48:14 GMT, Buck Turgidson <[email protected]> wrote:
> >
> > You can go anything with grep, sed, and awk.
>
> I've never seen anyone misspeel "perl" that way before.
>
Oh yea! Then what IS the correct way to "peel" perl? ;^}
Roy Smith <[email protected]> wrote:
>The data is a large number of small objects, interconnected in various
>data structures, not just one huge block of raw data.
I've never heard of joinery described that way. ;)
Wes
(trying to learn perl)
--
Reply to:
Whiskey Echo Sierra Sierra AT Gee Tee EYE EYE dot COM
Lycos address is a spam trap.
On Mon, 21 Jun 2004 11:41:43 -0400, Roy Smith <[email protected]> wrote:
> If a C++ version takes 300 Mbytes and a Python version
> takes 1 Gig, that's probably not going to work. Are there any rules of
> thumb I could use to get a first-order estimate?
I'd say lumber costs (retail) times about 3, should get you in the
ballpark. Higher if it's a particularly difficult species of
wood to work, or if other advanced techniques are required. Of course,
if you have to buy a new tool to do the job, half of that cost should
be added as well.
Hope this helps...
On Tue, 22 Jun 2004 11:48:14 GMT, Buck Turgidson <[email protected]> wrote:
>
> You can go anything with grep, sed, and awk.
I've never seen anyone misspeel "perl" that way before.
On Tue, 22 Jun 2004 20:16:02 +0000 (UTC), Chris Richmond - MD6-FDC ~ <[email protected]> wrote:
> In article <[email protected]>,
> [email protected] (Robert Bonomi) writes:
>>>
>>There are _always_ better ways than the pathetically eclectic rubbish lister.
>
> Define "better" in this context.
It's OK, he's just sore that he can't write in Perl with his toggle
switches. I look at it as the Leatherman of tools - sure, there are
specialized tools that can get you the last 1% of functionality, but
for 99% of what I'm doing, I can use perl for it.
The _real_ question is, ... VI or EMACS?
Dave Hinz
On Wed, 23 Jun 2004 01:15:57 +0000, Robert Bonomi <[email protected]> wrote:
> _Wall_ said so. I figure _he_ knows what he's talking about, re: PERL.
Oh yeah? Well, what would _he_ know about perl, anyway? Harrumpf.
> The rubbish-lister's advantage is that is 'good enough' for a _very_wide_
> variety of things. It doesn't _try_ to be 'best' at _anything_ -- being
> 'good enough' _is_ 'good enough'. <grin>
Exactly my "leatherman" analogy, yup.
Dave Hinz
On Wed, 23 Jun 2004 16:16:16 +0000 (UTC), Chris Richmond - MD6-FDC ~ <[email protected]> wrote:
> In article <[email protected]>,
> Dave Hinz <[email protected]> writes:
>>On Tue, 22 Jun 2004 20:16:02 +0000 (UTC), Chris Richmond - MD6-FDC ~ <[email protected]> wrote:
>>The _real_ question is, ... VI or EMACS?
>
> Isn't emacs a mail or news reader? What does it have to do with perl
> and editing?
It has nothing at all to do with editing, of course. I think you're
wrong about what EMACS is, though, I thought it was an interface for
"adventure", isn't it? "You're in a maze of twisty corridors, all alike"
and all that?
Dave "vim, actually..." Hinz
On Wed, 23 Jun 2004 18:24:59 GMT, patrick conroy <[email protected]> wrote:
> "Chris Richmond - MD6-FDC ~" <[email protected]> wrote in
> message news:[email protected]...
>
>> Isn't emacs a mail or news reader? What does it have to do with perl
>> and editing?
>
> Nope, and the OP must've missed the fact you work @ Intel. :)
Hrrm? emacs runs just fine on a lot of OS's which run on Intel
processors. It might even run on windows too, but I'm not likely to
try for at least two reasons.
On Wed, 23 Jun 2004 23:24:45 +0000, Robert Bonomi <[email protected]> wrote:
> In article <[email protected]>,
> Dave Hinz <[email protected]> wrote:
>>On Wed, 23 Jun 2004 01:15:57 +0000, Robert Bonomi
>><[email protected]> wrote:
>>
>>> _Wall_ said so. I figure _he_ knows what he's talking about, re: PERL.
>>
>>Oh yeah? Well, what would _he_ know about perl, anyway? Harrumpf.
>>
> Hint (No, not the singular of 'hinz' :): Look up the name of the guy
> who _invented_ the language. <grin>
Er, yeah, I know that. I actually got an email from him years ago,
answering a perl question I had put in one of the mailing lists.
Must've been a worthy question but I can't remember what it was about
anymore.
Doug Winterburn <[email protected]> wrote in message news:<[email protected]>...
> On Mon, 21 Jun 2004 20:25:21 +0000, patrick conroy wrote:
>
> > C++ == Neander
> > Python == Normite.
> >
> > No, that's not right.
> > Java == Normite
> > COBOL == Neander
> >
> > Nope...
> > Grrr...
>
> Assembler == Neander
VB.net = Crapsman
VB Script = Harbor Freight
PHP = Unisaw
Roy Smith wrote:
> In article <[email protected]>,
> Dave Hinz <[email protected]> wrote:
>
> > On Mon, 21 Jun 2004 11:41:43 -0400, Roy Smith <[email protected]> wrote:
> >
> > > If a C++ version takes 300 Mbytes and a Python version
> > > takes 1 Gig, that's probably not going to work. Are there any rules of
> > > thumb I could use to get a first-order estimate?
> >
> > I'd say lumber costs (retail) times about 3, should get you in the
> > ballpark. Higher if it's a particularly difficult species of
> > wood to work, or if other advanced techniques are required. Of course,
> > if you have to buy a new tool to do the job, half of that cost should
> > be added as well.
> >
> > Hope this helps...
>
> Arrggggh. I posted that to the wrong newsgroup by accident. My bad.
I have done that 2 or 3 times before also. Mine were a bit more personal however. I
understand your feeling.
Hoyt W.
In article <[email protected]>,
Chris Richmond - MD6-FDC ~ <[email protected]> wrote:
>In article <[email protected]>,
> [email protected] (Robert Bonomi) writes:
>>In article <[email protected]>,
>>Dave Hinz <[email protected]> wrote:
>>>On Tue, 22 Jun 2004 11:48:14 GMT, Buck Turgidson <[email protected]> wrote:
>>>> You can go anything with grep, sed, and awk.
>>>
>>>I've never seen anyone misspeel "perl" that way before.
>>>
>>There are _always_ better ways than the pathetically eclectic rubbish lister.
>
>Define "better" in this context.
>
>Chris (making my living writing perl, more or less)
_Wall_ said so. I figure _he_ knows what he's talking about, re: PERL.
'Better' is *highly* context-dependent. For any specific, _single_,
application, there is almost always 'something' that is better, for
any rational ranking basis.
The rubbish-lister's advantage is that is 'good enough' for a _very_wide_
variety of things. It doesn't _try_ to be 'best' at _anything_ -- being
'good enough' _is_ 'good enough'. <grin>
> I understand that psyco significantly increases memory use. Is that for
> code or data? More specifically, if I've got a memory intensive
> application (it might use 100's of Mbytes of data), should I expect
> memory use to go up significantly under psyco?
>
> Also, for that memory intensive application, how should I expect Python
> memory use to compare with C++? I'm really only interested in data; the
> memory needed to store the code is almost certainly insignificant in
> either case.
>
> The data is a large number of small objects, interconnected in various
> data structures, not just one huge block of raw data.
>
> I know all of the above is very vague, but I'm just trying to get a
> rough idea if a Python implementation is feasable (or at least
> plausable). If a C++ version takes 300 Mbytes and a Python version
> takes 1 Gig, that's probably not going to work. Are there any rules of
> thumb I could use to get a first-order estimate?
You can go anything with grep, sed, and awk.
In article <[email protected]>,
patrick conroy <[email protected]> wrote:
>
>"Chris Richmond - MD6-FDC ~" <[email protected]> wrote in
>message news:[email protected]...
>
>> Chris (making my living writing perl, more or less)
>
>Oh! I'm sorry!
>
><ducking... :) >
There are days that I *really* wish that Al Capp's mythical radical student
group from the 1960's/1970's -- "Students Wildly Indignant About Nearly
Everything" -- actually existed, and that I had them as a client. Just
imagine the line-item on the resume': "Casting PERLs before S.W.I.N.E."
Doug Winterburn wrote:
> On Mon, 21 Jun 2004 19:41:42 -0500, Morris Dovey wrote:
>
>
>
>> Huh!
>>
>> Horizontal Microcode = Neander
>>
>> Binary machine code = --Neander
>>
>> Assembler = --Binary Machine code
>>
>> C = Normite
>>
>> APL = ++Normite
>>
>> { C++, Java, COBOL, Fortran, PL/I, BASIC, Pascal } =
>> (Cro-Magnon)
>
> Sheesh, Morris - you'll get me remembering the 360/30 and
> 360/40 microcode. The 360/30 had a capacitive microcode made
> up of mylar keypunch cards with copper coating all stacked in
> a pile and squeezed together with an inflatable airbag. The
> 360/40 had TROS for microcode - same type of cards, but
> tannsformer/inductance based. And then there was the
> "datacell"/noodle snatcher - a whopping ten megabytes of
> storage in a rotating pie shaped drum with mag tape like
> strips that were snatched out the contraption , drug over the
> read/wriote heads and (hopefully) stuffed back in the drum.
> Didn't turn out to be a long term success...
The follow-on microcode storage device fared much better. The
Igar development effort produced the 33FD (33xx for disk, FD for
"flexible disc". The 33FD was originally intended as a microcode
IPL device for FS (which never came to be). Concurrent with Igar
was Gulliver, a sealed disk drive with mechanicals from the labs
at Hursley (thus the Winchester name applied to the technology)
capable of storing 40/64MB of data, depending on model; and Lynx,
a printer with type embossed on something roughly similar to a
bandsaw blade (I knew I could find something bordering on
topicality in this!) - all three of which survived fairly well in
one form or another. [There were a lot of woodworkers in that
crew; and they were the people to talked me into buying my
Unisauer and mentored my first serious woodworking projects.]
Seems like everybody liked the noodle muncher except the people
who relied on 'em and the people who serviced 'em. I'd really
wanted to play with one but never did.
> -Doug (IBM 1966-1970 - card assembler)
--
Morris (1959- PPR & Intercom on paper tape for
RAM-less [& ROM-less] Bendix G-15)
(1969-1976 IBM new prod dev - lotsa toy^H^H^Hmachines,
languages, media)
Roy Smith <[email protected]> wrote in
news:[email protected]:
> In article <[email protected]>,
> Dave Hinz <[email protected]> wrote:
>
>> On Mon, 21 Jun 2004 11:41:43 -0400, Roy Smith <[email protected]> wrote:
>>
>> > If a C++ version takes 300 Mbytes and a Python version
>> > takes 1 Gig, that's probably not going to work. Are there any
>> > rules of thumb I could use to get a first-order estimate?
>>
>> I'd say lumber costs (retail) times about 3, should get you in the
>> ballpark. Higher if it's a particularly difficult species of
>> wood to work, or if other advanced techniques are required. Of
>> course, if you have to buy a new tool to do the job, half of that
>> cost should be added as well.
>>
>> Hope this helps...
>
> Arrggggh. I posted that to the wrong newsgroup by accident. My bad.
>
That's OK, Roy. Just make sure you finish that software with a nice hand
rubbed shellac. ;-)
Patriarch
In article <[email protected]>,
Dave Hinz <[email protected]> wrote:
>On Tue, 22 Jun 2004 11:48:14 GMT, Buck Turgidson <[email protected]> wrote:
>>
>> You can go anything with grep, sed, and awk.
>
>I've never seen anyone misspeel "perl" that way before.
>
There are _always_ better ways than the pathetically eclectic rubbish lister.
Unfortunately, the better ways are almost always more complex, and/or
more difficult to learn/use.
On Mon, 21 Jun 2004 19:41:42 -0500, Morris Dovey wrote:
> Huh!
>
> Horizontal Microcode = Neander
>
> Binary machine code = --Neander
>
> Assembler = --Binary Machine code
>
> C = Normite
>
> APL = ++Normite
>
> { C++, Java, COBOL, Fortran, PL/I, BASIC, Pascal } = (Cro-Magnon)
Sheesh, Morris - you'll get me remembering the 360/30 and 360/40
microcode. The 360/30 had a capacitive microcode made up of mylar
keypunch cards with copper coating all stacked in a pile and squeezed
together with an inflatable airbag. The 360/40 had TROS for microcode -
same type of cards, but tannsformer/inductance based. And then there was
the "datacell"/noodle snatcher - a whopping ten megabytes of storage in a
rotating pie shaped drum with mag tape like strips that were snatched out
the contraption , drug over the read/wriote heads and (hopefully) stuffed
back in the drum. Didn't turn out to be a long term success...
-Doug (IBM 1966-1970 - card assembler)
--
"If you have an apple and I have an apple and we exchange apples
then you and I will still each have one apple.
But if you have an idea and I have one idea and we exchange these
ideas,then each of us will have two ideas" George B. Shaw
In article <[email protected]>,
[email protected] (Robert Bonomi) writes:
>In article <[email protected]>,
>Dave Hinz <[email protected]> wrote:
>>On Tue, 22 Jun 2004 11:48:14 GMT, Buck Turgidson <[email protected]> wrote:
>>> You can go anything with grep, sed, and awk.
>>
>>I've never seen anyone misspeel "perl" that way before.
>>
>There are _always_ better ways than the pathetically eclectic rubbish lister.
Define "better" in this context.
Chris (making my living writing perl, more or less)
--
Chris Richmond | I don't speak for Intel & vise versa
In article <[email protected]>,
Dave Hinz <[email protected]> writes:
>On Tue, 22 Jun 2004 20:16:02 +0000 (UTC), Chris Richmond - MD6-FDC ~ <[email protected]> wrote:
>The _real_ question is, ... VI or EMACS?
Isn't emacs a mail or news reader? What does it have to do with perl
and editing?
--
Chris Richmond | I don't speak for Intel & vise versa
Chris Richmond - MD6-FDC ~ wrote:
> In article <[email protected]>,
> Dave Hinz <[email protected]> writes:
>>On Tue, 22 Jun 2004 20:16:02 +0000 (UTC), Chris Richmond - MD6-FDC ~
>><[email protected]> wrote: The _real_ question is, ... VI or
>>EMACS?
>
> Isn't emacs a mail or news reader? What does it have to do with perl
> and editing?
What ever gave you the idea that EMACS is a mail or news reader? It's one
of the two standard editing tools in the Unix world, the other being vi,
and the choice of which is something of a religious issue akin to gun
control or "Mac vs PC". Perhaps you are confused because there is a
newsreader ("gnews") that runs under EMACS.
--
--John
Reply to jclarke at ae tee tee global dot net
(was jclarke at eye bee em dot net)
In article <[email protected]>,
"J. Clarke" <[email protected]> writes:
>Chris Richmond - MD6-FDC ~ wrote:
>> Isn't emacs a mail or news reader? What does it have to do with perl
>> and editing?
>
>What ever gave you the idea that EMACS is a mail or news reader? It's one
>of the two standard editing tools in the Unix world, the other being vi,
>and the choice of which is something of a religious issue akin to gun
>control or "Mac vs PC". Perhaps you are confused because there is a
>newsreader ("gnews") that runs under EMACS.
Caught one!!! Hook, line, and sinker! :^)
I'll quit using vim and xterms when you pry my cold, dead fingers
from my keyboard.
Chris
--
Chris Richmond | I don't speak for Intel & vise versa
"Roy Smith" <[email protected]> wrote in message
news:[email protected]...
>
> Also, for that memory intensive application, how should I expect Python
> memory use to compare with C++? I'm really only interested in data; the
> memory needed to store the code is almost certainly insignificant in
> either case.
C++ == Neander
Python == Normite.
No, that's not right.
Java == Normite
COBOL == Neander
Nope...
Grrr...
In article <[email protected]>,
Dave Hinz <[email protected]> wrote:
>On Wed, 23 Jun 2004 01:15:57 +0000, Robert Bonomi
><[email protected]> wrote:
>
>> _Wall_ said so. I figure _he_ knows what he's talking about, re: PERL.
>
>Oh yeah? Well, what would _he_ know about perl, anyway? Harrumpf.
>
Hint (No, not the singular of 'hinz' :): Look up the name of the guy
who _invented_ the language. <grin>
>
>> The rubbish-lister's advantage is that is 'good enough' for a _very_wide_
>> variety of things. It doesn't _try_ to be 'best' at _anything_ -- being
>> 'good enough' _is_ 'good enough'. <grin>
>
>Exactly my "leatherman" analogy, yup.
>
>Dave Hinz
>
"Chris Richmond - MD6-FDC ~" <[email protected]> wrote in
message news:[email protected]...
>
> Isn't emacs a mail or news reader? What does it have to do with perl
> and editing?
Nope, and the OP must've missed the fact you work @ Intel. :)
Doug Winterburn wrote:
> On Mon, 21 Jun 2004 20:25:21 +0000, patrick conroy wrote:
>
>
>>C++ == Neander
>>Python == Normite.
>>
>>No, that's not right.
>>Java == Normite
>>COBOL == Neander
>>
>>Nope...
>>Grrr...
>
>
> Assembler == Neander
>
Huh!
Horizontal Microcode = Neander
Binary machine code = --Neander
Assembler = --Binary Machine code
C = Normite
APL = ++Normite
{ C++, Java, COBOL, Fortran, PL/I, BASIC, Pascal } = (Cro-Magnon)
--
Morris Dovey
DeSoto, Iowa USA
"Dave Hinz" <[email protected]> wrote in message
news:[email protected]...
>
>
> Hrrm? emacs runs just fine on a lot of OS's which run on Intel
> processors. It might even run on windows too, but I'm not likely to
> try for at least two reasons.
>
Yeah - just tugging at his leg and ignoring BSD's, Linux's, etc.
Thanks for the Adventure reminder.
Played it on a DEC-10, odd machine that one, years ago.
Took me and a co-worker a couple of months to finish it, but we did.
He had the patience to map out the second maze.
In article <[email protected]>,
Dave Hinz <[email protected]> wrote:
> On Mon, 21 Jun 2004 11:41:43 -0400, Roy Smith <[email protected]> wrote:
>
> > If a C++ version takes 300 Mbytes and a Python version
> > takes 1 Gig, that's probably not going to work. Are there any rules of
> > thumb I could use to get a first-order estimate?
>
> I'd say lumber costs (retail) times about 3, should get you in the
> ballpark. Higher if it's a particularly difficult species of
> wood to work, or if other advanced techniques are required. Of course,
> if you have to buy a new tool to do the job, half of that cost should
> be added as well.
>
> Hope this helps...
Arrggggh. I posted that to the wrong newsgroup by accident. My bad.
"Chris Richmond - MD6-FDC ~" <[email protected]> wrote in
message news:[email protected]...
> Chris (making my living writing perl, more or less)
Oh! I'm sorry!
<ducking... :) >