[#79914] [Ruby trunk Bug#13282] opt_str_freeze does not always dedupe — normalperson@...
Issue #13282 has been reported by Eric Wong.
4 messages
2017/03/05
[#80140] [Ruby trunk Feature#13295] [PATCH] compile.c: apply opt_str_freeze to String#-@ (uminus) — shyouhei@...
Issue #13295 has been updated by shyouhei (Shyouhei Urabe).
5 messages
2017/03/13
[#80362] Re: [Ruby trunk Feature#13295] [PATCH] compile.c: apply opt_str_freeze to String#-@ (uminus)
— Eric Wong <normalperson@...>
2017/03/26
shyouhei@ruby-lang.org wrote:
[#80368] Re: [Ruby trunk Feature#13295] [PATCH] compile.c: apply opt_str_freeze to String#-@ (uminus)
— SASADA Koichi <ko1@...>
2017/03/27
On 2017/03/26 15:16, Eric Wong wrote:
[#80205] Re: [ruby-cvs:65166] duerst:r58000 (trunk): clarifiy 'codepoint' in documentation of String#each_codepoint — Eric Wong <normalperson@...>
duerst@ruby-lang.org wrote:
4 messages
2017/03/17
[#80213] Re: [ruby-cvs:65166] duerst:r58000 (trunk): clarifiy 'codepoint' in documentation of String#each_codepoint
— Martin J. Dürst <duerst@...>
2017/03/17
Hello Eric,
[#80290] [Ruby trunk Feature#13355] [PATCH] compile.c: optimize literal String range in case/when dispatch — normalperson@...
Issue #13355 has been reported by normalperson (Eric Wong).
4 messages
2017/03/23
[#80410] Re: [Ruby trunk Feature#13355] [PATCH] compile.c: optimize literal String range in case/when dispatch
— Eric Wong <normalperson@...>
2017/03/27
normalperson@yhbt.net wrote:
[#80415] [Ruby trunk Feature#12589] VM performance improvement proposal — vmakarov@...
Issue #12589 has been updated by vmakarov (Vladimir Makarov).
5 messages
2017/03/28
[#80488] [Ruby trunk Feature#12589] VM performance improvement proposal — vmakarov@...
Issue #12589 has been updated by vmakarov (Vladimir Makarov).
4 messages
2017/03/29
[ruby-core:80510] [Ruby trunk Feature#13166] Feature Request: Byte Arrays for Ruby 3
From:
Ruby-Lang@...
Date:
2017-03-31 08:04:24 UTC
List:
ruby-core #80510
Issue #13166 has been updated by jwmittag (J旦rg W Mittag).
I agree that the OP probably is more interested in a `BitVector`/`BitArray` than a `ByteArray`, at least for the specific use case he is describing. Nonetheless, such a data type sounds useful for high-performance code; it may also make it easier to self-host larger portions of the stdlib and corelib.
I would suggest to take a good look at the structured data types that have been added to ECMAScript in the last few years, specifically [`TypedArray`s](https://tc39.github.io/ecma262/#sec-typedarray-objects), [`DataView`](https://tc39.github.io/ecma262/#sec-dataview-objects), and [`ArrayBuffer`](https://tc39.github.io/ecma262/#sec-arraybuffer-objects), which are a generalization of what the OP is asking about: `ArrayBuffer` is an untyped contiguous portion of memory. It cannot be manipulated directly, it can only be manipulated through *views*. A buffer can have multiple views associated with it, and a view can be associated with only a subsection of the buffer. There are two kinds of views: `DataView`s offer heterogeneous access, with methods like `set_int8`, `set_uint8`, `set_int16`, `set_float64` (and the corresponding `get_*` methods) and so on. `TypedArray`s offer homogeneous access, there are types like `Int8Array`, `UInt8Array`, and so on. `TypedArray`s behave like `Array`s, but only support a subset of `Array` methods.
Translating the ECMAScript API to Ruby could look something like this:
```ruby
class ArrayBuffer
def initialize(length) end
attr_reader :byte_length
def slice(begin_offset, end_offset = byte_length) end
end
class DataView
def initialize(buffer, byte_offset = 0, byte_length = buffer.byte_length - byte_offset) end
attr_reader :buffer, :byte_offset, :byte_length
def get_int8(byte_offset) end
def set_int8(byte_offset, value) end
def get_uint8(byte_offset) end
def set_uint8(byte_offset, value) end
def get_uint8c(byte_offset) end
def set_uint8c(byte_offset, value) end
def get_int16(byte_offset, little_endian = false) end
def set_int16(byte_offset, value, little_endian = false) end
def get_uint16(byte_offset, little_endian = false) end
def set_uint16(byte_offset, value, little_endian = false) end
def get_int32(byte_offset, little_endian = false) end
def set_int32(byte_offset, value, little_endian = false) end
def get_uint32(byte_offset, little_endian = false) end
def set_uint32(byte_offset, value, little_endian = false) end
def get_int64(byte_offset, little_endian = false) end
def set_int64(byte_offset, value, little_endian = false) end
def get_uint64(byte_offset, little_endian = false) end
def set_uint64(byte_offset, value, little_endian = false) end
def get_float32(byte_offset, little_endian = false) end
def set_float32(byte_offset, value, little_endian = false) end
def get_float64(byte_offset, little_endian = false) end
def set_float64(byte_offset, value, little_endian = false) end
end
class TypedArray
private_class_method :new # TypedArray is abstract
def initialize(length) end
def initialize(typed_array) end
def initialize(enum) end
def initialize(buffer, byte_offset = 0, byte_length = buffer.byte_length - byte_offset) end
attr_reader :buffer, :byte_offset, :byte_length, :length
def set(array, offset = 0) end
def subarray(begin_offset = 0, end_offset = byte_length)
include Enumerable
class Int8 < self
BYTES_PER_ELEMENT = 1
def each(&blk) end
def [](窶ヲ) end
def []=(窶ヲ) end
# additional array methods 窶ヲ
end
class UInt8 < self
BYTES_PER_ELEMENT = 1
# 窶ヲ
end
class UInt8C < self
BYTES_PER_ELEMENT = 1
# 窶ヲ
end
class Int16 < self
BYTES_PER_ELEMENT = 2
# 窶ヲ
end
# and so on
end
class Array
def to_typed_array(type) end
end
```
----------------------------------------
Feature #13166: Feature Request: Byte Arrays for Ruby 3
https://bugs.ruby-lang.org/issues/13166#change-64013
* Author: jzakiya (Jabari Zakiya)
* Status: Feedback
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
I do a lot of numerically intensive applications.
In many instances I use arrays that contain boolean data (true|false or 1|0) values.
When I create such an array like:
`data = Array.new(size, value)` or just `data = Array.new(size)`
is it correct that the default memory unit size is that of the cpu, i.e. (32|64)-bit?
Since almost all modern cpus are byte addressable, I want to optimally use their system memory
by being able to explicitly create arrays of byte addressable elements.
For these use cases, this wlll allow my apps to extend their memory use capacity, instead
of wasting 31|63 bit of memory on 32|64 bit cpus systems just to store a boolean value.
To be clear, I am not talking about storing "strings" or "chars" but addessable 8-bit number elements.
I have not seen this capability documented in Ruby, thus I request this feature be added to
Ruby 3, and propose the following syntax that will be backwards compatible (non conflicting).
```ruby
data = Array8.new(size, value)
```
Having explicit addressable byte arrays not only will increase memory use compactness of many
applications, this compactness will directly contribute to the Ruby 3x3 goal for performance
by allowing more data to be held entirely in cache memory when possible.
Thanks in advance for its consideratoin.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>