robko

> Are claudisms different from gptisms?

Sorry, no idea. I rarely use Claude.

> Why can't these authors tell ChatGPT to write with a different prose and avoid "delve", "crucial", etc?

The authors could do this, but that would contradict the reason for using ChatGPT, which is to do less work.

> Wizardlm writes these same things in all its answers too

WizardLM has inherited that from its instruction tuning dataset, which has been generated with ChatGPT: https://openreview.net/pdf?id=CfXh93NDgH

I agree. This article is clearly written with a generative language model. A few other telltale signs:

1. Repeating the same thing multiple times with slight variation:

* "allowing developers to fine-tune their applications and unlock the full potential of their underlying hardware, ultimately maximising vLLM performance." (fine-tune, unlock potential, maximize performance are all roughly the same thing)

* "AI and machine learning models" (AI and machine learning models are the same thing in the context of this article)

* "utilise multiple threads or cores" (Why differentiate between threads and cores?)

* "tailored to enhance computational efficiency and overall throughput" (efficiency and throughput are highly related)

* "a series of graphs and data visualisations" (all the data visualizations in this article are graphs)

* "more computational effort and time" (same thing)

* "significantly enhanced the performance and efficiency" (same thing)

* "ensuring efficient processing and superior performance for complex and demanding AI workloads" (same things)

2. Explaining what "rocBLAS" stands for multiple times.

3. Other ChatGPTisms:

* "offering a comprehensive view of [...]"

* "Let’s delve into the notable advancements achieved through [...]"

* "ensures quicker processing times, which is crucial for [...]"

* "effectively mitigated these impacts, maintaining [...]"

* "elucidate the impact of"

* "significantly enhanced"

* "These results underscore the critical role of [...]"

* "Key Aspects", "Key Observations", "Key findings"

So why is this bad? - Because it undermines the trust in the the article. We do not know whether the claims are actually true or whether they were just made up by ChatGPT.

> Loras are just as powerful as a finetuned model and you can train one in minutes even on consumer hardware.

Do you have some more details on training a LoRA in minutes? Last I tried, it took several hours on an RTX 3090, but I am sure there have been improvements since then.

In my experience, the canvas api is very slow and not well thought-out. For example, to create a native image object from raw pixels, you have to copy the pixels into an ImageData object, draw it to a canvas, create a data URL from the canvas and then load an image from that data URL.

I get 60ms in C. But in your code, the compiler might decide to remove most of the code since b is not used after being calculated. I checked the assembly code and it does not seem to be the case here, but it's still something to be aware of.

You can use both at once. Usually, you'd have something like 64x64 tiles in cache and use 4x4 or 8x8 tiles for SIMD.

I tried a few micro-optimizations, but they did not make a measurable difference, so I kept the code short instead. But maybe some JIT is particularly bad at loop hoisting, so it might make a difference there.

You are correct. The code is using an inefficient cache access pattern, so most of the time is spent waiting.

You probably won't get 100x faster without SIMD, but 10x is certainly doable. Unfortunately, SIMD.js support has been removed from Chrome and Firefox a while ago, even though it is not available in wasm to this day.

My guess is that the JS implementation of the worst-performing browser is having trouble with the non-1 for-loop steps. Doing 90-degree image rotation with fixed steps and some index calculations should work better (0.18 sec vs 1.5 sec for their implementation in node.js):

    for (var y = 0; y < height; y++)
        for (var x = 0; x < width; x++)
            b[x + y*width] = a[y + (width - 1 - x)*height];

Although that's still far from the theoretical maximum throughput because the cache utilization is really bad. If you apply loop tiling, it should be even faster. This problem is closely related to matrix transpose, so there is a great deal of research you can build upon.

EDIT: 0.07 seconds with loop tiling:

    for (var y0 = 0; y0 < height; y0 += 64){
        for (var x0 = 0; x0 < width; x0 += 64){
            for (var y = y0; y < y0 + 64; y++){
                for (var x = x0; x < x0 + 64; x++){
                    b[x + y*width] = a[y + (width - 1 - x)*height];

rand() [1] is not a secure source of randomness. I strongly recommend against using that password manager since it is not secure.

[1] https://github.com/oormicreations/OormiPass/blob/d1d2bf5100f...

Ah, the good old OpenGL fixed function pipeline, deprecated for over 11 years now.

For something a bit more modern, I'd recommend [0], but one might argue that old OpenGL is easier to learn since you don't have to setup your own shaders.

[0] https://learnopengl.com/Introduction

Interestingly, many browsers are still susceptible to this attack, for example when used in SVG files (WARNING: might crash your browser and/or operating system): https://jsfiddle.net/e3guLn08/

This method requires a video or at least multiple frames. It won't work for a single photo.

Are you already using GPU acceleration? I'm currently working on alpha matting for my master's thesis and found that it helps quite a lot.