Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Two heads are better than one. -- John Heywood


interests / soc.culture.china / More of my philosophy about the StopWatch and and more about x86 and ARM processors and about the technicality about the Timer and about solar cells and about AES 256 encryption and TSMC and about China and about the Transformers and about Toyota and

SubjectAuthor
o More of my philosophy about the StopWatch and and more about x86 andAmine Moulay Ramdane

1
More of my philosophy about the StopWatch and and more about x86 and ARM processors and about the technicality about the Timer and about solar cells and about AES 256 encryption and TSMC and about China and about the Transformers and about Toyota and

<75f938c7-9e93-4107-af9e-8d0250303235n@googlegroups.com>

  copy mid

https://www.novabbs.com/interests/article-flat.php?id=13580&group=soc.culture.china#13580

  copy link   Newsgroups: soc.culture.china
X-Received: by 2002:a05:622a:1897:b0:403:a4d3:98eb with SMTP id v23-20020a05622a189700b00403a4d398ebmr16422qtc.3.1688935606630;
Sun, 09 Jul 2023 13:46:46 -0700 (PDT)
X-Received: by 2002:a17:903:441:b0:1ad:fa23:dd87 with SMTP id
iw1-20020a170903044100b001adfa23dd87mr10848772plb.5.1688935605941; Sun, 09
Jul 2023 13:46:45 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: soc.culture.china
Date: Sun, 9 Jul 2023 13:46:45 -0700 (PDT)
Injection-Info: google-groups.googlegroups.com; posting-host=66.131.174.130; posting-account=R-6XjwoAAACnHXTO3L-lyPW6wRsSmYW9
NNTP-Posting-Host: 66.131.174.130
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <75f938c7-9e93-4107-af9e-8d0250303235n@googlegroups.com>
Subject: More of my philosophy about the StopWatch and and more about x86 and
ARM processors and about the technicality about the Timer and about solar
cells and about AES 256 encryption and TSMC and about China and about the
Transformers and about Toyota and
From: amine...@gmail.com (Amine Moulay Ramdane)
Injection-Date: Sun, 09 Jul 2023 20:46:46 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 35694
 by: Amine Moulay Ramdane - Sun, 9 Jul 2023 20:46 UTC

Hello,

More of my philosophy about the StopWatch and and more about x86 and ARM processors and about the technicality about the Timer and about solar cells and about AES 256 encryption and TSMC and about China and about the Transformers and about Toyota and about China and about objective truth and about the objective and about the paper about the multiple universes and about quantum world and about consciousness and about mathematics and about the universe and about mathematical probability and about the positive behavior and about the positive mindset and about patience and about the positive energy and about the "packaging" or "presentation" and about the ideal and about the being idealistic and more of my thoughts..

I am a white arab from Morocco, and i think i am smart since i have also
invented many scalable algorithms and algorithms..

I think i am highly smart since I have passed two certified IQ tests and i have scored above 115 IQ, and i mean that it is "above" 115 IQ, so i have just done
the calculations, and i think that approximation in microhertz of the following StopWatch is really good, and you can even use the same method and obtain a really good approximation in nanohertz too, but i think that the
problem is that he is not taking into account the overflow of the Time Stamp Counter (TSC) with getCPUticks(), and here is his StopWatch:

https://www.davdata.nl/math/timer.html

So i think my StopWatch uses a different method and it avoids the overflow of the Time Stamp Counter (TSC) , and i have just made it support both x86 32 bit and x64 64 bit CPUs and it supports both Delphi and Freepascal compilers and it works in both Windows and Linux, so what is good about my new StopWatch is that it shows how you implement it from the low level layers in assembler etc., so i invite you to look at the new version of my source code that you can download from my website here:

https://sites.google.com/site/scalable68/a-portable-timer-for-delphi-and-freepascal

So I have just thought more and i think i will not support ARM in my new StopWatch, since ARM processors don't support like a Time Stamp Counter (TSC) in x86 processors that is compatible with previous 32 bit and 64 bit CPUs , so ARM has many important weaknesses , so the first important weakness is the following:

There is no single generic method that can be universally applied to all Arm processors for measuring time in CPU clocks. The available timing mechanisms and registers can vary significantly across different Arm processor architectures, models, and specific implementations.

In general, Arm processors provide various timer peripherals or system registers that can be used for timing purposes. However, the specific names, addresses, and functionalities of these timers can differ between different processors.

To accurately measure time in CPU clocks on a specific Arm processor, you would need to consult the processor's documentation or technical reference manual. These resources provide detailed information about the available timers, their registers, and how to access and utilize them for timing purposes.

It's worth noting that some Arm processors may provide performance monitoring counters (PMCs) that can be used for fine-grained timing measurements. However, the availability and usage of PMCs can also vary depending on the specific processor model.

Therefore, to achieve accurate and reliable timing measurements in CPU clocks on a particular Arm processor, it's crucial to refer to the documentation and resources provided by the processor manufacturer for the specific processor model you are targeting.

And the other weaknesses of ARM processors are the following:

I have just looked at the following articles about Rosetta 2 and the benchmarks of Apple Silicon M1 Emulating x86:

https://www.computerworld.com/article/3597949/everything-you-need-to-know-about-rosetta-2-on-apple-silicon-macs.html

and read also here:

https://www.macrumors.com/2020/11/15/m1-chip-emulating-x86-benchmark/

But i think that the problem with Apple Silicon M1 and the next Apple SiliconM2 is that Rosetta 2 only lets you run x86–64 macOS apps. That would be apps that were built for macOS (not Windows) and aren't 32-bit. The macOS restriction eliminates huge numbers of Windows apps, and 64-bit restriction eliminates even more.

Also read the following:

Apple says new M2 chip won’t beat Intel’s finest

Read more here:

https://www.pcworld.com/article/782139/apple-m2-chip-wont-beat-intels-finest.html

And here is what i am saying on my following thoughts about technology about Arm Vs. X86:

More of my philosophy about the Apple Silicon and about Arm Vs. X86 and more of my thoughts..

I invite you to read carefully the following interesting article so
that to understand more:

Overhyped Apple Silicon: Arm Vs. X86 Is Irrelevant

https://seekingalpha.com/article/4447703-overhyped-apple-silicon-arm-vs-x86-is-irrelevant

More of my philosophy about code compression of RISC-V and ARM and more of my thoughts..

I think i am highly smart, and i have just read the following paper
that says that RISC-V Compressed programs are 25% smaller than RISC-V programs, fetch 25% fewer instruction bits than RISC-V programs, and incur fewer instruction cache misses. Its code size is competitive with other compressed RISCs. RVC is expected to improve the performance and energy per operation of RISC-V.

Read more here to notice it:

https://people.eecs.berkeley.edu/~krste/papers/waterman-ms.pdf

So i think RVC has the same compression as ARM Thumb-2, so i think
that i was correct in my previous thoughts , read them below,
so i think we have now to look if the x86 or x64 are still more cache friendly even with Thumb-2 compression or RVC.

More of my philosophy of who will be the winner, x86 or x64 or ARM and more of my thoughts..

I think i am highly smart, and i think that since x86 or x64 has complex instructions and ARM has simple instructions, so i think that x86 or x64 is more cache friendly, but ARM has wanted to solve the problem by compressing the code by using Thumb-2 that compresses the code, so i think Thumb-2 compresses the size of the code by around 25%, so i think
we have to look if the x86 or x64 are still more cache friendly even with Thumb-2 compression, and i think that x86 or x64 will still optimize more the power or energy efficiency, so i think that there remains that since x86 or x64 has other big advantages, like the advantage that i am talking about below, so i think the x86 or x64 will be still successful big players in the future, so i think it will be the "tendency". So i think that x86 and x64 will be good for a long time to make money in business, and they will be good for business for USA that make the AMD or Intel CPUs.

More of my philosophy about x86 or x64 and ARM architectures and more of my thoughts..

I think i am highly smart, and i think that x86 or x64 architectures
has another big advantage over ARM architecture, and it is the following:

"The Bright Parts of x86

Backward Compatibility

Compatibility is a two-edged sword. One reason that ARM does better in low-power contexts is that its simpler decoder doesn't have to be compatible with large accumulations of legacy cruft. The downside is that ARM operating systems need to be modified for every new chip version.

In contrast, the latest 64-bit chips from AMD and Intel are still able to boot PC DOS, the 16-bit operating system that came with the original IBM PC. Other hardware in the system might not be supported, but the CPUs have retained backward compatibility with every version since 1978.

Many of the bad things about x86 are due to this backward compatibility, but it's worth remembering the benefit that we've had as a result: New PCs have always been able to run old software."

Read more here on the following web link so that to notice it:

https://www.informit.com/articles/article.aspx?p=1676714&seqNum=6

So i think that you can not compare x86 or x64 to ARM, since it is
not just a power efficiency comparison, like some are doing it by comparing
the Apple M1 Pro ARM CPU to x86 or x64 CPUs, it is why i think that x86 or x64 architectures will be here for a long time, so i think that they will be good for a long time to make money in business, and they are a good business for USA that make the AMD or Intel CPUs.

More of my philosophy about weak memory model and ARM and more of my thoughts..

I think ARM hardware memory model is not good, since it is a
weak memory model, so ARM has to provide us with a TSO memory
model that is compatible with x86 TSO memory model, and read what Kent Dickey is saying about it in my following writing:

ProValid, LLC was formed in 2003 to provide hardware design and verification consulting services.

Kent Dickey, founder and President, has had 20 years experience in hardware design and verification. Kent worked at Hewlett-Packard and Intel Corporation, leading teams in ASIC chip design and pre-silicon and post-silicon hardware verification. He architected bus interface chips for high-end servers at both companies. Kent has received more than 10 patents for innovative work in both design and verification.

Read more here about him:

https://www.provalid.com/about/about.html

And read the following thoughts of Kent Dickey about the weak memory model such as of ARM:

"First, the academic literature on ordering models is terrible. My eyes
glaze over and it's just so boring.

I'm going to guess "niev" means naive. I find that surprising since x86
is basically TSO. TSO is a good idea. I think weakly ordered CPUs are a
bad idea.


Click here to read the complete article
1
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor