About skipping, when you have 2 sequential data sections like
[Id <object> "section2" id 33] parts and similar names, let you express the elements after object in one path selection, without using blocks and reusing the same words: word/>>3/id returns 33. Excessive nesting is sometime also a problem and not all structures are better when nested, sometime they are better when expressed linearly...
(pardon
<< is really >>) The last usage I forgot to write is the SKIP to value or datatype. Let's take the first example and extend it [Id word word <object> data data id 33] the first part, as before, ends in object. With TO shifting you can have variable data length on the first segment of data and in the second just with word/>>object!/>>id. With this syntax a full horizontal navigation is possible in just one line.
*to skipping (pardon, I am in mobile in my bed)
This enhancement would let you navigate any type of structure and this night, while writing, I have realized you could even use this approach to have a path which returns a series AT position instead of an element of it. Think about having multiple
find expressed in one efficient and compact path.
@GiuseppeChillemi With all my honest, your proposal looks very ugly to me. And hard to read... not mentioning that its implementation would slow down all path access evaluations. Also having large records in pure block is not too good. Instead of your proposed perlism I would rather wanted to see
struct! datatype, which would be more memory friendly than block! and would provide named accessors to all values.
Or a proper in memory database, where you would not require artificial value skipping.
@GiuseppeChillemi what I mean by non-nested is
[1 2 3 4 5 6 7 8 9] vs [[1 2 3] [4 5 6] [7 8 9]]. Nesting, and keys vs positional values, add overhead, but also information. There is no single solution that it best in every case, so it will be interesting to see what comes of your work.
With target Windows I got an .exe
@xqlab I’ve just compiled Linux version on Linux (actually on macOS in Docker, but that’s just a Linux in disguise) and haven’t seen this problem.
BTW: the code is about 10 faster under windows10 than under macOS. Any idea about this difference?
Or maybe better gpu on windows?
For those wondering why Windows is faster than Mac OS, i have noticed this performance difference many times, as i run Windows and Linux under OSX via VMware Fusion. One massive difference between Windows and OSX is that Windows has a much faster file system, with read ahead and caching, and OSX is rather dumb in this area. So anything that involves reading data is going to be noticeably faster in Windows, and since Windows will keep a file in RAM even after you have closed the file (on the off-chance that it might be used again), second and later runs of the same program on Windows tend to be rather quick. In general the I/O on OSX is slow. This may be unrelated to why redCV has a performance difference, but there is no cleaner comparison than the same exact hardware!
I have a Mac and Windows version of my Beads compiler (Beads is a completely different kind of language than Red, a State-Action-Model graphical language), and it is baffling how the Windows version is so much faster at compilation compared to the Mac version, running on the same hardware! I think it boils down to Windows being highly optimized for I/O after so many versions, while OSX has pursued Realtime Audio Processing integration, and fancy typography as priorities along the way.
I have also noticed in my experience that Windows accessing files from a Windows fileserver is WAY slower than Windows accessing files from a Linux fileserver running CIFS, especially when the directory that is being accessed has thousands of files in it. And FreeBSD is even faster than Linux as a fileserver in this regard.
My experience is that the same Windows client has at least an order of magnitude speed improvement when accessing a large directory from a Linux fileserver when compared to the same directory on a Windows fileserver. Perhaps there's a way to speed up the Windows fileserver, but I would think the real-time protection would be running on the client machine.
Everyone I hear using the M1 are a bit shocked at how fast it is, even on a Mac that only has 8 GB RAM. The key to the design is very wide memory buses and of course having all the memory right on the main chip. Also, each CPU core can saturate the memory controller that can handle around 60-70 GB/s. An intel/AMD CPU core can only do 15-25 GB/s. That's pretty astounding.
Then of course is the low TDP of less than 30 W can make it do long running tasks with little cooling needed. The GPU isn't very powerful though. The cost is also presently only a maximum of 16 GB RAM.
What is even more interesting is that Mx series CPUs will grow much faster in the near future, if Apple's CPU speed ramp will be maintained from the earlier Ax CPUs. There's lots of low-hanging fruit left for Apple to pick.
Intel should worry for many other reasons, since they squandered their position for 7-8 years now. So far behind AMD now. The "upside" for them, is that Apple will also squander certain opportunities with the Mx series, such as producing open hardware at a reasonable price. That's not in their nature.
Intel has lost the entire Apple account, which was probably at least 5% of Intel's total business. So it's a big loss. They have been idling for years they didn't have any serious competition. Intel still has the best Quantum Physicists on the planet, and they are only one invention away from blowing away the world again. We are in the plateau region of the development curve, where almost nothing changes. If you put more than 10 cores in a chip you don't get much useful work out of it, so we are flattening out everywhere in the computer biz.
We are in the plateau region of the development curve, where almost nothing changes. If you put more than 10 cores in a chip you don't get much useful work out of it, so we are flattening out everywhere in the computer biz.
We have still a large margin of improvement in software. Algorithms are tuned for single processor tasks. Once they will move to multi-core operations we will see again a lot of improvements.
What’s problematic OTOH is locating such sign on most keyboards. With $ it’s much easier.
¤ was part of money's design discussion, and I have it in my
format exploration. In addition to the typing issue, it's universal but also universally unknown. :^\ One thought I had in format was that $ could be literal for that symbol, but ¤ could be replaced based on a locale setting.
dockimbel on master
FEAT: adds `bounds` option to /… (compare)