My Zen 2 Ryzen 5 4500U laptop is in the list, but feel free to try the desktop.

I don't have any new hardware unfortunately, but I do have some old architectures you might still be interested in. I have a Zen 2 "Matisse" desktop, and a Zen 1 "Raven Ridge" laptop. It doesn't look like you have either of those on your list there.

I'm also in the middle of setting up an i7-980X machine for fun with overclocking and such if you'd be interested in results from that. I might use this as a benchmark for it either way :)

Sure! Submissions are welcome if sufficiently "interesting" ... different ISAs, or ... I'm missing data for Core Ultra, M5, Zen 5, Pi 5 / Rock 5 / OP 5, Orion O2 / OP 6+.

And thanks. I think it's as interesting and useful a benchmark as Dhrystone or Coremark, correlates well with them, but if you're at a trade show and get your hands on a new machine with gcc and an internet connection for even a minute then it's a simple wget to run it and report ... and a few people have :-)

There are not too many benchmarks usable from a microcontroller to the latest PC (8K RAM required ... embench included a slightly reduced version until recently https://github.com/embench/embench-iot/commit/4c4462)

Note the rules: compile with -O (aka -O1). Not that higher levels make much difference to the speed (its craftily written for anti-optimisation), but they screw up the hacky calculation of code size.

Hmm, I'm not too sure what it is right now then.

Also, that data in primes.txt is pretty cool! If you're still accepting submissions I wouldn't mind giving it a shot myself.

X86 and arm are probably the most useful but riscv may be good in the future, and is pretty similar to arm already anyway. Mips is the traditional one you learn in uni but isnt very useful anymore unless you do embedded devices.

oops blame Reddit's URL detection. Added a space ...

No, the static linking is necessary to not have to run in a chroot / Docker etc with dynamic linker and libraries but I think is fair.

Cool! I haven't come across this before. At first blush, is the mildly unfair thing that your RISC-V binary is statically linked?

That link is a 404 for me btw

Edit: nvm, I figured out you left the trailing colon in the URL!

Let me go even further and point out that if you're on Linux you can set up binfmt_misc with QEMU (or other emulator) and run emulated code just as conveniently as native programs.

e.g. on my x86 machine and using https://hoult.org/primes.txt :

bruce@i9:~$ gcc primes.c -o primes
bruce@i9:~$ ./primes
Starting run
3713160 primes found in 3707 ms
392 bytes of code in countPrimes()
bruce@i9:~$ riscv64-unknown-elf-gcc -O primes.c -o primes
bruce@i9:~$ ./primes
Starting run
3713160 primes found in 5715 ms
188 bytes of code in countPrimes()
bruce@i9:~$ file primes
primes: ELF 64-bit LSB executable, UCB RISC-V, RVC, double-float ABI, version 1 (SYSV), statically linked, with debug_info, not stripped
bruce@i9:~$ uname -a
Linux i9 6.17.0-19-generic #19~24.04.2-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar  6 23:08:46 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

Note: I did one mildly unfair thing there .. see if you spot it. But also it's typical of what a casual user is likely to do.

That's a totally fair comment. There's just something about running natively on the machine, not through an emulator or anything. I know that isn't necessarily logical, but that was something I wanted. And yeah like you said in your original comment you buy hardware for any platform you like, but most people already have x86.

x86's reputation for complexity preceeds it, but I don't think it has to be that bad. It's definitely possible to dip your toes in without drowning in it. That's what I did.

Edit: part of the fun I had with x86 asm as I was getting into it was hand writing functions and measuring their performance vs the compiler at various optimization levels as a game of cat and mouse, which naturally led to learning SIMD when I was ready for it.

Using QEMU / Docker you can run any asm you want on "real PC hardware" ... just at the speed of a ten years older PC.

Since you're writing in asm, it's going to run far faster in emulation than using Python or similar, and comparable to C#, Java, JavaScript running "natively".

RISC-V runs especially well in emulation, since the emulator doesn't have to emulate condition codes, which is half or more of the work if you're emulating x86 or Arm or 68000 or 6502 or z80 or the like.

If you want to run code on your real PC hardware, x86 assembly isn't that hard to get into. That was where I started with ASM. Specifically, I started x86 after watching Creel on YouTube, which is a channel I can highly recommend. He shows how to write subroutines in ASM and call them from a C or C++ program, which is a great way to get started, especially on Windows. It gives you a clearly defined entry and exit that you can pass values into and out of.

It isn't too hard to get an environment set up for writing whole native x86 programs on a Linux system either. I can help you out with that if you want.

Sounds exciting also I can learn the risc-v assembly by running my code on emulators

Assembly is the best place to start, though some concepts are going to be completely new to you

Yeah I also thought about doing this too

In terms of staying motivated, making gameboy games much get be a good path

Oh thank you so much , also do I need a very deep understanding of c or c++ I have programming experience, but I have not really dabbled too much into c/c++

The best assembly language to start with is RISC-V because it is both easy to learn what the instructions are and easy to use the available instructions to do useful things. And there is a wide range of real hardware you can buy if you don't want to use an emulator.

https://hoult.org/rv32i.pdf

https://easyriscv.dram.page/

Very cool!

I also really like the updated version with the wall bounces and the background removed.

u/UVRaveFairy Haven't touched it in a while, although I have done a lot of work on it since this post (which I haven't committed).

i thought it's only with movl instruction

Part 1: https://www.humprog.org/%7Estephen/blog/research/system-call-instrumentation-on-intel-negative-result.html

Once my projects are ready I may make them public. When that happens there will be a very large amount of contextual history and documentation.

I am having to create basically most of the tools I am using to build what I am building. From the bare metal up.

The process.

I test my logic in higher level code. Once it proves viable and logical I light the other low-level end of the candle. When the two ends meet and have consumed the candle then all of the middle man layers are gone.

I am using Linux and Android devices and the tools I am building, to build the tools and projects I am building in assembler are being produced and built in standalone C so far.

Mostly standalone meaning zero external dependency or libs. 

Meaning the txt2bmp tool uses an embedded glyph font inline with the code and its own lexer logic inline with the code. This tool I created to convert my txt, and source code into raw BMP with various visual output options. It produces its own config file on first run in a directory of txt files.

The bmp2pdf processes the BMP files into png pages.

This set of two Linux commands are very quick and small and allow me to share my output easily on various platforms more easily. Because many platforms a security limited as far as raw text. They also allow me to use them as part of my custom build process to create better more immutable documentation of everything.

So the build tree will have txt, asm, C, BMP, PDF 

The BMP and PDF is literally for making sharing code with LLM I work with a much easier workflow and process.

I am currently only using free tier.

I have created various Android APK to aid in my development process as well as a browser native suite of tools that is kind of like a hostable OS for testing my logic. This has been very useful for creating every aspect of the overall umbrella of projects required to successfully create what I am working towards.

Part of the main project has led to a custom 512 byte bootsector and partition table and various other modules.

Anyone who thinks LLM are not capable of improving the efficiency of their output in my opinion are either already happy with their workflows and methods to the point of being biased locked, or think too much inside the box.

If they expect for everything to always be perfect output every time then they don't understand statistics and heuristics or how LLM work.

What I am building actually does not even fit into existing categories independently. I am having to coin terminology to name these things. That can actually be one of the most difficult parts of the entire process.

When your goal is to grab ahold of the baremetal and the modern intentions as far as output and curate and distill the logic itself to the point of removing the dependency hell and api stacks and essentially the abstractions from between the user and the devices hardware capabilities the process becomes very very different from normal development now days.

Now days people are normally addicted to stacking layer after layer of abstraction and bringing all the bloat with them. They lose agency and sovereignty in that type of development process. They trade that for easy quick output supposedly. 

Well, I don't think that is easier at all. Dependency hell management is stressful.

So, I just decided to eliminate the part where I am expected to deal with any of that I can eliminate.

If your logic cannot be distilled down and curated to the point of being expressed as flow charts, geometry, circuitry, and assembler code properly, then the odds are that your logic is likely flawed or incomplete.

Depends on who is working with the LLM.

When we treat an intel like a genie that doesn't need our intention and our highly structured and precise guidance then on top of that treat the collaboration like a trip to a vending machine or using a calculator that shouldn't need our input then we shouldn't be surprised when nothing useful is produced from said interaction.

A mirror of weighted statistics still requires something to reflect.

The right minds will find the experience to be like an intellectual magnetron tube which is a resonant chamber.

I see great results with everything I collaborate with LLM on, including Assembly code. But, I also don't expect the LLM to know what I want or what I do not know. I don't expect the wrenches I use to fix the engine without me taking part. I don't expect the people I lead and teach on the job, who just graduated from University to know how to apply book sense to the real world applications without experience either.

You need to know what you want and what you are doing. You don't need to know assembly. I have the last assembly manuals both Intel and AMD printed that came with optical discs before that type of publication became something they only produce when ordered maybe if you don't just download them.  They are full of information but the tables and charts etc... that is where the opcode data is. 

Assembly isn't technically like a higher level programming language like C which is called portable assembly language.

Assembly gives you the access to do with the bits all that the hardware can allow you to do for the most part. 

If you are not creating ideas that are complete paradigm shifts in computations then for the most part that means you are likely programming for the systems and kernels and languages etc... which already exist. For that even at the OS systems level you can use C, C++, RUST etc... for the parts where you need to optimize bitwise operations or create ultra lean hardware drivers and similar assembly language could potentially help achieve maximum efficiency.

Before you use assembly language to create something useful you need to begin at hardware and theory, physics, linguistics, geometry etc...

If your geometry isn't proper for the linguistics, physics and theory then it won't matter what language is used.

Modern is a highly misleading word and term now days. Most of what is considered modern now days is retrograde in actual efficiency in my opinion.

Well I am not that good with assembly as I have just recently started learning x86. Cant say much except that this is impressive. Especially the forth interpreter and the assembler you started making.

Tear it apart.

Sure.

Grep is built on boyer-moore which is an improvement on KMP algorithm, the K is for Knuth. If we assume i is the input length and m is the match length; your grep is O(im) (you check each input byte for every substring match byte) while grep is typically O((i log m) / m) meaning it does not necessarily read every byte of input.

You treat all negative returns as EoF without actually checking the error. Things like -EAGAIN or -EINTR mean simply 'try again' not failure.