I arrived at a need to search hard drives - like
up to 16 terabyte hard drives - AND kinda show what's
going on. THE problem is that if you need to look at
a SPECIFIC spot on the disk the usual "seek()"
functions crap out - limited to longint (about 2.4
gig). Free Pascal CLAIMS its fseek() will take an
int64 ... but in practice I see the exact same bits
of the disk come up again, which means it's rolling
over. Just started experimenting with Python - I'll
know in a day or two.

The GCC lib - sometimes requiring special flags -
claims it'll do 64-bit seeks - but I haven't
confirmed that yet either.

Consider 'dd' ... you can copy all, or parts of,
huge disks. Tell it to start at the 3tb mark
and it'll do it. I'm not sure if that uses any
of the standard 'C' libraries or is something
totally custom under the hood. It IS kinda
slow alas - try duplicating, or even zeroing, a
12tb disk sometime ... better start on friday
afternoon ......

A lot of languages/compilers were refined when
the old 2 gb files were kind of the max. You
CAN view a big disk AS a file if need be. The
world moved on, but it seems THEY didn't.

Any insights ???

"25B.E866" <25B.E866@noaaba.net> writes:
> I arrived at a need to search hard drives - like
> up to 16 terabyte hard drives - AND kinda show what's
> going on. THE problem is that if you need to look at
> a SPECIFIC spot on the disk the usual "seek()"
> functions crap out - limited to longint (about 2.4
> gig). Free Pascal CLAIMS its fseek() will take an
> int64 ... but in practice I see the exact same bits
> of the disk come up again, which means it's rolling
> over. Just started experimenting with Python - I'll
> know in a day or two.

In Python 3, file offsets use the int type, which can be as big as you
like.

> The GCC lib - sometimes requiring special flags -
> claims it'll do 64-bit seeks - but I haven't
> confirmed that yet either.

In C, on a 64-bit Linux platform, all of lseek, fseek and fseeko will
use 64-bit offsets (since long and off_t are both 64 bits on such
platforms).

https://man7.org/linux/man-pages/man2/lseek.2.html
https://man7.org/linux/man-pages/man3/fseek.3.html
https://man7.org/linux/man-pages/man3/ftello.3.html

If you have 32-bit platform still, you have a couple of options, but the
sensible one is: bin it and get a computer that hasn’t been obsolete for
the last 15 years.

--
https://www.greenend.org.uk/rjk/

On 22/02/2023 08:55, Richard Kettlewell wrote:
> you have a couple of options, but the
> sensible one is: bin it and get a computer that hasn’t been obsolete for
> the last 15 years.

LOL. Is it THAT long ago?

--
In theory, there is no difference between theory and practice.
In practice, there is.
-- Yogi Berra

The Natural Philosopher <tnp@invalid.invalid> writes:
> On 22/02/2023 08:55, Richard Kettlewell wrote:
>> you have a couple of options, but the
>> sensible one is: bin it and get a computer that hasn’t been obsolete for
>> the last 15 years.
>
> LOL. Is it THAT long ago?

Opteron release was 2003. That didn’t necessarily make 32-bit x86
obsolete overnight but the writing was on the wall.

--
https://www.greenend.org.uk/rjk/

On 2/22/23 3:55 AM, Richard Kettlewell wrote:
> "25B.E866" <25B.E866@noaaba.net> writes:
>> I arrived at a need to search hard drives - like
>> up to 16 terabyte hard drives - AND kinda show what's
>> going on. THE problem is that if you need to look at
>> a SPECIFIC spot on the disk the usual "seek()"
>> functions crap out - limited to longint (about 2.4
>> gig). Free Pascal CLAIMS its fseek() will take an
>> int64 ... but in practice I see the exact same bits
>> of the disk come up again, which means it's rolling
>> over. Just started experimenting with Python - I'll
>> know in a day or two.
>
> In Python 3, file offsets use the int type, which can be as big as you
> like.

That's what it looked like at first brush yesterday.
Now my Lazarus GUI has to call a Python3 helper pgm
to do the seeks and create a file-o-binary form
consumption.

>> The GCC lib - sometimes requiring special flags -
>> claims it'll do 64-bit seeks - but I haven't
>> confirmed that yet either.
>
> In C, on a 64-bit Linux platform, all of lseek, fseek and fseeko will
> use 64-bit offsets (since long and off_t are both 64 bits on such
> platforms).
>
> https://man7.org/linux/man-pages/man2/lseek.2.html
> https://man7.org/linux/man-pages/man3/fseek.3.html
> https://man7.org/linux/man-pages/man3/ftello.3.html

Trying to search it I kept running into odd flags
and pragmas and such that might need to be added
to make sure it was using 64-bits. At the rate
things are going they might just wanna bite it
and go to 128-bit values for all their file stuff.

In any case I'll re-do the helper pgm in 'C' today
and experiment. Python is a bit weird with binary
(not TOO bad in this specific case) but 'C' is
always happy.

> If you have 32-bit platform still, you have a couple of options, but the
> sensible one is: bin it and get a computer that hasn’t been obsolete for
> the last 15 years.

There isn't much that ain't 64 bit these days.

On 2/22/23 07:14, 25B.E866 wrote:
> On 2/22/23 3:55 AM, Richard Kettlewell wrote:
>> "25B.E866" <25B.E866@noaaba.net> writes:
>>> I arrived at a need to search hard drives - like
>>> up to 16 terabyte hard drives - AND kinda show what's
>>> going on. THE problem is that if you need to look at
>>> a SPECIFIC spot on the disk the usual "seek()"
>>> functions crap out - limited to longint (about 2.4
>>> gig). Free Pascal CLAIMS its fseek() will take an
>>> int64 ... but in practice I see the exact same bits
>>> of the disk come up again, which means it's rolling
>>> over. Just started experimenting with Python - I'll
>>> know in a day or two.
>>
>> In Python 3, file offsets use the int type, which can be as big as you
>> like.
>
>   That's what it looked like at first brush yesterday.
>   Now my Lazarus GUI has to call a Python3 helper pgm
>   to do the seeks and create a file-o-binary form
>   consumption.
>
>>> The GCC lib - sometimes requiring special flags -
>>> claims it'll do 64-bit seeks - but I haven't
>>> confirmed that yet either.
>>
>> In C, on a 64-bit Linux platform, all of lseek, fseek and fseeko will
>> use 64-bit offsets (since long and off_t are both 64 bits on such
>> platforms).
>>
>> https://man7.org/linux/man-pages/man2/lseek.2.html
>> https://man7.org/linux/man-pages/man3/fseek.3.html
>> https://man7.org/linux/man-pages/man3/ftello.3.html
>
>   Trying to search it I kept running into odd flags
>   and pragmas and such that might need to be added
>   to make sure it was using 64-bits. At the rate
>   things are going they might just wanna bite it
>   and go to 128-bit values for all their file stuff.
>
>   In any case I'll re-do the helper pgm in 'C' today
>   and experiment. Python is a bit weird with binary
>   (not TOO bad in this specific case) but 'C' is
>   always happy.
>
>> If you have 32-bit platform still, you have a couple of options, but the
>> sensible one is: bin it and get a computer that hasn’t been obsolete for
>> the last 15 years.
>
>   There isn't much that ain't 64 bit these days.
` Any there is not much that 32 bits cannot do but it will be an
inconvenience. Used 64 bit machines are cheap even refurbished. And
if you have to deal with very large disks then get a Newer machine.

bliss-“Nearly any fool can use a GNU/Linux computer. Many do.”
After all here I am... Again

--
bliss dash SF 4 ever at dslextreme dot com

On 22/02/2023 16:52, Bobbie Sellers wrote:
> On 2/22/23 07:14, 25B.E866 wrote:
>> On 2/22/23 3:55 AM, Richard Kettlewell wrote:
>>> "25B.E866" <25B.E866@noaaba.net> writes:
>>>> I arrived at a need to search hard drives - like
>>>> up to 16 terabyte hard drives - AND kinda show what's
>>>> going on. THE problem is that if you need to look at
>>>> a SPECIFIC spot on the disk the usual "seek()"
>>>> functions crap out - limited to longint (about 2.4
>>>> gig). Free Pascal CLAIMS its fseek() will take an
>>>> int64 ... but in practice I see the exact same bits
>>>> of the disk come up again, which means it's rolling
>>>> over. Just started experimenting with Python - I'll
>>>> know in a day or two.
>>>
>>> In Python 3, file offsets use the int type, which can be as big as you
>>> like.
>>
>>    That's what it looked like at first brush yesterday.
>>    Now my Lazarus GUI has to call a Python3 helper pgm
>>    to do the seeks and create a file-o-binary form
>>    consumption.
>>
>>>> The GCC lib - sometimes requiring special flags -
>>>> claims it'll do 64-bit seeks - but I haven't
>>>> confirmed that yet either.
>>>
>>> In C, on a 64-bit Linux platform, all of lseek, fseek and fseeko will
>>> use 64-bit offsets (since long and off_t are both 64 bits on such
>>> platforms).
>>>
>>> https://man7.org/linux/man-pages/man2/lseek.2.html
>>> https://man7.org/linux/man-pages/man3/fseek.3.html
>>> https://man7.org/linux/man-pages/man3/ftello.3.html
>>
>>    Trying to search it I kept running into odd flags
>>    and pragmas and such that might need to be added
>>    to make sure it was using 64-bits. At the rate
>>    things are going they might just wanna bite it
>>    and go to 128-bit values for all their file stuff.
>>
>>    In any case I'll re-do the helper pgm in 'C' today
>>    and experiment. Python is a bit weird with binary
>>    (not TOO bad in this specific case) but 'C' is
>>    always happy.
>>
>>> If you have 32-bit platform still, you have a couple of options, but the
>>> sensible one is: bin it and get a computer that hasn’t been obsolete for
>>> the last 15 years.
>>
>>    There isn't much that ain't 64 bit these days.
>
> `    Any there is not much that 32 bits cannot do but it will be an
> inconvenience.  Used 64 bit machines are cheap even refurbished.  And
> if you have to deal with very large disks then get a Newer machine.
>
I think that ARM based boards only recently went 64bit
Not sure about other embedded style kit.

--
It is the folly of too many to mistake the echo of a London coffee-house
for the voice of the kingdom.

Jonathan Swift

On 2/22/23 08:52, Bobbie Sellers wrote:
> On 2/22/23 07:14, 25B.E866 wrote:
>> On 2/22/23 3:55 AM, Richard Kettlewell wrote:
>>> "25B.E866" <25B.E866@noaaba.net> writes:
>>>> I arrived at a need to search hard drives - like
>>>> up to 16 terabyte hard drives - AND kinda show what's
>>>> going on. THE problem is that if you need to look at
>>>> a SPECIFIC spot on the disk the usual "seek()"
>>>> functions crap out - limited to longint (about 2.4
>>>> gig). Free Pascal CLAIMS its fseek() will take an
>>>> int64 ... but in practice I see the exact same bits
>>>> of the disk come up again, which means it's rolling
>>>> over. Just started experimenting with Python - I'll
>>>> know in a day or two.
>>>
>>> In Python 3, file offsets use the int type, which can be as big as you
>>> like.
>>
>>    That's what it looked like at first brush yesterday.
>>    Now my Lazarus GUI has to call a Python3 helper pgm
>>    to do the seeks and create a file-o-binary form
>>    consumption.
>>
>>>> The GCC lib - sometimes requiring special flags -
>>>> claims it'll do 64-bit seeks - but I haven't
>>>> confirmed that yet either.
>>>
>>> In C, on a 64-bit Linux platform, all of lseek, fseek and fseeko will
>>> use 64-bit offsets (since long and off_t are both 64 bits on such
>>> platforms).
>>>
>>> https://man7.org/linux/man-pages/man2/lseek.2.html
>>> https://man7.org/linux/man-pages/man3/fseek.3.html
>>> https://man7.org/linux/man-pages/man3/ftello.3.html
>>
>>    Trying to search it I kept running into odd flags
>>    and pragmas and such that might need to be added
>>    to make sure it was using 64-bits. At the rate
>>    things are going they might just wanna bite it
>>    and go to 128-bit values for all their file stuff.
>>
>>    In any case I'll re-do the helper pgm in 'C' today
>>    and experiment. Python is a bit weird with binary
>>    (not TOO bad in this specific case) but 'C' is
>>    always happy.
>>
>>> If you have 32-bit platform still, you have a couple of options, but the
>>> sensible one is: bin it and get a computer that hasn’t been obsolete for
>>> the last 15 years.
>>
>>    There isn't much that ain't 64 bit these days.
>
> `    And there is not much that 32 bits cannot do but it will be an
> inconvenience.  Used 64 bit machines are cheap even refurbished.  And
> if you have to deal with very large disks then get a Newer machine.
>
> bliss-“Nearly any fool can use a GNU/Linux computer. Many do.”
>         After all here I am... Again
> "Any" corrected to "And"
But with large disks you should get a fast processor as well as
newer. I think an i7 with at least 4 cores or the Ryzen series with
multiple cores. 6 or 8 in a notebook or laptop (desktop replacement).

bliss
--
bliss dash SF 4 ever at dslextreme dot com

On 2/22/23 9:11 AM, Richard Kettlewell wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>> On 22/02/2023 08:55, Richard Kettlewell wrote:
>>> you have a couple of options, but the
>>> sensible one is: bin it and get a computer that hasn’t been obsolete for
>>> the last 15 years.
>>
>> LOL. Is it THAT long ago?
>
> Opteron release was 2003. That didn’t necessarily make 32-bit x86
> obsolete overnight but the writing was on the wall.

And a computer-shop guru in the Atari/C64 days once asked
me why there would be any use for 16 or (horrors!) 32 bit
processors :-)

Just a followup ... proper 64-bit seeking WAS possible
with Python3. Compiled it with pyinstaller. Alas the
throughput between the main pgm and the helper was crappy.

However I re-did it in 'C' ... and there was more than a
50X speed improvement doing essentially identical steps
with the same read/write blocksize. Upped the blocksize
from 128kb to 256kb and it picked up to about 70x the
Python speed. Going to 512kb didn't yield much improvement.

Saving/reading the tempfile in a RAMdisk would likely give
a good performance boost - but you've gotta set up a
RAMdisk ..... I forget, is /tmp actually a RAMdisk
in Deb derivatives ? I'll check.

Now I suspect 'pyinstaller' isn't REALLY a "compiler"
per-se but instead a way of encapsulating the Py
interpreter and needed libs inside one executable.
I'll give Cython and Nutika a shot, just to be fair.

'C' notes ... some compiler directives about using
large files and deffing something as 64 bits were
required. ALSO, fopen() and fseek() kept throwing
seg errors - had to switch to open() and lseek64().
I don't think fopen() could even open "/dev/sdb" or
whatever, but open() did it easily.

Even now, most good old gcc libs are oriented around
longints. Had to dig a bit for odd variable type
defs in the libs and lesser-documented functions
to get it all working right. FPC didn't even have
a StrToInt64() - had to write one (and a Int64ToHex()
as well).

Anyway, 'C' beat the snot out of Python here ...
a 5mb 'compiled' py pgm -vs- 15kb 'C' pgm.

On 2/22/23 8:38 AM, The Natural Philosopher wrote:
> On 22/02/2023 08:55, Richard Kettlewell wrote:
>> you have a couple of options, but the
>> sensible one is: bin it and get a computer that hasn’t been obsolete for
>> the last 15 years.
>
> LOL. Is it THAT long ago?

Even longer really ... more like 20 years.

Events tend to move on more quickly than people.

I think 64-bit uPs came out around 2003/2004 with AMD getting
first credit.

DID solve my 64-bit file-seek problem, albeit a bit
weirdly. First a Python "helper" pgm, then re-did
it in 'C' (there were weird issues) and it was 50+
times faster. Anyway, the Free Pascal seek(), despite
docs, does NOT seem to be 64-bit, just longint. NOT
big enough at all. 20+ year old thinking there .......

Hey, I wanted/needed to seek/read anywhere on a 16tb
hdd. Some could manage that, others couldn't.

On 2023-02-23, 25B.E866 <25B.E866@noaaba.net> wrote:
> On 2/22/23 8:38 AM, The Natural Philosopher wrote:
>> On 22/02/2023 08:55, Richard Kettlewell wrote:
>>> you have a couple of options, but the
>>> sensible one is: bin it and get a computer that hasn’t been obsolete for
>>> the last 15 years.
>>
>> LOL. Is it THAT long ago?
>
> Even longer really ... more like 20 years.

Well, not quite that long, unless you were into high-end
hardware.

23 years ago, a 64-bit machine would have been something like a
US$8k Alpha UP2000 machine.

20 years ago plus or minus a month or so, the Alpha machine
developed a hardware problem with the motherboard, and the board
needed to be shipped back east for repairs (came back with a few
blue wires and a new chip or two). Its "temporary" replacement
was a machine with a $150-180 Pentium 4A, which was definitely
_NOT_ 64-bit. (I was on the design team, so I would have known.)

I don't remember exactly when, but it was at least a few years
after that that a consumer-grade 64-bit machine became available.

--
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

On 2/22/23 21:11, Robert Riches wrote:
> On 2023-02-23, 25B.E866 <25B.E866@noaaba.net> wrote:
>> On 2/22/23 8:38 AM, The Natural Philosopher wrote:
>>> On 22/02/2023 08:55, Richard Kettlewell wrote:
>>>> you have a couple of options, but the
>>>> sensible one is: bin it and get a computer that hasn’t been obsolete for
>>>> the last 15 years.
>>>
>>> LOL. Is it THAT long ago?
>>
>> Even longer really ... more like 20 years.
>
> Well, not quite that long, unless you were into high-end
> hardware.
>
> 23 years ago, a 64-bit machine would have been something like a
> US$8k Alpha UP2000 machine.
>
> 20 years ago plus or minus a month or so, the Alpha machine
> developed a hardware problem with the motherboard, and the board
> needed to be shipped back east for repairs (came back with a few
> blue wires and a new chip or two). Its "temporary" replacement
> was a machine with a $150-180 Pentium 4A, which was definitely
> _NOT_ 64-bit. (I was on the design team, so I would have known.)
>
> I don't remember exactly when, but it was at least a few years
> after that that a consumer-grade 64-bit machine became available.
>
I got mine on sale about 20o6 a Pentium single core laptop for $500.

It had XP and I used that to run an Amiga Emulation which was
a Just In Time translator running on a Knoppix base which translated
68000 instructions to x86 codes and at the time was the very fastest
Amiga ever seen at 2.4 GH.
This was the machine I first ran Mandriva 2006 on.
It did not have staying power and only lasted about
4.5 years.

bliss - on the ever-faithful Dell Latitude E7450, PCLinuxOS 2022
KDE Plasma 5.27.1 Kernel Version: 6.1.13-pclos1 (64-bit)
KDE Frameworks 5.103.0 - Qt Version: 5.15.6
Graphics : X11 - Mesa Intel® HD Graphics 5500
15.5 GiB of RAM CPU 4 × Intel® Core™ i7-5600U CPU @ 2.60GHz
Actually 2 real cores and 2 virtual cores.

--
bliss dash SF 4 ever at dslextreme dot com

On 2/23/23 12:11 AM, Robert Riches wrote:
> On 2023-02-23, 25B.E866 <25B.E866@noaaba.net> wrote:
>> On 2/22/23 8:38 AM, The Natural Philosopher wrote:
>>> On 22/02/2023 08:55, Richard Kettlewell wrote:
>>>> you have a couple of options, but the
>>>> sensible one is: bin it and get a computer that hasn’t been obsolete for
>>>> the last 15 years.
>>>
>>> LOL. Is it THAT long ago?
>>
>> Even longer really ... more like 20 years.
>
> Well, not quite that long, unless you were into high-end
> hardware.
>
> 23 years ago, a 64-bit machine would have been something like a
> US$8k Alpha UP2000 machine.

But the Cutting-Edgers/Gamers DID pay ...... often, I
suspect, for the same reasons involved in having THE
Latest i-Phone (and preferably taking a selfie out in
front of the Apple store) - BRAGGING RIGHTS.

We tend to denigrate the Gamers - but they, and their $$$,
tend to push along and lower the prices of the hardware.

I *do* remember when the 386 was billed as "aimed-at/
only-needed for high-end servers" ..... a year later
they were cheap and everywhere, mostly because of the
Gamers. My boss was impressed when I told him they
could do over One-MIPs ... felt he'd entered
SuperComputerLand :-) Then I went down to an
electronics-repair place we used and got some
new crystals and made it 1.5 MIPs (with homebrew
heatsinks made from Pepsi cans ... )

> 20 years ago plus or minus a month or so, the Alpha machine
> developed a hardware problem with the motherboard, and the board
> needed to be shipped back east for repairs (came back with a few
> blue wires and a new chip or two). Its "temporary" replacement
> was a machine with a $150-180 Pentium 4A, which was definitely
> _NOT_ 64-bit. (I was on the design team, so I would have known.)
>
> I don't remember exactly when, but it was at least a few years
> after that that a consumer-grade 64-bit machine became available.

The Core2 derivatives were, as I remember, the first
really affordable 64-bitters worth having. Still have
a Core2-Quad that's STILL doing some useful work - running
Bullseye-64 at this point. Those chips were surprisingly
spry and would still run 8-bit code - even native CP/M-86.

On 23/02/2023 05:49, 25B.E866 wrote:
> The Core2 derivatives were, as I remember, the first
>   really affordable 64-bitters worth having

I cant remember what I had first. Probably a celeron? Dunno.
I remember people saying that 64 bits wasn't any faster, took up more
space for files and so loaded slower, and so on. Lots of religion.

ISTR I slung Debian on one at 64 bits and it worked. And was faster at
my slowest job - video editing, so I never looked back.

Currently running a secondhand quadcore I5. It does everything I need
fast enough except video editing, and I haven't done much of that recently

--
“It is hard to imagine a more stupid decision or more dangerous way of
making decisions than by putting those decisions in the hands of people
who pay no price for being wrong.”

Thomas Sowell

The Natural Philosopher <tnp@invalid.invalid> writes:
> On 23/02/2023 05:49, 25B.E866 wrote:
>> The Core2 derivatives were, as I remember, the first
>>   really affordable 64-bitters worth having
>
> I cant remember what I had first. Probably a celeron? Dunno.
> I remember people saying that 64 bits wasn't any faster, took up more
> space for files and so loaded slower, and so on. Lots of religion.

The change that might, in theory, have negatively impacted performance
was the doubling of the size of pointers. An application that used a lot
of pointers would use more memory and therefore have more cache misses
(at multiple levels of the memory hierarchy), and a cache miss can leave
a CPU idle (or at least, pursuing speculative execution paths which
don’t pay off) for huge numbers of cycles.

In practice I never noticed anything I could attribute to that, and
everything else was getting faster at the same time (SSDs were coming in
for example).

> ISTR I slung Debian on one at 64 bits and it worked. And was faster at
> my slowest job - video editing, so I never looked back.

A good example of the kind of application which I’d expect to get a
small benefit (though the real wins in that case are likely to come from
vectorization, which I think is the same in the 32- and 64-bit ISAs).

--
https://www.greenend.org.uk/rjk/

On 24/02/2023 13:13, The Natural Philosopher wrote:
> On 23/02/2023 05:49, 25B.E866 wrote:
>> The Core2 derivatives were, as I remember, the first
>>    really affordable 64-bitters worth having
>
> I cant remember what I had first. Probably a celeron? Dunno.
> I remember people saying that 64 bits wasn't any faster, took up more
> space for files and so loaded slower, and so on. Lots of religion.
>
> ISTR I slung Debian on one at 64 bits and it worked. And was faster at
> my slowest job - video editing, so I never looked back.
>
> Currently running a secondhand quadcore I5. It does everything I need
> fast enough except video editing, and I haven't done much of that recently
>

My first was an Athlon 64, I had a 64 bit version of Windows XP. Getting
drivers was a bit dodgy.

As for keeping old hardware, I recently bought an Orange Pi 5, with a
desktop speed that feels comparable with a 2012 Sandy Bridge i5 2500K,
except it idles at 2 watts. If the GPU driver didn't crash/freeze the
desktop every couple of hours, the oPi5 would be a stunning machine.

On 2023-02-22 07:52, 25B.E866 wrote:
> I arrived at a need to search hard drives - like
> up to 16 terabyte hard drives - AND kinda show what's
> going on. THE problem is that if you need to look at
> a SPECIFIC spot on the disk the usual "seek()"
> functions crap out - limited to longint (about 2.4
> gig). Free Pascal CLAIMS its fseek() will take an
> int64 ... but in practice I see the exact same bits
> of the disk come up again, which means it's rolling
> over. Just started experimenting with Python - I'll
> know in a day or two.

You should ask at the Lazarus mail list:

List-Id: Lazarus mailing list <lazarus.lists.lazarus-ide.org>
List-Unsubscribe: <https://lists.lazarus-ide.org/options/lazarus>,
<mailto:lazarus-request@lists.lazarus-ide.org?subject=unsubscribe>
List-Archive: <http://lists.lazarus-ide.org/pipermail/lazarus/>
List-Post: <mailto:lazarus@lists.lazarus-ide.org>
List-Help: <mailto:lazarus-request@lists.lazarus-ide.org?subject=help>
List-Subscribe: <https://lists.lazarus-ide.org/listinfo/lazarus>,
<mailto:lazarus-request@lists.lazarus-ide.org?subject=subscribe>

--
Cheers, Carlos.

On 2/24/23 8:13 AM, The Natural Philosopher wrote:
> On 23/02/2023 05:49, 25B.E866 wrote:
>> The Core2 derivatives were, as I remember, the first
>>    really affordable 64-bitters worth having
>
> I cant remember what I had first. Probably a celeron? Dunno.

They were ... ummm ... "ok" - but basically a "laptop chip".

> I remember people saying that 64 bits wasn't any faster, took up more
> space for files and so loaded slower, and so on. Lots of religion.

64-bits is faster if the APPS are writ for 64-bits.

> ISTR I slung Debian on one at 64 bits and it worked. And was faster at
> my slowest job - video editing, so I never looked back.
>
> Currently running a secondhand quadcore I5. It does everything I need
> fast enough except video editing, and I haven't done much of that recently

Those are perfectly good for almost anything, and notably
cheaper than i7's these days. The newer i5's are now
hexcore however.

Gen12 i5s are generally faster than Gen8/9 I7's.

Oh yea ... sometimes when I've nothing to do I tend
to benchmark things. One thing I've consistently
noticed is that lots of apps are NOT writ to take
proper advantage of multiple cores. The OS does
what it can, but often it's not much. You'll see
one core at 250% and all the others just sitting
there doing nothing. So, my advice for now, value
the CPU clockspeed over the number of cores/threads.
A low-end 2ghz with lots of cores/threads will often
be blown away by a high-end 4+ghz chip with fewer.

On 2/24/23 10:13 AM, Pancho wrote:
> On 24/02/2023 13:13, The Natural Philosopher wrote:
>> On 23/02/2023 05:49, 25B.E866 wrote:
>>> The Core2 derivatives were, as I remember, the first
>>>    really affordable 64-bitters worth having
>>
>> I cant remember what I had first. Probably a celeron? Dunno.
>> I remember people saying that 64 bits wasn't any faster, took up more
>> space for files and so loaded slower, and so on. Lots of religion.
>>
>> ISTR I slung Debian on one at 64 bits and it worked. And was faster at
>> my slowest job - video editing, so I never looked back.
>>
>> Currently running a secondhand quadcore I5. It does everything I need
>> fast enough except video editing, and I haven't done much of that
>> recently
>>
>
> My first was an Athlon 64, I had a 64 bit version of Windows XP. Getting
> drivers was a bit dodgy.

Yea .. XP64 was kinda "ahead of its time". Drivers
were VERY hard to find. As such it never became
very popular. I have a VM with it ... but almost
never fire it up.

> As for keeping old hardware, I recently bought an Orange Pi 5, with a
> desktop speed that feels comparable with a 2012 Sandy Bridge i5 2500K,
> except it idles at 2 watts. If the GPU driver didn't crash/freeze the
> desktop every couple of hours, the oPi5 would be a stunning machine.

I just experimented with an Orange (mostly because real rPIs
are almost impossible to get due to China problems). It's not
a terrible board - but the one I bought did not have built-in
WiFi and using a USB wifi SUCKED ROCKS - insanely slow. Did
find a use for it, but it's gotta be plug-in networking.

Just got in a RockPI-4c ... I'll see if it's mo-better.